Chapter 43 MCP: Stable Interoperability Concepts and Version Boundaries

43.1 The read works. Must every application invent another adapter?

One assistant calls get_order(order_id). Another expects a URL and a JSON body. A third needs a list of available operations before it can offer any of them. If each application and service invents a private description and exchange format, integrating three applications with four services can require up to $3\times4=12$ custom pairwise adapters.

A shared interface can instead give each application a compatible client and each service a compatible server surface: three plus four, or seven implementation boundaries in this idealized example. This is an authored integration-count comparison, not a measurement of development effort. Different authentication policies and business meanings still require work.

Model Context Protocol (MCP) addresses this interoperability problem. It specifies how applications exchange capabilities, requests and results with servers. It is neither a language model nor the function that reads an order. It also does not decide whether the user should ask for another operation.

43.2 Locate the host, client and server

Example 43.1 — Wrap the existing executor. The knowledge-assistant application is the host: it manages the user interaction, model integration and permission policy. Inside it, an MCP client speaks the protocol to a server. The MCP server exposes the order tool and delegates the actual read to Chapter 42’s executor. “Server” describes this interface role; the process can be on the same computer.

Request path

1. Outside the modelHost: permission policy
2. Text piecesClient: protocol request
3. An operationServer: decode + dispatch
4. Outside the modelSame read executor

Protocol compatibility does not add a cancellation operation.

Return path

1. Outside the modelRecord or forbidden
2. Text piecesCorrelated protocol result
3. An operationHost validates and packs

A complete protocol result can carry a business failure.

Figure 43.1 — A common protocol preserves the business boundary. Original teaching diagram · CC BY-SA 4.0

Figure 43.1 separates protocol handling from business access. The application principal is mira because the trusted fixture configuration says so. A client name in a request is self-reported diagnostic information, not proof of identity. A server description saying “trusted order service” cannot grant access to another owner’s order.

Table 43.1 — Three kinds of exposed information.

Concept	Example in this project family	What receiving it does not do
Tool	A callable order query with an argument schema	Grant permission or prove it has already run
Resource	Addressable policy text with a URI and content	Automatically retrieve the best passage or insert it into model input
Prompt	A reusable, parameterized message template	Become a higher-priority trusted instruction merely by arriving from a server

These categories distinguish operations, data and templates. A server need not implement all three. Our minimal server exposes only the tool. Chapter 40’s template could be distributed as a prompt and Chapter 45’s documents as resources, but that would be an additional implementation, not something we claim the current adapter already does. Discovery tells the host what the server offers; the host still chooses what to expose and use.

43.3 A transport is not an authorization policy

A transport carries messages. The local practice uses standard input/output, or stdio: the host starts a child process, writes one JSON-RPC message per line and reads its replies. JSON-RPC attaches a request ID so a response can be matched to its request. Diagnostic logging belongs on standard error, not mixed into the message stream.

Remote deployments can use the protocol’s HTTP transport. The HTTP Primer explains its underlying requests, responses and streaming. Authentication establishes the credential’s identity; authorization decides which operations and records it may access. The HTTP authorization framework belongs at that boundary, while row-level ownership checks still belong to the application/service. Our stdio fixture does not implement remote OAuth or claim to validate real identities.

Protocol success is also distinct from tool success. The server can understand a request perfectly and report that access was forbidden. Conversely, a protocol error can prevent the tool from being reached at all. A successful tool result is data for the host; the host must validate it and apply Chapter 40’s trust rules before using it as context.

43.4 Dated implementation layer: 2026-09-14

This section and docs/part-vii-online.md pin the formal revision 2026-07-28, verified on 2026-09-14. These are versioned implementation facts, not timeless definitions of MCP. The current base protocol supplies version and client capabilities on each request. It does not require the old initialization handshake. Our client performs discovery for inspection, then lists and calls the tool; discovery is optional for clients but implemented by servers in this revision.

Example 43.2 — One complete wire exchange. Whitespace is expanded here; the actual stdio message occupies one line. ID 3 links this response to this request, not to order A-104 and not to an approval. The empty capabilities object declares no optional client facilities.

{
  "jsonrpc":"2.0",
  "id":3,
  "method":"tools/call",
  "params":{
    "name":"get_order",
    "arguments":{"order_id":"A-104"},
    "_meta":{
      "io.modelcontextprotocol/protocolVersion":"2026-07-28",
      "io.modelcontextprotocol/clientCapabilities":{},
      "io.modelcontextprotocol/clientInfo":{"name":"book-host","version":"1.0.0"}
    }
  }
}

