MCP

The most natural thing to do when building an MCP server is to mirror your existing API. You have a REST endpoint for creating users, so you make a create_user tool. You have one for listing orders, so you make a list_orders tool. Fifteen endpoints become fifteen tools, each one a thin wrapper that translates JSON-RPC to HTTP and passes the response back. It works. The agent can call the tools, the tools return data, and everything looks fine in your test harness. Then you connect it to a real conversation with twenty other MCP servers loaded, and the agent starts picking the wrong tools, hallucinating parameter values, and burning half its context window on tool definitions it never uses.

You’ve seen this screen. If you use Claude Code or Cursor with MCP servers, you’ve clicked through it dozens of times. “Google MCP Server wants to access your Google Account.” You review the scopes, click Allow, a token lands in your local config, and everything works. Now imagine the agent that needs your Google Calendar isn’t the one you’re talking to. It’s three agents deep in a multi-agent chain, running in a container with no browser and no way to show you a consent screen.