How does MCP act as a contract between agents and external systems?

What you need to know

What the contract fixes

• Inputs — inputSchema (JSON Schema) for each tool.
• Outputs — optional outputSchema; when present, the server must return structuredContent that matches it, and clients should validate it.
• Behaviour hints — annotations such as readOnlyHint and destructiveHint (hints only).
• Protocol version and capabilities — each request states its version and client capabilities; servers advertise theirs through server/discover. A mismatch returns an "unsupported protocol version" error instead of undefined behaviour.
• Error vocabulary — JSON-RPC errors for protocol problems (unknown tool, malformed request); isError: true results for tool execution problems (bad date, upstream API down).

What it lets teams do

Where the contract stops

• Semantics. A schema says amount is a number; it does not say whether it is rupees or paise. Only the description (and tests) carry meaning.
• Behaviour changes. A tool can keep its schema but change what it does. Treat description and behaviour changes as breaking changes: version them and announce them.
• Trust. The contract is not a security boundary against a malicious server.

Practical contract hygiene

• Version your servers, and keep a changelog of tool changes.
• Add contract tests: call each tool with known inputs and check the output schema.
• Make changes additive: new optional fields, new tools; deprecate before removing.
• Pin the server version in production hosts.

A real-life example

A travel company's hotel team runs an MCP server used by four agents. The search_hotels tool has an outputSchema with price_per_night_inr as a number.

The hotel team moves to a new supplier and, in a refactor, starts returning prices including taxes. The schema still validates — it is still a number — but the agents now quote prices 18% higher than the booking page. Nobody noticed for two days.

Their fixes: a new field price_per_night_inr_incl_tax alongside the old one (additive change), the description now says exactly what each price includes, a contract test compares the MCP output with the booking page for 20 sample hotels every night, and the server version is pinned in each agent so changes roll out deliberately.

The schema did its job — it caught nothing because nothing was structurally wrong. The meaning changed, and only descriptions, versioning and tests catch that.

Follow-up questions to expect

• "How do you handle breaking changes?" — Add a new tool or field, deprecate the old one with a notice in its description, watch usage, then remove it.
• "Should clients validate server outputs?" — Yes, when an outputSchema is given. It catches server bugs before they reach the model.
• "What happens if versions don't match?" — The server returns an unsupported-version error listing what it supports; the client can retry with a supported version.