42Crunch launches MCP Security Governance — AI exposure management and compliance reporting for every MCP server. Read release

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.