MCP Server Architecture
The Model Context Protocol standardizes how an AI app connects to external capability. This page is the system architecture — the host/client/server roles, transports, primitives, and lifecycle. The why a standard wins argument lives in MCP as the Integration Standard.
MCP follows a client-server model with three roles. A host is the AI application (Claude Desktop, Cursor, a Dedalus agent). Inside the host, one client is instantiated per server, holding a 1:1 stateful session. A server is a separate program exposing capability over the protocol. The host orchestrates; clients speak MCP; servers do the work. Decoupling client from server is what makes "build a server once, use it in every host" real. Source: compiled from modelcontextprotocol.io
Transports
- stdio — the server runs as a local subprocess; the host talks over stdin/stdout. Lowest latency, no network, ideal for local tools/filesystems.
- Streamable HTTP (with SSE) — the server is a remote HTTP service; requests are POSTed and the server streams responses/notifications over SSE. The shape for hosted, multi-user servers.
All messages are JSON-RPC 2.0 (requests, responses, notifications), so transport and message format are cleanly separated.
The three server primitives
| Primitive | Controlled by | Purpose |
|---|---|---|
| Tools | Model | Actions the agent can invoke (search, write, call an API) — see Tool-Calling Design |
| Resources | Application | Readable context (files, records) the host can attach |
| Prompts | User | Reusable templated workflows the user can trigger |
The split is deliberate: model-controlled vs app-controlled vs user-controlled capability, each surfaced and gated differently.
Lifecycle
Connection opens with an initialize handshake that negotiates protocol version and capabilities, so a host only uses what a server actually supports. Then the host discovers primitives (tools/list, etc.) and invokes them; servers can push notifications (e.g. list changed) mid-session.
Design implications
- One client per server, stateful. Session state lives in the client; a flaky server connection drops just that capability, not the host.
- Capability negotiation prevents version cliffs — old host + new server still interoperate at the agreed level.
- The server still owns tool quality. MCP standardizes transport/discovery, not whether a tool is well-designed (Tool-Calling Design); a bad tool over MCP is still a bad tool.
- Remote servers need gateway concerns — auth, rate limiting, multi-tenancy at the edge (API Gateway Architecture).
This is the protocol layer under Kevin's Dedalus model-agnostic, MCP-powered SDK and the Agent System: agents compose external capability through MCP rather than N bespoke integrations, and Kevin's own wiki is reachable as an MCP server (qmd).
Architecture Position
| Axis | Value |
|---|---|
| Family | Agent runtime and control plane |
| Boundary owned | MCP server transports, primitives, lifecycle, and capability exposure. |
| Read with | Tool Execution Runtime Architecture, Agent Harness Architecture, API Gateway Architecture |
| Use this page when | exposing tools/data to AI clients through MCP |
Timeline
-
2026-07-01 | Architecture category refresh added this page to the Agent runtime and control plane family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: MCP server transports, primitives, lifecycle, and capability exposure. Source: User request, 2026-07-01
-
2026-06-02 | Page created. Captured the host/client/server roles, stdio vs Streamable-HTTP transports over JSON-RPC, the tools/resources/prompts primitive split by controller, the initialize→discover→use lifecycle with capability negotiation, and the Dedalus grounding. Source: compiled from modelcontextprotocol.io