Model Context Protocol (MCP) is one of the more useful things to happen to AI agent architecture in the past year. It standardizes how agents connect to tools: a JSON-RPC 2.0 transport that lets any MCP-compatible agent call any MCP-compatible tool without custom glue code. The protocol is well-designed. The adoption is real. The ecosystem is growing.
It does not solve governance.
This is not a criticism of MCP. It would be a category error to criticize a transport protocol for not handling governance decisions—that is not what transport protocols do. But the distinction matters, because a growing number of teams are treating MCP adoption as equivalent to having governed AI agents. Those are different things.
What MCP Does Well
MCP solves a specific, important problem: agent-to-tool connectivity at scale.
Before MCP, connecting an AI agent to a new tool meant writing a custom adapter. The adapter had to handle authentication, response parsing, error handling, and retry logic—all specific to that tool’s API. Multiply this across dozens of agents and dozens of tools, and you get thousands of lines of adapter code that all do the same thing slightly differently.
MCP standardizes the interface. Tools expose a set of callable operations via the MCP server specification. Agents discover those operations via the protocol. The handshake is consistent. The JSON-RPC format is consistent. A tool built to the MCP spec works with any MCP-compatible agent without custom integration work.
This is genuinely valuable. Connectivity friction is a real cost in multi-agent systems. Reducing it matters.
What MCP Does Not Do
MCP defines how agents connect to tools. It does not define what agents are permitted to do once connected.
Here is the specific gap:
| MCP handles | MCP does not handle |
|---|---|
Informing an agent that a send_email tool is available |
Whether the agent is permitted to send email right now |
Describing the parameters send_email accepts |
How many emails the agent sent in the last 24 hours |
Delivering the result when send_email is called |
Whether the proposed recipient has opted in |
| Standardizing the transport format | Which constitutional constraints apply to outbound messaging |
These are governance questions. They require access to system state, policy context, and decision logic that lives outside the transport layer.
The WHO vs. HOW Distinction
The current wave of AI agent governance tooling solves the WHO problem: which agents exist, what systems they can access, and when they should be suspended. MCP fits naturally into this layer—you know which tools an agent has registered, and you can revoke access at the protocol level.
The HOW problem is different: how does an agent decide what to do with the access it has?
This distinction matters operationally. An agent that has registered access to an email tool can send email to anyone in its contact list, any time the tool call succeeds. Protocol-level access control does not constrain the agent’s judgment about when to use that access. The agent can be correctly authenticated, correctly authorized, and still make a decision that violates a policy, exceeds a rate limit, or triggers an unintended consequence.
Governance at the HOW layer requires something that looks more like constitutional logic than access control: rules that evaluate the current state of the system before any consequential action is taken.
What We Built on Top of MCP
We use MCP’s SSE (Server-Sent Events) transport in our system. It handles the connectivity layer. On top of that, we built five governance tools that external AI systems can query before acting:
Five Governance Tools Built on MCP SSE Transport
- gate_evaluate — returns the current state of all six governance gates (PASS / HOLD / FAIL)
- harm_test — evaluates a proposed action against constitutional harm criteria
- constraint_check — verifies a proposed action does not violate any of 17 hard constraints
- dli_assess — runs a Decision Load Index evaluation for a given user context
- audit_decision — logs a decision with full constitutional citation for the immutable audit trail
An external agent that connects via MCP can call gate_evaluate before acting and receive a structured response indicating whether the system is in a FREEZE, THROTTLE, or RUN state. It can call constraint_check with a proposed action and receive a PASS or FAIL with a specific constitutional citation if the action is blocked.
These tools are not access control. They are governance reasoning exposed as a queryable interface.
The MCP transport makes them discoverable and callable in a standard way. The governance logic is entirely separate from the transport.
Why the Distinction Matters
As AI agent systems scale, the governance gap becomes more consequential. An agent fleet with MCP connectivity can reach more systems, more quickly, with more standardized integration than ever before. That is the value proposition of MCP. It is also why the absence of a HOW layer becomes more expensive as MCP adoption grows.
A transport protocol that makes it easy to call 50 tools is neutral on whether those calls are appropriate. The governance layer that decides appropriateness needs to exist somewhere. It does not emerge automatically from connectivity infrastructure.
MCP is additive to governance architecture. It is not a substitute for one.
The teams building on MCP that are also building constitutional constraints on agent behavior—rules that evaluate system state before action, that log decisions with citations, that fail closed when state is uncertain—are not doing extra work. They are doing the other half of the work.
A Note on Complementarity
None of this is intended as a critique of MCP or of teams building with it. The protocol is well-specified and solves a real problem. The point is specifically about scope.
Connectivity and governance are adjacent layers that each need to exist. A well-connected agent without governance constraints will make decisions at machine speed with no policy context. A governed agent without reliable connectivity tooling will make decisions slowly and inconsistently across different tool integrations.
Both layers matter. They are not interchangeable.
Read the Research Preprints
The constitutional governance architecture described in this article is documented in published preprints: the CSG framework and the Agent Security Harness evaluation results across MCP, A2A, L402, and x402 protocols.
Constitutional Self-Governance → Agent Security Harness (MCP/A2A) →Is your organization governance-ready?
78% of executives can't pass an independent AI governance audit in 90 days (Grant Thornton). Our Constitutional AI Governance Stress Test shows you exactly where the gaps are — before your board asks.
Get Your Governance Score →