# Why We Deleted Our MCP Server and Rebuilt It Abhi Arya, Reducto | AI Engineer | 16:40 Source: https://www.youtube.com/watch?v=jJQoVkd5yLg Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/why-we-deleted-our-mcp-server-and-rebuilt-it Published: 2026-10-08 Tags: context-engineering, human-in-the-loop, mcp, tool-use ## TL;DR - Agent-first software is an architecture problem defined by who pays when the agent is wrong. - Reducto replaced an MCP server with one tool per API endpoint with fewer tools that encode workflow structure, live state, and validation. - Making uncertainty visible, asking users instead of guessing, and logging usage helped the system improve and gain adoption from the sales team. ## Summary Abhi Arya describes Reducto's failed attempt to give its team an MCP tool for every API endpoint. A curated demo looked good, but real users supplied incomplete customer requirements and the agent built workflows that nobody could explain. Reducto deleted the server and rebuilt it around fewer tools that reflected actual work, such as a single classify-to-extract operation, automatic chaining, and a snapshot of live pipeline state. Arya then addresses failures that happen after a pipeline runs. Confidence scores, bounding boxes, error information, and explicit user questions make uncertainty visible instead of allowing the agent to guess. Reducto logs MCP sessions, overrides, low-confidence moments, and questions, then feeds those observations into longer-term guidance. Arya's argument is that agent-first design puts the agent inside a workflow where humans can inspect and answer for its work. The agent's access must be shaped around user verification. ## Key ideas ### Agent-first software is an architecture decision about responsibility [02:28](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=148s) Arya says agent-first software is not mainly about better prompts, APIs, or model optimization. It is an architecture problem that starts with one question: who pays when the agent is wrong? In auto mode, the agent acts freely and the user may never see its mistake. In a user-first design, the human gets many controls while the agent becomes little more than a chatbot. Arya prefers an agent experience in service of the user, where the agent has rich but scoped capabilities and the human can verify the work. This framing moves the design problem toward context, capability, and self-improvement. ### A tool for every API endpoint failed when real users supplied incomplete context [04:47](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=287s) Reducto's first MCP server gave every API endpoint its own tool in one large file. Arya built and tested it through a carefully controlled Claude Code demo, where he already understood the intended workflow. When the whole team used it, people supplied half-formed descriptions from customer calls or Notion pages. The agent then built complete workflows with confidence, but neither the user nor the agent could explain what the workflow did. It never admitted uncertainty, and there was no useful point where a human could inspect the process. Arya deleted the entire MCP file in one commit. ### Fewer tools can carry more useful workflow structure [06:27](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=387s) The replacement MCP server used fewer tools that encoded how Reducto's product actually worked. Instead of repeatedly exposing a generic create step and hoping the agent assembled the pipeline correctly, Arya created a classify-to-extract tool for a common path. The tool gave the agent guidance about what should happen next, and some tools chained automatically. This prevented the model from freelancing parts of the workflow that Reducto already knew were correct. The agent had a constrained path through the product, while the human could follow and explain the resulting pipeline. ### A snapshot tool gives a stateless agent current pipeline state [07:32](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=452s) Because agents are stateless, Reducto added a snapshot tool that returns the live state of the pipeline. It includes the full flow and surfaced errors with specific error codes. The agent can reference what is actually present instead of guessing variable names or inventing state. Arya describes this as moving context out of the prompt and into structure. The result was that the agent stopped guessing and started referencing. His broader rule is that an MCP server should provide tools carrying patterns, state, and validators, so the correct path is also the simplest path available to the agent. ### Runtime failures need visible uncertainty, not silent completion [08:17](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=497s) Encoding workflow structure fixed how the agent built pipelines, but it did not solve failures in the final output. A bad schema or an unclear document type could let a pipeline run across many documents while missing a scan or extracting the wrong information. These failures might produce no obvious system error. Reducto made uncertainty legible through confidence scores, bounding boxes, and other failure information from extraction. The tools pass that information back to the model, which can use it to improve the extraction schema. The user also receives an explanation of what the agent did and why. ### The agent should ask when an interpretation is ambiguous [10:22](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=622s) Arya says the agent must expose its own uncertainty as well as uncertainty in the output. If a field or document type can be read in two ways, the agent should say that and ask the user what they meant. Reducto's evaluations failed the agent when it made shaky assumptions. Its harness guidance encouraged the agent to use question tools offered by Claude Code and other frontier harnesses. The team rewarded asking instead of guessing. A clarifying question gives the model more context, lets it choose the right capability, and keeps final judgment with the human who is accountable for the work. ### Instrumentation turns usage into guidance for future pipelines [13:07](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=787s) Reducto logged every MCP session, including model prompts, human overrides, low-confidence moments, and questions. The team also asked salespeople and other users to export their Claude Code sessions so the product team could see how the agent behaved in practice. Those observations flowed back into the MCP's long-term guidance. Arya says the system became better at building pipelines through more usage, without the team rewriting the guidance by hand. The result was a self-improving loop for each organisation or user, while the underlying decision remained the same: keep the model guided and inspectable. ### Adoption came when the agent fit the sales team's existing work [14:12](https://www.youtube.com/watch?v=jJQoVkd5yLg&t=852s) Arya did not tell the sales team to use the agent. Reducto exposed it as product tools in its Claude Enterprise environment, and people began adding it to their workflows. Before customer calls, they used CircleBack or Slack to learn about the customer, then used the MCP to ask questions and build a pipeline. The team trusted the output enough to put it in front of high-value customers. In Arya's account, adoption came from an experience that helped users do their work and let them explain what they had built, rather than from pushing people toward a new tool. ## Notable quotes - "Agent-first software is inherently an architecture problem." (02:28) - "I deleted the entire thing in one commit." (10:27) - "By moving context out of the prompt and into structure, the agent stopped guessing and started referencing." (07:57) - "You don't hand your agent an API, you hand it tools that carry the overall expertise such as the right patterns, the state, and the validators." (08:17) - "When your agent is really confidently wrong, who finds out and how fast did they find out?" (15:54) ## Tools & references mentioned - Reducto - Harvey - Scale AI - Claude Code - CircleBack - Slack - Notion - Mean Girls ## Who should watch - You are exposing an API or MCP server to an agent and are considering one tool per endpoint. - Your agents complete workflows that users cannot easily inspect or explain. - You need a practical way to surface uncertainty, collect human corrections, and turn usage into better guidance. ## Editor's note Abhi Arya says Reducto's first MCP server let agents build complete workflows that neither the user nor the agent could explain. Kitaru records each model call and tool result in a real run, then replays the run with the same inputs and tool responses. That gives the team a fixed case to inspect after changing the prompt, model, or code. Written by the AIE Talks editors (the Kitaru team), not by the speaker. ## Related talks - [Your MCP Server is Bad (and you should feel bad)](https://aietalks.com/talks/your-mcp-server-is-bad-and-you-should-feel-bad) (Jeremiah Lowin, Prefect, 54:33) - [Bending a Public MCP Server Without Breaking It](https://aietalks.com/talks/bending-a-public-mcp-server-without-breaking-it) (Nimrod Hauser, Baz, 40:50) - [MCP Is Not Good Yet](https://aietalks.com/talks/mcp-is-not-good-yet) (David Cramer, Sentry, 16:41) - [Exposing Agents as MCP Servers with mcp-agent](https://aietalks.com/talks/exposing-agents-as-mcp-servers-with-mcp-agent) (Sarmad Qadri, Last Mile AI, 18:05) - [Rebuilding the Web for Agents](https://aietalks.com/talks/rebuilding-the-web-for-agents) (Liad Yosef, MCP Apps, 20:41)