Why Reducto deleted its one-tool-per-endpoint MCP server and rebuilt it with fewer, workflow-shaped tools

What went wrong

The first version was a minimum viable product built with Claude Code: every API endpoint behind the app became one MCP tool, all in one large file. It looked fine in a curated demo, then failed when the team used it. People pasted half-formed notes from customer calls or Notion pages, and the agent built an entire pipeline end to end, told the user everything was right, and neither side could explain what the workflow did. His label for this is 'auto mode' in production: maximum autonomy, with nobody positioned to validate.

What replaced it, step by step

1. Delete the file. The whole file was removed in one commit, and the fix was 'mostly fewer tools', not more guidance in the system prompt.
2. Build tools that carry the structure of the work. Instead of a generic create-step tool called repeatedly, he made tools that know how the product works. Example: routing the output of a classify step into an extract step became a single classify-to-extract tool, so the agent no longer guesses a path the team already knows is right.
3. Give each step contextual guidance. After each call the agent is told what comes next, and some tools chain automatically.
4. Add a snapshot tool. Agents are stateless, so one call returns the live state of the pipeline, from the context of the whole flow to errors with specific error codes, so the agent references what exists instead of guessing variable names.
5. Make uncertainty legible. Extract returns confidence scores and bounding boxes; the server feeds that back to the model, which helped it tune the extract schema over time.
6. Ask instead of guess. When something is ambiguous (two ways to read a field, an unseen document type) the agent should ask the user. Their evals started failing the agent for shaky assumptions, and the harness prompt points it to the ask-user-question tools frontier harnesses offer.
7. Explain every action. Each time the agent builds something, the MCP output says what it did and why, so the user can review it.
8. Instrument everything. Every MCP session and prompt is logged, and team members exported their Claude Code sessions, to see where humans overrode the agent, where model confidence ran low and where it asked questions. That fed back into the server's guidance, a self-improving loop per organisation.

The framing he uses

He sorts agent software by 'who pays when the agent is wrong': auto mode (autonomy first; the user pays), user-first (every knob exposed; the agent can't do much) and agent experience in service of the user, where the agent gets rich but scoped capabilities and a person can still verify the work. Unprompted, the sales team started using the rebuilt server in their calls, which he takes as the signal it worked.

Gotchas & Caveats

• Company talk for Reducto, a document-processing platform; the talk ends with a hiring pitch. The lessons are about MCP design, not about Reducto's product.
• No numbers are given for failure rates before and after; the evidence is the team's behaviour changing.
• The tool names are his illustrations of the idea, not published tool definitions.

Key Takeaways

• One tool per API endpoint hands the agent an API; a few tools shaped like the real workflow hand it expertise.
• Give stateless agents a single 'what is the state right now' tool.
• Return confidence and error detail to the model, and reward asking over guessing in your evals.
• Log every session; the overrides and questions are your best source of improvements.