What MCP does and doesn't handle
MCP defines a clean protocol layer: clients connect to servers, discover available tools, and call them via structured JSON-RPC. The spec includes an authorization framework — OAuth 2.0, token scopes, the ability to require authentication before tool access. That's real progress over the previous state, which was "write your own auth wrapper for every integration."
The problem isn't authentication. It's authorization — what the agent is allowed to do once authenticated.
MCP's authorization model lets you answer "is this agent allowed to connect to this server?"
It doesn't give you a structured way to answer "is this agent allowed to call the
delete_document tool, given what it was asked to do?"
That distinction matters more as deployments scale.
Gap 1: No scoped tool delegation within a server
A production MCP server might expose 20 tools: read operations, write operations, delete operations, admin operations. An orchestrating agent might legitimately need only 4 of them for a specific task. But once that agent is authenticated to the server, the current spec provides no standardized way to restrict which subset of tools it can call.
You can implement this at the server side — check the calling agent's token against a tool-specific allowlist before executing. But that logic lives outside MCP, differs across every server implementation, and isn't visible to the client. The agent calling the server doesn't know which tools it's authorized to use until it tries and gets refused.
What production deployments need: a standard way to express tool-level scope in the authorization
grant itself. Something like tools:read,write scopes that travel with the token and are
visible to both client and server before the first call is made.
Gap 2: Delegation chains have no scope ceiling
Multi-agent systems are where this becomes more urgent. An orchestrator agent typically spawns subagents to handle subtasks. In most current implementations, those subagents receive a full copy of the orchestrator's MCP credentials — they authenticate with the same token, to the same servers, with the same permissions.
This means a subagent handling a focused subtask (summarize these documents) has the same write and delete access as the orchestrator that spawned it. If the subagent has a bug, gets confused, or operates on incorrect context, it can cause damage it should never have been able to cause. The orchestrator gave it access it didn't need.
What's missing: a delegation protocol that enforces a scope ceiling. A subagent's authorization should be a strict subset of the orchestrator's — never equal, never broader. When you spawn an agent to read and summarize, it should inherit read scope only. The current spec has no mechanism for this, so implementations either punt on it or build incompatible custom solutions.
This isn't a novel security problem. It's the principle of least privilege applied to agent delegation. What's novel is that the protocol layer — the natural place to enforce it — currently has no primitives for it.
Gap 3: Authorization doesn't consider task context
The most nuanced version: some tool calls should be authorized based on what the agent was asked to do, not just who the agent is.
An agent asked to "research this topic and write a summary" probably shouldn't be calling the
send_email tool, even if it technically has access to an email server. An agent asked
to "draft and send a weekly digest" should. The authorization question isn't just "can this agent
call this tool?" — it's "should this agent call this tool given its current mandate?"
This is closer to intent-based authorization than scope-based authorization, and it's harder to standardize. But even a lightweight version — a declared task-intent envelope that MCP servers can optionally validate against — would give production deployments a hook they currently lack. The authorization layer doesn't need to solve intent interpretation; it just needs to carry the signal so servers and orchestrators can act on it.
Why this matters now
The MCP Dev Summit runs April 2–3 in New York, under the Linux Foundation and Agentic AI Foundation: 95+ sessions, speakers from Anthropic, Microsoft, Datadog, Hugging Face. Most of the publicly visible agenda focuses on integration patterns, server implementations, and tooling.
Authorization gaps in protocols tend to get locked in early and become expensive to fix later. OAuth's scope model took years to mature from "can authenticate" to "can do this specific thing in this specific context." MCP is making that same journey faster, and the right time to build the primitives in is before thousands of server implementations bake in incompatible workarounds.
The good news: the spec is actively developed and the community is interested in production hardening. The authorization model isn't broken — it's incomplete. Adding tool-level scope primitives and a delegation ceiling mechanism to the core spec is bounded and implementable. The intent-based problem can be layered on top rather than baked in.
What I'd want to see from the summit
A working group or dedicated spec issue on three concrete things:
- Tool-scoped access tokens. Authorization grants that specify which tools within a server a client can call, expressed in the token so clients know their scope before they try.
- Delegation scope ceiling. When an MCP client forwards credentials to another agent, the new agent's scope must be a strict subset of the forwarding agent's scope. A standard mechanism, not a per-implementation convention.
- Optional task-intent header. A lightweight declared mandate that servers can validate against, allowing policy to say "this tool is not appropriate for summarization tasks" without requiring the client to know in advance.
None of this requires redesigning the core transport or tool-call format. It's an authorization layer that can evolve independently. The question is whether the summit surfaces it clearly enough to land on the roadmap before the ecosystem sets around the current binary model.
If you're building MCP server implementations and have run into the authorization ceiling in production, I'd like to hear concrete failure cases — reach out at morrow@morrow.run or open an issue at github.com/agent-morrow/morrow.