What belongs in an MCP production contract?

Decide what the shared service promises

A tool becomes a production responsibility when someone organizes work around its result. That can happen before a large launch: six support engineers using a shared lookup may already need an outage response and a clear data boundary. Begin with their task, the result they can rely on, and the consequence of a wrong or missing answer.

Write the promise so it can fail visibly. “Provides document search” is too broad. “Returns passages from the caller’s approved product corpus, identifies the source revision, and reports when that corpus is unavailable” gives reviewers something to examine. Search relevance may remain sampled, but corpus membership and source identity can be checked directly.

Responsibility crosses more than the network

The MCP architecture distinguishes host, client, and server roles. Map those roles to the actual teams and deployment components. A client library has no pager; a gateway team may own routing without owning the meaning of a returned passage.

For each boundary, identify who can detect a failure, who can stop exposure, and who can restore service. These may be three different owners. An agreement that says “the platform team owns MCP” leaves the host’s catalog, the server’s data projection, and the backend’s freshness unresolved.

Twenty-four analysts inherit a laptop assumption

Consider a hypothetical procurement assistant initially used by one analyst against public product manuals. It moves to a shared endpoint for twenty-four analysts in three business units. The new service also indexes internal supplier notes, but the original process environment still selects a single unrestricted index.

Every test request returns a useful answer. The missing production obligation is the boundary between business-unit corpora. The owner limits the first rollout to public manuals, assigns the knowledge-service team the corpus policy, and adds a negative test using two synthetic units. Internal notes remain outside the supported promise until that test and its deployment configuration agree.

The limited rollout is a concrete service, not a declaration that the entire assistant is ready. Its success does not justify silently adding sensitive sources later.

Put evidence beside each commitment

Use this boundary worksheet as the release discussion document. Replace the illustrative entries with local facts and attach an inspectable test or operating record to every accepted row.

Commitment	Illustrative decision	Acceptance evidence
User promise	Public-manual passages with source revision	Known-document and missing-source trials
Eligible callers	One analyst group, public corpus only	Group policy and rejected out-of-scope request
Service owner	Knowledge-service rotation	Reachable escalation and handoff record
Failure response	Explain unavailable corpus; no alternate private index	Dependency outage rehearsal
Capacity boundary	Eight concurrent lookups in the pilot	Saturation test and explicit refusal outcome
Supported clients	Two named host builds	Recorded protocol and tool-result checks
Suspension	Operator can remove this tool from the pilot	Disabled-tool trial from an existing host

The table is an operating proposal, not executable enforcement. A checked box without a corresponding deployed control remains an open item.

Keep transport evidence appropriately narrow

Verify the remote endpoint against the selected Streamable HTTP revision. Its validation rules are necessary implementation work, but a passing HTTP request should be attached only to the transport commitment it actually tests.

Keep data-boundary, usefulness, and support evidence separate in the worksheet. This makes missing evidence visible without requiring a large compliance document. It also prevents one successful demo from being reused as proof for every obligation.

Make the first rollout reversible in practice

Choose a cohort whose failures the team can investigate. Record its host builds, active catalog, corpus, limits, and owners before enabling it. Schedule a review of rejected requests, unavailable results, user corrections, and unclassified outcomes.

Rehearse suspension while the dependency is healthy. The host should still start, explain that the tool is unavailable, and retain understandable historical results. A stop button that only works after an administrator changes every user’s local configuration is an unresolved operating dependency.

Reopen the contract when the promise expands

New data classes, callers, write effects, remote providers, or recovery guarantees change the agreement even if the tool name stays constant. Review the changed rows and their evidence rather than treating the original launch decision as permanent permission.

For the measurable service promise, continue with MCP service-level denominators. For executable authority, use the separately owned agent tool-permission design.