🚀 Beta: All Pro and Team features are free. Install on GitHub →

← Blog

What Is MCP Governance?

MCP governance is the practice of controlling what an AI agent’s tools are allowed to do — validating tool schemas against breaking changes, gating high-risk actions before execution, and producing verifiable evidence of every decision.

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.

The direction is unmistakable: MCP is turning into production infrastructure. And production infrastructure needs governance — not a demo that trusts every tool call, but a layer that validates, decides, and records.

What MCP governance covers

Three layers, each mapping to a capability you can exercise today.

Tool-schema stability. An agent binds to a tool’s input and output schema. If that schema drifts — a parameter removed, a type tightened, a field made required — the agent breaks mid-call, silently. Validating each MCP tool schema against the previously deployed one before it ships catches the break at deploy time, the same way an OpenAPI diff catches breaking changes in a REST contract.

Pre-execution verdicts. Before an agent acts, it can ask for a deterministic decision: ALLOW, WARN, REQUIRE_APPROVAL, or BLOCK. A preflight check scores the change and its blast radius; an action verdict gates a high-risk tool call. The same inputs always produce the same verdict, so the decision is auditable rather than a model’s guess.

Verifiable evidence. Every verdict ships as an Ed25519-signed receipt covering the decision and a hash of the evidence. Anyone can verify it against a published public key with an open-source verifier, so the record cannot be quietly rewritten and no one has to take the vendor’s word for it.

The stateless transition

The July 28 spec removes the session entirely. Our MCP surface never had one. The Streamable HTTP path dispatches each request on its own — a tools/list or tools/call works with no prior initialize, and there is no session map to keep. The move that the new spec asks servers to make, this surface had already made. Three honest caveats belong here.

server/discover is not yet implemented. A call to it returns a clean JSON-RPC -32601 (method not found) with a correlation id, and clients fall back to the specification’s standard discovery path. Nothing breaks; the method is simply absent.

_meta fields are tolerated, not yet consumed. A request carrying _meta (for example a 2026-07-28 protocolVersion) is accepted and answered normally — the surface never rejects it — even though it does not yet read those fields.

Legacy initialize continues to work. A pre-2026 client that opens with initialize gets the expected handshake back, so older integrations are unaffected by the stateless move.

See it yourself

Three probes against the live MCP endpoint, captured 2026-07-21. No key, no signup — run them yourself.

Verified finding — run it yourself

1. tools/list with no handshake (stateless), 2026-07-28 metadata:

curl -s https://app.coderifts.com/mcp \
  -H "Content-Type: application/json" \
  -H "Mcp-Method: tools/list" -H "Mcp-Name: coderifts" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{"protocolVersion":"2026-07-28"}}}'

→ the full tool list, no initialize required. First tool: preflight_check.

2. server/discover (not yet implemented):

curl -s https://app.coderifts.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"server/discover"}'

→ a clean JSON-RPC error carrying a correlation_id: {"error":{"code":-32601,"message":"Method not found: server/discover"}}. Clients use the spec’s fallback discovery path.

3. legacy initialize (older clients still work):

curl -s https://app.coderifts.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":3,"method":"initialize","params":{"protocolVersion":"2025-06-18"}}'

→ result echoed: protocolVersion 2025-06-18, capabilities tools, serverInfo CodeRifts API Governance 1.0.0.

MCP manifest · MCP onboarding · Open-source verifier

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. 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, so an agent, a downstream team, or an auditor can confirm what was decided without trusting the vendor.

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.

CodeRifts is API and MCP governance as a zero-config service: it validates tool and API contracts, issues a deterministic pre-execution verdict, and signs it so anyone can verify the decision. Connect the MCP server, or read what agent-safe API governance means.