item's product is an agent. It lives inside their Next.js app, it is wired into their own services, and it carries the kind of domain knowledge you only get from building for a specific problem for a long time. It is the thing their customers come for.
So it was not surprising when those customers started asking the same question: can we use item from our own agents? They were already living in ChatGPT, Claude, and Cursor, and they wanted item's capabilities to show up there too. The answer to that question is MCP. This is the story of how item shipped it.
Step one was not "build an MCP server", it was "do not fork the app"
item's first instinct was the right one: they did not want to rewrite their logic in a separate service just to speak MCP. Everything already existed in their Next.js codebase: the services, the auth, the tools their agent calls. Standing up a parallel project and porting that logic over would mean maintaining the same thing twice and watching the two copies drift.
The plain MCP path did not fit their setup either. It was not flexible enough for how their app was built, it made authentication harder than it needed to be, and it had no story for the next thing they wanted: an MCP app, with real UI rendered inside the client, once they were ready to ship richer experiences.
What they wanted was one source tree that could ship two things: the Next.js app and an MCP server, sharing the same code. That is exactly the setup we walk through in our Next.js integration guide, and it is the foundation item built on.
Reuse the tools you already have
item's internal agent runs on AI SDK tools. The key move was that the MCP server reuses those exact same tools. No second implementation, no separate definitions to keep in sync. The tool an external agent calls through MCP is the same tool item's own agent calls internally.
With mcp-use handling the protocol, the team got a production-grade MCP server, with authentication and their existing services intact, in a fraction of the time it would have taken to build one from scratch. Their customers had been asking for an MCP, and instead of a multi-week detour it became a focused piece of work on top of what they already had.
The interesting part: expose the agent as a tool, not just the data
Here is where item did something we are seeing more and more, and did it well.
They did not just expose the raw tools. They went hybrid. The MCP server offers two layers:
- The underlying tools, so ChatGPT or Claude can act directly on the data when a request is simple.
- The item agent itself, exposed as a single MCP tool, so that for anything complex an outside agent can hand the question to item's agent instead of trying to orchestrate the raw tools on its own.
That second layer is the important one. item spent a long time building an agent that knows their domain. Exposing it as a tool means all of that context and judgment travels with it. An external agent does not have to rebuild item's reasoning from primitives. It can just ask item.
For any company that already has an internal agent, this is a clean pattern: reuse your existing tools in an MCP server, and expose your agent as a tool so the full functionality and context you built can be used by agents outside your product.
One week in production
The most interesting result showed up almost immediately. After about a week live, outside agents are leaning heavily on the item assistant tool rather than driving the raw tools themselves. Given the choice, they prefer to ask the agent.
That is a good outcome for item, because the agent is their value. The worry with exposing your product through MCP is that you give away the thing that makes you you. What actually happened is the opposite. The raw tools are there for customers who want their own agents to act directly, and that is real value too. But the agent, the part item is proud of, gets called more, not less. Putting it behind MCP extended its reach instead of hollowing it out.
If you have an internal agent, this is the playbook
item's path is repeatable for any team in the same spot:
- Keep one source tree. Run the MCP server from your existing Next.js repo instead of forking your app into a new service. The Next.js integration guide shows how.
- Reuse your existing tools. The tools your internal agent already calls are the tools you expose over MCP.
- Expose the agent itself as a tool, so outside agents can defer to it for the hard questions and your domain knowledge comes along for the ride.
- Let mcp-use handle the protocol and authentication so the work stays on your product, not on plumbing.
If you are building on Next.js and want your product to be reachable from ChatGPT, Claude, and Cursor, start with mcp-use or read the Next.js integration guide.