{
  "jsonrpc":"2.0",
  "id":3,
  "result":{
    "resultType":"complete",
    "_meta":{"io.modelcontextprotocol/serverInfo":{"name":"book-orders","version":"1.0.0"}},
    "content":[{"type":"text","text":"{\"order_id\":\"A-104\",\"status\":\"processing\",\"as_of\":\"2026-09-14T00:00:00Z\",\"source_version\":\"ka3-orders-v1\"}"}],
    "structuredContent":{"order_id":"A-104","status":"processing","as_of":"2026-09-14T00:00:00Z","source_version":"ka3-orders-v1"},
    "isError":false
  }
}

The structured content is produced by server code. It is not schema-constrained LLM generation. The text block serializes the same object for consumers using text content. The host checks their agreement, correlation and business fields; a familiar tool name is not enough.

Table 43.2 — Actual subprocess trace outcomes.

Request ID	Request	Response and interpretation
1	Discover server	Supported revision 2026-07-28, tools capability, book-orders 1.0.0
2	List tools	Only get_order; one required order_id; read-only annotation
3	Read A-104	Complete protocol result; processing snapshot; no tool error
4	Read B-205 as mira	Complete protocol result carrying a forbidden tool error
5	Propose cancel_order	Invalid-parameter protocol error, code -32602; no such tool

data/part-vii/mcp-run.json retains every complete request and response, produced by a real child process. The host closes its input and waits for shutdown; the practice enforces a five-second process deadline. It uses no SDK and claims only this tested synchronous read subset, not full protocol conformance, subscriptions or remote deployment.

43.5 Version boundaries prevent false compatibility

An older tutorial may start with initialize and initialized. Those belong to older protocol revisions. The pinned server rejects missing required request metadata and rejects unsupported versions with the formal version-error shape. Supporting an older client would require a separately tested compatibility path; blindly adding its handshake to every new exchange is not a neutral repair.

The official deprecation registry also distinguishes deprecated from removed. Roots, Sampling, Logging and Dynamic Client Registration are deprecated in the pinned revision, with specified migration paths and earliest removal dates. We do not build the stable explanation around them. The older HTTP+SSE transport has a separate deprecation history; this does not mean that all uses of server-sent events have disappeared. The online notes retain the exact registry distinctions and scope.

Even a stateless protocol can access a stateful order database. Here “stateless” concerns the protocol information needed to interpret each request; it does not mean orders never change, nor that an open connection is the user’s conversation memory.

43.6 KA-3: interoperability without extra authority

mcp_readonly.py wraps the same execute and lookup used by the local Tool and HTTP examples. Run its demonstration or the corresponding Notebook cells. Tests check discovery, response IDs, request metadata, unknown methods, malformed arguments, version rejection, forbidden ownership and equality between text and structured results. The snapshot remains unchanged.

MCP does not add retrieval ranking, grounded generation, multi-step planning or business approval. It can carry a retriever as a tool, but that retriever still needs a ranking rule and evaluation set. That is the next problem: among the policy documents we are allowed to read, which ones actually help answer the question?

43.7 Summary

MCP gives hosts and servers a shared interface through clients. Tools, resources and prompts expose different things; transport and authorization solve different problems. The versioned local adapter establishes one read exchange, not a model, RAG system or autonomous agent. Compatibility must be tied to a verified revision and tested scope.

43.8 Exercises

1. A request declares its client name to be administrator. Should the server let it read B-205? Identify the missing evidence.
2. A host lists a policy resource. Has the model received the policy, and has the best passage been selected? Describe what remains.
3. ID 4 returns a complete result with a forbidden tool error. Is that the same failure as ID 5’s unknown-tool error? Locate both.
4. An engineer says “MCP is stateless, so we cannot support changing order status.” Explain the confusion. Another says “MCP is installed, so we now have RAG.” Explain that confusion too.

43.9 Reference answers

1. No. Self-reported client metadata is not authentication or ownership. The server needs a trusted principal and authorization for the requested record. The local fixture remains mira regardless of the client name.
2. Neither follows. Listing advertises availability; reading obtains content. A retriever selects relevant passages, and the host packs chosen evidence into actual model input. These steps require explicit application behavior.
3. No. ID 4 reaches a known operation whose business authorization fails; the protocol carries that failure as tool-result data. ID 5 names no exposed tool and fails at the protocol/interface boundary. Neither executes cancellation.
4. Per-request protocol metadata removes dependence on a preceding protocol session; application records may still change. Similarly, protocol interoperability supplies no indexing, ranking, evidence packing or answer-support check. Those components are needed for RAG.

43.10 References

• MCP specification 2026-07-28, architecture and security principles. Locates hosts, clients, servers and their trust responsibilities.
• Base protocol, stdio, discovery and tools. Define the dated wire exchange and result distinctions.
• Versioning and Compatibility and Deprecated Features, verified 2026-09-14. Establish compatibility and deprecation boundaries; the implementation does not silently mix eras.