Tool-Level Permission Scoping in MCP: Why Server Authentication Isn't Enough

When teams first secure an MCP server, they focus on the front door: who can connect. OAuth, API keys, TLS — the authentication layer. It feels complete. The question "is this agent allowed to use this server?" has an answer. But there's a second question they haven't asked: "Which tools on this server is this agent allowed to call?" These are different problems. And conflating them is how you end up with a research agent that can accidentally trigger a deployment. The Single Permission Boundary Problem Most MCP server implementations today treat auth as binary. An agent authenticates → it gets access to the full tool surface. Every tool the server exposes is available to every authenticated client. This works fine in a single-agent setup. It starts breaking down the moment you add heterogeneous agents — systems where a research agent, a deployment agent, and a data pipeline agent all talk to the same MCP server. Each of those agents has a different job. Different blast radius. Differe