MCP Architecture Explained: Host, Client, Server, and Lifecycle

MCP architecture is a stateful host-client-server system built on JSON-RPC 2.0. The host owns consent, orchestration, and context aggregation. Each client maintains one isolated session with one server. The server exposes capabilities such as tools, resources, and prompts. That is the core shape.

This post is the technical companion to What Is MCP?. That overview answers what MCP is and why it matters. This page focuses on how the protocol actually behaves: lifecycle, negotiation, transport, message types, and where the real implementation bugs tend to show up.

The architecture in one diagram

The latest MCP architecture specification defines exactly this split and makes one important point explicit: the host can run multiple client instances, but each client maintains a 1:1 relationship with a single server.

The four responsibilities that matter

Host

The host is the application the user is actually in. According to the latest architecture spec, the host:

• creates and manages client instances
• controls permissions and lifecycle
• enforces security policies and consent
• coordinates LLM integration
• aggregates context across clients

This is why the host is where most trust and safety decisions belong.

Client

The client is the protocol connector inside the host. The spec says each client establishes one stateful session per server, handles protocol negotiation, routes messages bidirectionally, manages notifications, and maintains security boundaries between servers.

That 1:1 relationship is easy to miss, but it explains a lot about MCP's simplicity. There is no giant shared bus where all servers see everything.

Server

The server exposes focused capabilities. In the same architecture spec, servers provide tools, resources, and prompts, can be local processes or remote services, and must respect security constraints.

The server should stay narrow. The host handles orchestration complexity so the server can focus on one domain cleanly.

Transport

The transport moves JSON-RPC messages between the client and the server. The latest transports spec defines two standard options:

• stdio
• Streamable HTTP

That transport layer is intentionally separate from the protocol semantics.

The base protocol: JSON-RPC and stateful sessions

The latest MCP specification says MCP uses JSON-RPC 2.0 messages and stateful connections. JSON-RPC itself gives you three message types:

• requests
• responses
• notifications

The official JSON-RPC 2.0 specification defines a notification as a request object without an id, which means no response is expected.

That maps cleanly to MCP. For example:

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Berlin"
    }
  }
}

And a progress notification can be sent without an id because it is fire-and-forget.

Why people compare MCP to LSP

The latest MCP spec explicitly says MCP takes inspiration from the Language Server Protocol. LSP standardized communication between editors and language servers so the same server could work across multiple development tools. MCP applies the same kind of standardization to AI applications and external capabilities.

That does not make MCP "LSP for AI" in every detail, but it is the right architectural analogy.

Lifecycle: initialize, operate, shut down

The latest lifecycle spec defines three phases:

1. initialization
2. operation
3. shutdown

Initialization

Initialization is mandatory and must happen first. The client sends an initialize request containing:

• the protocol version it supports
• client capabilities
• client implementation info

The server responds with its protocol version, capabilities, and server info. After that, the client sends notifications/initialized.

This is not ceremony for its own sake. It is how version agreement and capability negotiation happen.

Operation

During normal operation, both sides must respect the negotiated protocol version and only use capabilities that were successfully negotiated.

This is where calls such as tools/list, tools/call, resources/list, resources/read, prompts/list, and prompts/get happen.

Shutdown

MCP does not define a special shutdown message. The transport closes. For stdio, the client typically closes the child process input stream and waits for exit. For HTTP, shutdown is the end of the associated connection.

Capability negotiation is not optional fluff

Capability negotiation is one of the most important architectural details in MCP.

The latest architecture and lifecycle specs say clients and servers explicitly declare supported features during initialization. Server capabilities can include prompts, resources, tools, logging, or completions. Client capabilities can include roots, sampling, and elicitation.

Why this matters:

• a server should not assume the client supports every optional feature
• a client should not call capabilities the server never advertised
• most subtle incompatibility bugs start here

If a tool exists but the server did not advertise tool capability correctly, the rest of your implementation can be perfect and the host still will not use it.

The three server features and who controls them

The server concepts guide is useful because it distinguishes not only what the three features are, but who generally controls them.

That distinction is easy to skip, but it matters when you design your server.

Tools

Tools are callable operations. The same server concepts guide says tools are schema-defined interfaces that LLMs can invoke and that they may require user consent before execution.

Resources

Resources are passive context. They expose readable material like documents, knowledge bases, or schemas.

Prompts

Prompts are user-invoked templates. The docs explicitly say prompts are user-controlled and require explicit invocation, which is an important difference from tools.

If you only remember one design rule, remember this: do not cram everything into tools just because they are the most visible feature.

Transports: local versus remote

The latest transports spec says MCP currently defines two standard transport mechanisms:

1. stdio
2. Streamable HTTP

stdio

Use stdio when the host launches the server as a subprocess. The server reads JSON-RPC messages from stdin and writes valid MCP messages to stdout.

This is the local-server pattern.

Streamable HTTP

Use Streamable HTTP when the server is remote and reachable over the network. One subtle but current detail is worth calling out: the latest spec says Streamable HTTP replaces the older HTTP+SSE transport from protocol version 2024-11-05. If you are reading older MCP tutorials, that is one of the first places terminology drift shows up.

Security boundaries are part of the architecture

The latest architecture spec says servers should not be able to read the whole conversation or see into other servers. Full conversation history stays with the host, and the host enforces the security boundaries.

The latest MCP specification adds the trust and safety principles on top:

• user consent and control
• data privacy
• tool safety
• sampling controls

One practical production note matters here too. OpenAI's current MCP guide warns that custom MCP servers still carry prompt-injection and write-action risks, recommends preferring official servers from the underlying provider, and notes that ChatGPT currently requires manual confirmation before write actions.

The protocol architecture helps a lot. It does not magically remove trust and safety work.

Where integration bugs actually happen

This next section is an implementation inference from the protocol, not a verbatim claim from the spec. In practice, MCP bugs cluster around boundaries:

• initialization never fully completes
• capabilities are not advertised correctly
• transport assumptions differ between client and server
• tool schemas are valid JSON but poor for model use
• UI behavior is assumed even though the host does not support it

That is why debugging MCP usually means checking lifecycle and negotiation first before you blame the tool handler itself.

If your goal is richer rendering rather than low-level debugging, go to Building MCP Tools with Rich UIs.

Summary

MCP architecture is a host-client-server system built on JSON-RPC 2.0 and stateful sessions. The host manages consent and orchestration. Each client maintains one isolated connection to one server. The server exposes tools, resources, and prompts. Initialization and capability negotiation determine what can happen during the session, while stdio and Streamable HTTP define how messages move.

If you understand those layers and boundaries, most of the protocol becomes much easier to reason about.

FAQ

What is MCP architecture in one sentence?

It is a stateful host-client-server architecture where the host manages one or more clients, each client maintains an isolated session with one server, and servers expose capabilities over JSON-RPC.

Why does MCP use JSON-RPC?

JSON-RPC provides a simple request, response, and notification model that fits capability invocation and protocol coordination well. The MCP spec adopts it as the message format for the base protocol.

What is the difference between host and client in MCP?

The host is the user-facing application and policy owner. The client is the protocol connector inside that host that maintains a session with a specific server.

What are the three core server features in MCP?

The three core server features are tools, resources, and prompts.

What transport should I start with?

Start with stdio for local development or local integrations. Use Streamable HTTP when the server needs to be remote and shareable across users or systems.

If you want to build against the protocol without hand-rolling every transport and lifecycle detail yourself, go from here to the build server guide or take the faster product path with drio's docs.