MCP Primitives & Transports
CoreSelect the appropriate connection protocol: MCP, API/CLI, or agent-to-agent · Difficulty 3/5
Explanation
MCP (Model Context Protocol) is an open standard for exposing capabilities to any MCP Client. Its architectural value is what makes it the default choice for shared integrations, and understanding its primitives and transports is prerequisite to the protocol-selection decision covered in the companion concept below.
Build-Once, Reuse-Everywhere
MCP's value is build-once, reuse-everywhere: an MCP Server authored once is usable by many Claude applications and clients, and it is maintained on its own release cycle — independent of any single consuming application. This is fundamentally different from a direct API integration, where the integration logic is embedded in, and coupled to, one specific app.
MCP Primitives
MCP exposes three kinds of primitives to a connecting client:
| Primitive | What it is |
|---|---|
| Tools | Actions the model can invoke |
| Resources | Readable data/context the model can pull in |
| Prompts | Reusable prompt templates |
Tools from all configured MCP servers are made available simultaneously once a client connects, alongside any of the client's own built-in or directly-defined tools.
Transports
MCP supports two transport models depending on where the server runs:
- stdio — for a local subprocess, where the client and server run on the same machine.
- Streamable HTTP / sockets — for remote, multi-client servers that many consumers connect to over a network.
Stateful vs. Stateless Servers: The Scaling Question Streamable HTTP Raises
Moving to Streamable HTTP doesn't just change the wire format — it forces a real design decision an architect has to make explicitly: is the server stateful or stateless?
| Design | What it means | Where it breaks down |
|---|---|---|
| Stateful | The server holds session state (conversation context, in-progress operation state, cached per-client data) in its own memory, tied to a specific connection | Doesn't horizontally scale cleanly — a load balancer must route every request from a given client back to the *same* server instance ("sticky sessions"), or that client's state is lost |
| Stateless | Every request is fully self-contained; the server reads whatever state it needs from the request itself (or an external store) and any instance can handle it | None from a scaling standpoint — this is the design that scales horizontally behind a standard, non-sticky load balancer |
The decision isn't abstract — it follows directly from who is calling the server. An MCP Server backing a single-user local dev tool, reached over stdio or by exactly one Streamable HTTP client, can be stateful without consequence: there's only ever one caller, so there's no other instance to route to and no sticky-session problem to have. The moment that same server is reimagined as the backend for a multi-tenant SaaS product — serving thousands of concurrent agent sessions across many customers — statefulness stops being a convenience and becomes the thing standing between the architecture and horizontal scale. At that point the server needs either a stateless design (each request carries or derives everything it needs) or a stateful design with the session state externalized to a shared store (e.g., Redis) that every server instance can read, so any instance can still serve any client's next request without losing that client's state.
Common exam traps
- Assuming a stateful MCP Server is simply a worse choice in every case. It's the right, simplest choice for a single-client local tool — the failure mode only appears once multiple clients and multiple server instances enter the picture.
Key Takeaways
- MCP is an open standard exposing tools, resources, and prompts to any MCP client
- MCP's value is build-once, reuse-everywhere: authored once, used by many apps, maintained on its own release cycle
- stdio transport suits a local subprocess; Streamable HTTP/sockets suit remote, multi-client servers
- A stateful server holds per-client session state in memory and needs sticky routing; a stateless server treats each request independently and scales horizontally without it
- A single-user local dev tool can be stateful without issue; a multi-tenant SaaS product serving many concurrent sessions needs a stateless design or externalized session state (e.g., Redis) to scale behind a standard load balancer
Glossary Terms
An open standard protocol for connecting Claude to external tools and data sources. Defines a client-server architecture where MCP servers expose capabilities that MCP clients discover and use. Supports project-scoped (.mcp.json) and user-scoped configurations.
A process that implements the MCP protocol and exposes tools, resources, and prompts to MCP clients. Built with official SDKs (Python, TypeScript). Deployed locally via stdio or remotely via StreamableHTTP. Claude Code auto-discovers servers configured in .mcp.json.
An application that connects to MCP servers to access their tools, resources, and prompts. Responsible for tool-list filtering, tool_use_id routing, and enforcing which capabilities the model can call. Claude Code is the canonical MCP client in the CCA-F curriculum.
The three fundamental building blocks of the MCP protocol: Tools (model-controlled actions Claude can invoke), Resources (application-controlled data Claude can read), and Prompts (user-controlled templates for common interactions). Each serves a distinct control model.
The model-controlled MCP primitive. Claude autonomously decides when to invoke MCP tools based on task requirements. Distinct from Resources (app-controlled) and Prompts (user-invoked). The invocation path mirrors the API's native tool_use → tool_result exchange.
The application-controlled MCP primitive. The host application determines what data to provide to Claude by reading resources. Resources are identified by URIs and can be text, JSON, binary data, or template-generated content. Claude reads but does not autonomously request resources.
The user-controlled MCP primitive. Pre-defined prompt templates that users explicitly trigger via the application UI (e.g., a '/summarize' command). The user chooses when to apply them. Prompts can be parameterized and support autocomplete via the MCP completion endpoint.
An MCP transport mechanism where the client launches the server as a subprocess and communicates via stdin/stdout pipes. Ideal for local development and trusted single-user environments. Simple to set up but limited to same-machine deployment.
An MCP transport that communicates over HTTP with Server-Sent Events (SSE) for streaming. Runs as an independent network service — not a subprocess. Enables multiple simultaneous clients, per-request authentication, and remote deployment. The correct transport for shared, cloud-hosted, or containerised MCP servers.
Related Concepts