What MCP actually standardises
MCP gives a consistent schema for tool discovery, invocation and response — an agent can learn what a tool does and call it without bespoke integration code per tool. This is a genuine productivity win, comparable to what REST did for web APIs a decade earlier.
What it does not standardise is who is allowed to expose which tools to which agents, under what conditions — that governance layer sits entirely outside the protocol and has to be built deliberately.
The new boundary: tool servers you don't control
As MCP adoption grows, agents will increasingly call tool servers operated by third parties — plugins, partner integrations, community-maintained connectors. Each one is effectively a new, unaudited piece of your action surface the moment it's added to an agent's available tools.
Treat every third-party MCP server with the same scrutiny you'd apply to a new vendor API integration: least-privilege scoping, output validation, and an explicit allowlist rather than open discovery.
Governing it without losing the productivity benefit
A workable pattern is a central tool registry: every MCP server an agent can reach is reviewed once, scoped explicitly, and versioned — agents request access to a registered capability, not to an arbitrary discovered server. This keeps the integration speed MCP promises while keeping a human-reviewed boundary around what it's actually allowed to touch.
This is the same lesson enterprises already learned with API gateways; MCP just moves the same problem into the agentic layer, faster than most security teams have had time to notice.
A standard protocol for calling tools is not a standard for deciding which tools should be called.MNB AI Practice
Key actions
- Treat third-party MCP servers like unaudited vendor integrations
- Maintain a reviewed, versioned tool registry rather than open discovery
- Scope agent-to-tool access per registered capability
- Validate tool outputs before acting on them, not just inputs