What is MCP governance?
The Model Context Protocol (MCP) is how AI agents discover and call tools. As agents move from demos into production, the tools they call become part of your attack surface and your reliability surface. MCP governance is the layer that keeps that surface under control: it checks that a tool's contract has not silently changed, decides whether a given action is safe before the agent runs it, and leaves a record you can verify afterward.
Why now: MCP is becoming production infrastructure#
The protocol is standardizing fast. The Model Context Protocol 2026-07-28 release candidate takes the core protocol stateless: the initialize handshake and the session header are removed, and per-request metadata moves into a _meta field. It adds routable Mcp-Method and Mcp-Name request headers, a server/discover method, hardened authorization, and a formal 12-month deprecation policy. The release candidate was locked on May 21, 2026; the final specification publishes on July 28, 2026.
Frequently asked questions#
What is MCP governance?
MCP governance is the practice of controlling what an AI agent's tools can do: validating tool schemas against breaking changes before deployment, issuing a deterministic verdict before a high-risk action runs, and signing that verdict so it can be verified later. It is API contract governance applied to the Model Context Protocol.
What changes in the MCP 2026-07-28 specification?
The core protocol becomes stateless: the initialize handshake and the session header are removed, and per-request metadata moves into a _meta field. It adds routable Mcp-Method and Mcp-Name request headers, a server/discover method, hardened authorization, and a formal 12-month deprecation policy. The release candidate was locked on May 21, 2026, and the final specification publishes on July 28, 2026.
Does a stateless MCP server mean my application can't have state?
No. Stateless refers to the transport: the server does not keep a session between requests. Your application still carries state through explicit handles that tools return and accept, which is how the specification itself expects state to be passed. The transport is stateless; your workflow is not.
How do I validate an MCP tool schema for breaking changes?
Compare the new tool schema against the previously deployed one before you ship. A schema diff detects removed parameters, tightened types, or newly required fields that would break an agent mid-call, and classifies each as breaking or non-breaking, the same way an OpenAPI diff works for REST contracts.
Can an MCP verdict be verified independently?
Yes. Verify the receipt yourself — offline, no live CodeRifts API call needed. A verdict is issued as an Ed25519-signed receipt covering the decision and a hash of the evidence. Anyone can check it against the published public key with an open-source verifier. See Portable Verification.
Is the CodeRifts MCP server compatible with the 2026-07-28 spec?
The stateless core client path works today. A tools/list call with no handshake returns the full tool list, and legacy initialize still works for older clients, both verified live on 2026-07-21. The server/discover method is not yet implemented; the server returns a clean -32601 error and clients use the specification's fallback discovery path.
See also: MCP Integration, Decision Spec v2.