Contract-first AI governance

One MCP Contract. A deterministic foundation for AI agent governance.

The MCP Contract plays the same role for AI agent tools that an OpenAPI contract plays for a REST API — a single, machine-readable source of truth. The difference is what that source of truth buys you: assessed the same way every time, so the result holds up as evidence, not a snapshot.

Why it matters

The one document a security team, a regulator, and an AI agent can all rely on.

An MCP Contract works for the same reason an OpenAPI contract works — everyone stops arguing over separate versions of the truth and starts working from one. Security teams get a precise, versioned declaration of what a server exposes and permits, instead of a wiki page or a Slack thread. The calling AI agent gets the closest thing it has to ground truth about what a tool is actually for. And because the contract is machine-readable, assessment against it is deterministic: the same server evaluated twice returns the same score, the same findings, and the same verdict — which is what turns a governance decision into audit evidence, not a point-in-time opinion.

What a good contract buys you

Four things a deterministic MCP Contract does that a policy document can't.

Repeatable governance

Assessment runs against the declared contract, not a human's read of the server on a given day. Score a server twice, get the same answer twice.

Audit-grade evidence

A deterministic verdict is something you can hand to a regulator or a customer security review — not a dashboard screenshot with a timestamp.

CI/CD enforcement, no manual gate

Because the contract is structured, a Security Quality Gate can block a non-compliant server automatically — no one has to remember to review it.

Scales from one server to the estate

The same contract model governs ten MCP servers or ten thousand, without governance quality depending on team-by-team discipline.

No manual spec-writing required

Point it at a URL. The contract writes itself.

The contract does not need to be written by hand. Connect to any live MCP server URL and the discovery pass generates the contract automatically — every tool, resource, and prompt the server exposes, plus best-effort inferences for risk level, data classification, and side-effects.

Anything that can't be safely inferred is marked # STUB rather than guessed — so a human closes the gap deliberately instead of publishing a false sense of completeness.

$ mcp-scanner -addr https://your-server/mcp \ -contract contract.yaml \ -server-name io.acme/crm-mcp \ -server-version 2.4.1 ✓ discovered 14 tools, 3 resources, 2 prompts ✓ contract.yaml written (mcpContract: "0.2") → 6 fields marked # STUB — complete before audit
What's inside

Nine sections. One of them is real today.

The schema is deliberately structured so that free-text descriptions — the part an AI model actually reads — sit in their own section, separate from the structural declarations security teams review. The structural sections define the schema that the 42Crunch platform audits and scores against.

Live — real analysis today

content

The full-text description field of every tool and prompt — added in schema version mcpContract: "0.2" alongside the existing truncated title. This is what a calling AI model actually reads, and it's what the 42Crunch platform analyzes automatically for prompt injection, tool poisoning, data exfiltration, and tool shadowing.

Schema exists — scoring is roadmap

Eight structural sections

serverName, version, reverse-DNS identity
initializeInstructions given to the calling agent
integrityMessage signing, rug-pull protection
resolutionAudit invariants
capabilitiesTools, resources, prompts and their risk levels
authenticationSchemes, fail-closed defaults
authorizationRoles, wildcard-allow rejection
throttlingRate limits, fail-closed behavior
Producer & consumer

One contract, read by two very different audiences.

This is the same idea that makes an OpenAPI contract valuable — just applied to a new kind of consumer.

For producers (your team)

A precise, versioned declaration of what your MCP server does and doesn't allow — the basis for governance, automated testing, and a CI/CD gate that doesn't depend on someone remembering to review a pull request.

For consumers (the AI agent)

The contract is the closest thing to ground truth an AI model has about what a tool is actually for. A well-written, hardened content section is what stands between a calling agent and a tool description trying to manipulate it.

Frequently asked

MCP Contracts, answered.

What makes contract-based MCP governance different from scanning traffic? +

Traffic-based detection tells you what happened; a contract tells you what's allowed, so a security team can test and gate a server before it's ever called by an agent, not just log what an agent already did.

Why does determinism matter for AI governance specifically? +

Because the burden of proof is different — a regulator or auditor needs a result that doesn't change depending on when you asked. A deterministic, contract-based verdict is reproducible; a live-traffic risk score generally isn't.

Does the contract replace runtime protection? +

No — it's the declaration that runtime enforcement is built from. The contract says what's permitted; a runtime layer (MCP Runtime Protection) is what actually blocks a server that drifts from it.

What happens to fields that can't be inferred automatically? +

They're marked # STUB rather than silently guessed, so a human closes the gap deliberately — the contract never claims more completeness than it has.

Generate your first MCP Contract in the time it takes to read this page.