The Model Context Protocol gives agents a standard way to discover tools from an MCP server and invoke them. That's genuinely useful — it's the same interoperability problem USB-C solved for chargers, applied to tool discovery. An agent that speaks MCP can call tools from any MCP server without bespoke integration code per tool.
What MCP doesn't standardize is the question every framework integration we've written about eventually runs into: should this specific agent be allowed to call this specific tool, right now, given its current trust level and context?
That's not a protocol gap MCP needs to fix — tool discovery and authorization are different concerns, and conflating them would make MCP servers responsible for policy logic that belongs elsewhere. But it does mean MCP deployments inherit exactly the same problem we described for LangChain, CrewAI, and AutoGen: a tool being discoverable and callable is not the same as a tool being authorized.
Where the gap shows up
An MCP server exposes a set of tools to any client that connects to it. In the patterns we've seen so far:
- The server itself has no concept of which agent is calling, beyond whatever the transport layer happens to carry.
- There's no standard place to ask "is this call, from this agent, in this context, allowed?" before the tool executes.
- If the server does add access control, it tends to be static — API-key-scoped or server-wide — not the kind of per-agent, per-action, context-aware decision that agent authorization requires.
That's the same shape of problem API keys had for agents in general, which is what got us started on this in the first place — see why agents need their own identity infrastructure.
How we think about the fix
The pattern that's worked for LangChain, CrewAI, and AutoGen is a gate in front of tool execution: identify the calling agent, check policy via /v1/decide, only proceed on ALLOW. Applied to MCP, that maps naturally onto an authorization gateway sitting in front of the MCP server — or a check baked into the server's tool-call handler — that:
- Resolves the calling agent's identity (DID-based, the same model used everywhere else in AGF)
- Evaluates the requested tool call against policy, trust score, and risk — the same three-signal decision every other integration uses
- Produces a signed decision artifact either way, so a call that's blocked (or allowed) is provable after the fact, not just logged as a guess
None of this requires MCP itself to change. It's the same authorization boundary we put in front of a LangChain BaseTool or a CrewAI Agent, moved to sit in front of an MCP server's tool-call handler instead.
Where we are today
To be direct about it: there's no shipped AGF adapter for MCP yet, unlike the LangChain and CrewAI integrations that ship in agf-sdk today. This post describes the direction, not a released feature.
If MCP governance is something you're hitting right now — you're running MCP servers in production and need per-agent policy enforcement before we've shipped a dedicated adapter — get in touch. The direct pattern from the AutoGen post (wrap the tool-call handler with AgentGovernance.authorize()) works today without any MCP-specific code, since the underlying primitive — check policy before executing — doesn't depend on which framework triggered the call.