MCP Architecture Explained: Hosts, Clients, Servers & Production Patterns
Before the Model Context Protocol (MCP), connecting an AI agent to external capabilities was a fragmented, labor-intensive exercise. Every integration required custom code. Want your agent to read a file? Write a filesystem connector. Need it to query a database? Build a database adapter. Call a GitHub API? Another custom integration. Each connector had its own authentication scheme, its own error handling, its own data format.
The result was a proliferation of bespoke integrations that were:
- Brittle: Every API change broke the integration
- Non-portable: Integrations written for one agent couldn't be reused by another
- Hard to secure: Each integration implemented security differently
- Expensive to maintain: The N×M problem—N agents × M tools = N×M integrations
┌─────────┐ ┌─────────────────────────────────────────────────────────────┐
│ │ │ Custom Integration 1 │ Different APIs │ Different Auth │
│ AI │────▶│ Custom Integration 2 │ Different APIs │ Different Auth │
│ Agent │────▶│ Custom Integration 3 │ Different APIs │ Different Auth │
│ │────▶│ Custom Integration 4 │ Different APIs │ Different Auth │
└─────────┘ └─────────────────────────────────────────────────────────────┘
Figure 1: The pre-MCP integration problem—each agent-to-tool connection required custom code.
MCP solves this problem by introducing a standardized integration architecture. Write an MCP server once, and any MCP-speaking client can discover and use its capabilities. The protocol handles discovery, capability negotiation, and communication, leaving developers to focus on what matters: building the actual capabilities.
MCP Architecture at a Glance
MCP follows a client-host-server architecture where each host can run multiple client instances. This architecture enables users to integrate AI capabilities across applications while maintaining clear security boundaries and isolating concerns.
The Three Participants
| Component | Responsibility | Examples |
|---|---|---|
| MCP Host | The AI application that coordinates and manages one or multiple MCP clients | Claude Desktop, Claude Code, custom AI applications, IDEs |
| MCP Client | A component that maintains a connection to an MCP server and obtains context for the host to use | SDK client instances created by the host |
| MCP Server | A program that provides context and capabilities to MCP clients | Filesystem server, Database server, GitHub server, Sentry server |
Architecture Diagram
┌─────────────────────────────────────────────────────────────────────────────┐
│ MCP Host │
│ (AI Application / Agent Runtime) │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ User Interface │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ LLM Integration │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────┼──────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ MCP Client │ │ MCP Client │ │ MCP Client │ │
│ │ (Server A) │ │ (Server B) │ │ (Server C) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
└─────────┼──────────────────────────┼──────────────────────────┼─────────────┘
│ │ │
│ JSON-RPC │ JSON-RPC │ JSON-RPC
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ MCP Server │ │ MCP Server │ │ MCP Server │
│ (Local) │ │ (Remote) │ │ (Local) │
│ stdio │ │ HTTP │ │ stdio │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Filesystem │ │ Database │ │ GitHub │
│ Tools │ │ Resources │ │ Prompts │
└─────────────┘ └─────────────┘ └─────────────┘
Figure 2: MCP architecture showing a Host with multiple Clients, each connecting to a different Server.
The Two Layers
MCP consists of two distinct layers:
-
Data Layer: Defines the JSON-RPC-based protocol for client-server communication, including lifecycle management, and core primitives such as tools, resources, prompts, and notifications.
-
Transport Layer: Defines the communication mechanisms and channels that enable data exchange between clients and servers, including transport-specific connection establishment, message framing, and authorization.
Design Principles
MCP is built on several key design principles that inform its architecture:
- Servers should be extremely easy to build: Host applications handle complex orchestration; servers focus on specific, well-defined capabilities
- Servers should be highly composable: Each server provides focused functionality in isolation; multiple servers can be combined seamlessly
- Servers should not be able to read the whole conversation: Servers receive only necessary contextual information; full conversation history stays with the host
- Features can be added progressively: Core protocol provides minimal required functionality; additional capabilities can be negotiated as needed
MCP Host
The Host is the AI application that coordinates and manages one or multiple MCP clients. It is the application users interact with directly—Claude Desktop, Claude Code, an IDE, or a custom AI application.
Role of the Host
The host process acts as the container and coordinator:
- Creates and manages multiple client instances: The host creates one MCP client for each MCP server it needs to connect to
- Controls client connection permissions and lifecycle: The host decides when to connect, disconnect, and reconnect
- Enforces security policies and consent requirements: The host handles user authorization decisions
- Coordinates AI/LLM integration and sampling: The host manages how LLM responses are generated and how context is provided
- Manages context aggregation across clients: The host collects and combines context from multiple MCP servers
Host vs. Server
A common point of confusion is the distinction between Host and Server. The Host is the application that consumes capabilities; the Server is the program that provides them. The Host creates Clients to communicate with Servers.
┌─────────────────┐ ┌─────────────────┐
│ │ │ │
│ MCP Host │────── creates ────▶│ MCP Client │
│ (Consumer) │ │ (Connector) │
│ │ │ │
└─────────────────┘ └────────┬────────┘
│
│ communicates
▼
┌─────────────────┐
│ │
│ MCP Server │
│ (Provider) │
│ │
└─────────────────┘
Figure 3: The Host-Clients-Servers relationship—Hosts consume, Servers provide.
Host Responsibilities in Depth
Session Management: The Host manages the lifecycle of each Client connection. When the Host starts, it may initialize multiple Clients. When the Host shuts down, it gracefully closes all Client connections.
User Interaction: The Host is responsible for presenting MCP capabilities to users. This includes showing available tools, resources, and prompts, and handling user consent for tool execution.
Model Integration: The Host integrates with one or more LLMs, deciding which context from which MCP servers to include in prompts, and how to handle tool calls from the model.
Policy Enforcement: The Host enforces security policies, including what tools can be called, what resources can be read, and what prompts can be used.
MCP Client
The MCP Client is a component that maintains a connection to an MCP server and obtains context from the MCP server for the MCP host to use. Clients are instantiated by host applications to communicate with particular MCP servers.
Client Responsibility
Each client is created by the host and communicates with exactly one server. The client:
- Establishes one stateful session per server
- Handles protocol negotiation and capability exchange
- Routes protocol messages bidirectionally
- Manages subscriptions and notifications
- Maintains security boundaries between servers
Connection Management
The Client is responsible for establishing and managing the connection to its Server:
- Transport setup: Configures the appropriate transport (stdio, Streamable HTTP)
- Connection establishment: Initiates the connection to the Server
- Lifecycle management: Handles initialization, capability negotiation, and shutdown
- Reconnection: Manages reconnection attempts on failure
Multiple Clients in a Host
A Host can manage multiple Clients simultaneously, each connected to a different Server:
┌─────────────────────────────────────────────────────────────────────────────┐
│ MCP Host │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ MCP Client │ │ MCP Client │ │ MCP Client │ │ MCP Client │ │
│ │ (GitHub) │ │ (Database) │ │ (Filesystem)│ │ (Search) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │ │
└─────────┼────────────────┼────────────────┼────────────────┼───────────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ GitHub │ │ Database │ │ Filesystem │ │ Search │
│ Server │ │ Server │ │ Server │ │ Server │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
Figure 4: A Host managing multiple Clients, each connected to a different Server.
Client-Side Features
MCP Clients can support several optional features:
- Sampling: The ability to make LLM sampling requests to the Host
- Elicitation: The ability to request additional information from users
- Roots: The ability to provide filesystem root information (deprecated as of protocol version 2026-07-28)
- Notifications: The ability to receive and process server notifications
MCP Server
The MCP Server is a program that provides context and capabilities to MCP clients. Servers provide specialized context and capabilities.
Server Responsibility
Servers are responsible for:
- Exposing resources, tools, and prompts via MCP primitives
- Operating independently with focused responsibilities
- Requesting client input (sampling, elicitation, roots) via InputRequiredResult within a reply
- Respecting security constraints
- Operating as local processes or remote services
Server Design Principles
MCP servers are designed to be:
- Easy to build: Simple interfaces minimize implementation overhead
- Focused: Each server provides specific, well-defined capabilities in isolation
- Composable: Multiple servers can be combined seamlessly
- Isolated: Servers cannot read the whole conversation or "see into" other servers
- Independent: Servers evolve independently; features can be added progressively
Server Primitives
Servers expose three core primitives:
| Primitive | Control | Description | Example |
|---|---|---|---|
| Tools | Model-controlled | Executable functions that allow models to take actions | read_file, query_database, create_issue |
| Resources | Application-controlled | Contextual data attached and managed by the client | File contents, database schemas, API documentation |
| Prompts | User-controlled | Pre-defined templates or instructions that guide language model interactions | "Summarize", "Code review", "Generate report" |
Local vs. Remote Servers
MCP servers can run locally or remotely:
-
Local MCP servers use the stdio transport and typically serve a single MCP client. Example: the filesystem server launched by Claude Desktop.
-
Remote MCP servers use the Streamable HTTP transport and typically serve many MCP clients. Example: the official Sentry MCP server.
MCP Architecture Components
| Component | Responsibility | Examples |
|---|---|---|
| Host | Coordinates AI application, manages Clients, enforces security, handles user consent | Claude Desktop, Claude Code, custom AI apps, IDEs |
| Client | Maintains connection to one Server, handles protocol negotiation, routes messages | SDK client instances, language-specific client implementations |
| Server | Exposes capabilities (tools, resources, prompts), operates independently, respects security constraints | Filesystem server, Database server, GitHub server, Sentry server |
| Tool | Executable function that allows models to take actions | read_file, query_database, create_issue, send_email |
| Resource | Contextual data that provides additional context to the model | File contents, database schemas, API documentation, logs |
| Prompt | Pre-defined template that guides language model interactions | "Summarize this text", "Review this code", "Generate a report" |
MCP Communication Model
All messages between MCP clients and servers MUST follow the JSON-RPC 2.0 specification.
Message Types
MCP defines three types of messages:
1. Requests: Sent from the client to the server (or vice versa) to initiate an operation.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}
- Requests MUST include a string or integer ID
- The ID MUST NOT be null
- The request ID MUST NOT match the ID of any other request the sender has issued and not yet received a response for
2. Responses: Sent in reply to requests, containing either the result or error of the operation.
Result Response:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resultType": "complete",
"tools": [...]
}
}
- Result responses MUST include the same ID as the request they correspond to
- Result responses MUST include a
resultfield - The
resultMUST include aresultTypefield to indicate the type of the result resultTypevalues include: "complete" (operation succeeded) and "input_required" (more information needed)
Error Response:
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32000,
"message": "Tool execution failed"
}
}
- Error responses MUST include the same ID as the request they correspond to
3. Notifications: Sent from the client to the server (or vice versa) without expecting a response.
{
"jsonrpc": "2.0",
"method": "notifications/initialized"
}
- Notifications MUST NOT include an ID
Message Correlation
MCP uses request IDs to correlate requests with responses. Each request includes a unique ID, and the corresponding response includes the same ID. This allows multiple requests to be in flight simultaneously.
Communication Flow
┌──────────┐ ┌──────────┐
│ Client │ │ Server │
└────┬─────┘ └────┬─────┘
│ │
│ 1. initialize request │
│────────────────────────────────────────▶│
│ │
│ 2. initialize response │
│◀────────────────────────────────────────│
│ │
│ 3. initialized notification │
│────────────────────────────────────────▶│
│ │
│ 4. tools/list request │
│────────────────────────────────────────▶│
│ │
│ 5. tools/list response │
│◀────────────────────────────────────────│
│ │
│ 6. tools/call request │
│────────────────────────────────────────▶│
│ │
│ 7. tools/call response │
│◀────────────────────────────────────────│
│ │
Figure 5: MCP communication flow showing request-response pairs and notifications.
MCP Lifecycle
MCP defines a rigorous lifecycle for client-server connections that ensures proper capability negotiation and state management.
Lifecycle Phases
1. Initialization
The initialization phase MUST be the first interaction between client and server. During this phase, the client and server:
- Establish protocol version compatibility
- Exchange and negotiate capabilities
- Share implementation details
The client initiates this phase by sending an initialize request:
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2026-07-28",
"capabilities": {
"sampling": {},
"elicitation": {}
},
"clientInfo": {
"name": "ExampleClient",
"version": "1.0.0"
}
}
}
The server MUST respond with its own capabilities and information:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2026-07-28",
"capabilities": {
"logging": {},
"prompts": { "listChanged": true },
"resources": { "subscribe": true, "listChanged": true },
"tools": { "listChanged": true }
},
"serverInfo": {
"name": "ExampleServer",
"version": "1.0.0"
}
}
}
Version Negotiation: In the initialize request, the client MUST send a protocol version it supports. If the server supports the requested version, it responds with the same version. Otherwise, it responds with another version it supports. If the client does not support the version in the server's response, it SHOULD disconnect.
2. Capability Negotiation
Client and server capabilities establish which optional protocol features will be available during the session.
Key capabilities include:
| Category | Capability | Description |
|---|---|---|
| Client | roots | Ability to provide filesystem roots |
| Client | sampling | Support for LLM sampling requests |
| Client | elicitation | Support for elicitation requests |
| Server | logging | Ability to log messages |
| Server | prompts | Support for prompt templates |
| Server | resources | Support for resources with subscriptions |
| Server | tools | Support for tools |
3. Normal Operation
After successful initialization, the client MUST send an initialized notification to indicate it is ready to begin normal operations:
{
"jsonrpc": "2.0",
"method": "notifications/initialized"
}
During normal operation:
- The client SHOULD NOT send requests other than pings before the server has responded to the initialize request
- The server SHOULD NOT send requests other than pings and logging before receiving the initialized notification
4. Shutdown
Graceful termination of the connection. Both parties should clean up resources and close the connection.
Lifecycle Sequence Diagram
┌──────────┐ ┌──────────┐
│ Client │ │ Server │
└────┬─────┘ └────┬─────┘
│ │
│ 1. initialize (version + capabilities) │
│────────────────────────────────────────▶│
│ │
│ 2. initialize response │
│ (version + server capabilities) │
│◀────────────────────────────────────────│
│ │
│ 3. initialized notification │
│────────────────────────────────────────▶│
│ │
│ ──── Normal Operation ──── │
│ │
│ 4. tools/list │
│────────────────────────────────────────▶│
│ │
│ 5. tools/list response │
│◀────────────────────────────────────────│
│ │
│ 6. tools/call │
│────────────────────────────────────────▶│
│ │
│ 7. tools/call response │
│◀────────────────────────────────────────│
│ │
│ 8. (Optional) shutdown │
│────────────────────────────────────────▶│
│ │
Figure 6: MCP lifecycle sequence diagram showing initialization, capability negotiation, normal operation, and shutdown.
Capability Negotiation
MCP uses a capability-based negotiation system where clients and servers declare their supported features. Capabilities determine which protocol features and primitives are available during a session.
How Capability Negotiation Works
- Client declares capabilities in the
initializerequest - Server declares capabilities in the
initializeresponse - Both parties respect declared capabilities throughout the interaction
- Additional capabilities can be negotiated through extensions to the protocol
Server Capabilities
Servers declare capabilities like:
- Tool support: Whether the server provides tools
- Resource subscriptions: Whether the server supports resource change notifications
- Prompt templates: Whether the server provides prompt templates
- Logging: Whether the server supports logging
Client Capabilities
Clients declare capabilities like:
- Sampling support: Whether the client can make LLM sampling requests
- Elicitation handling: Whether the client can handle elicitation requests
- Roots support: Whether the client can provide filesystem roots
Capability Negotiation Example
Client capabilities in initialize request:
"capabilities": {
"sampling": {},
"elicitation": {},
"roots": { "listChanged": true }
}
Server capabilities in initialize response:
"capabilities": {
"logging": {},
"prompts": { "listChanged": true },
"resources": { "subscribe": true, "listChanged": true },
"tools": { "listChanged": true }
}
This exchange establishes that the client supports sampling and elicitation, while the server provides tools, resources, and prompts.
MCP Tools Architecture
Tools are executable functions that allow models to take actions. They are the primary way agents interact with external systems.
Tool Discovery
Clients can discover available tools through the tools/list endpoint. MCP supports dynamic tool discovery—clients can list available tools at any time.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list"
}
Response:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "read_file",
"description": "Read the contents of a file",
"inputSchema": {
"type": "object",
"properties": {
"path": { "type": "string", "description": "Path to the file" }
},
"required": ["path"]
}
}
]
}
}
Tool Invocation
Tools are called using the tools/call endpoint, where servers perform the requested operation and return results.
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": {
"path": "/path/to/file.txt"
}
}
}
Tool Architecture
┌─────────────────────────────────────────────────────────────────────────────┐
│ MCP Host │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ LLM │ │
│ │ "I need to read the file /path/to/file.txt" │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Tool Selection │ │
│ │ Finds tool "read_file" in available tools │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ MCP Client │ │
│ │ Sends tools/call request to Server │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
└────────────────────────────────────┼────────────────────────────────────────┘
│
▼
┌─────────────┐
│ MCP Server │
│ │
│ read_file │
│ function │
└──────┬──────┘
│
▼
┌─────────────┐
│ Filesystem │
└─────────────┘
Figure 7: Tools architecture—the LLM selects a tool, the Client invokes it via the Server.
Tool Annotations
Tools can include annotations that provide additional metadata:
- Read-only hints: Indicate whether a tool modifies state
- Destructive hints: Indicate whether a tool performs destructive operations
- Idempotent hints: Indicate whether a tool can be safely retried
MCP Resources Architecture
Resources are structured data or content that provides additional context to the model. Unlike tools, resources are application-controlled—the client decides what resources to attach to the model.
Resource Discovery
Resources are identified by URIs and can be discovered through the resources/list endpoint.
{
"jsonrpc": "2.0",
"id": 1,
"method": "resources/list"
}
Resource Reading
Resources are read using the resources/read endpoint with the resource URI.
{
"jsonrpc": "2.0",
"id": 2,
"method": "resources/read",
"params": {
"uri": "file:///path/to/document.txt"
}
}
Resource Templates
For open-ended sets of resources (e.g., one resource per customer), servers can expose URI templates using RFC 6570 syntax.
file:///{path}
git+https://{repo}/{ref}/{path}
db://users/{user_id}
Templates allow dynamic URI-based resources with variable substitution. The server does not expand templates; clients call resources/templates/list, expand the template client-side, then call resources/read.
Resources vs. Tools
| Aspect | Resources | Tools |
|---|---|---|
| Control | Application-controlled | Model-controlled |
| Purpose | Provide context | Perform actions |
| Side effects | No side effects | May have side effects |
| Discovery | resources/list | tools/list |
| Invocation | resources/read | tools/call |
MCP Prompts Architecture
Prompts are pre-defined templates or instructions that guide language model interactions. They are user-controlled and allow servers to provide structured messages and instructions.
Prompt Discovery
Clients can discover available prompts through the prompts/list endpoint.
{
"jsonrpc": "2.0",
"id": 1,
"method": "prompts/list"
}
Prompt Retrieval
Prompts are retrieved using the prompts/get endpoint with the prompt name and optional arguments.
{
"jsonrpc": "2.0",
"id": 2,
"method": "prompts/get",
"params": {
"name": "summarize",
"arguments": {
"text": "Long text to summarize..."
}
}
}
Prompt Templates
Prompts are parameterized templates that the user picks in the host UI. The server returns structured messages for the host to inject into the chat.
Example prompt template:
{
"name": "code_review",
"description": "Review code for best practices and bugs",
"arguments": [
{
"name": "code",
"description": "The code to review",
"required": true
}
]
}
Prompts vs. Tools vs. Resources
| Primitive | Control | Purpose | Example |
|---|---|---|---|
| Tools | Model-controlled | Perform actions | read_file, query_database |
| Resources | Application-controlled | Provide context | File contents, database schemas |
| Prompts | User-controlled | Guide interactions | "Summarize", "Code review" |
Transport Architecture
MCP defines two standard transport mechanisms for client-server communication:
stdio Transport
In the stdio transport:
- The client launches the MCP server as a subprocess
- The server reads JSON-RPC messages from its standard input (stdin)
- The server sends messages to its standard output (stdout)
- Messages are individual JSON-RPC requests, notifications, or responses
- Messages are delimited by newlines and MUST NOT contain embedded newlines
- The server MUST NOT write anything to stdout that is not a valid MCP message
Logging: The server MAY write UTF-8 strings to stderr for logging purposes.
Security: stdio transport has no network surface; authentication is handled through environment credentials.
Streamable HTTP Transport
In the Streamable HTTP transport:
- The server operates as an independent process that can handle multiple client connections
- The server provides a single HTTP endpoint that supports both POST and GET methods
- JSON-RPC messages are sent as HTTP POST requests to the MCP endpoint
- The server can optionally use Server-Sent Events (SSE) to stream multiple server messages
- This replaces the older HTTP+SSE transport from protocol version 2024-11-05
Sending Messages: Every JSON-RPC message sent from the client MUST be a new HTTP POST request to the MCP endpoint. The client MUST include an Accept header listing both application/json and text/event-stream.
Security: Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks. Servers SHOULD bind only to localhost (127.0.0.1) rather than all network interfaces when running locally.
Transport Comparison
| Aspect | stdio | Streamable HTTP |
|---|---|---|
| Deployment | Local subprocess | Remote service |
| Clients | Typically one client | Many clients |
| Authentication | Environment credentials | OAuth 2.1 |
| Network | No network surface | HTTP/HTTPS |
| Streaming | No | Yes (SSE) |
| Scalability | Process-level | Service-level |
Local MCP Architecture
Local MCP architecture runs the MCP server as a subprocess of the host application, typically using the stdio transport.
┌─────────────────────────────────────────────────────────────────────────────┐
│ Desktop AI Application │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ User Interface │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ LLM Integration │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ MCP Client │ │
│ │ (stdio transport) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ stdin / stdout / stderr │
│ │ │
└────────────────────────────────────┼────────────────────────────────────────┘
│
▼
┌─────────────┐
│ Local │
│ MCP Server │
│ (stdio) │
└──────┬──────┘
│
▼
┌─────────────┐
│ Filesystem │
│ Git │
│ Local Tools │
└─────────────┘
Figure 8: Local MCP architecture—the Host launches the Server as a subprocess.
Key Considerations
Process Lifecycle: The Host controls the Server process lifecycle—launching, monitoring, and terminating it.
Filesystem Permissions: The Server runs with the Host's filesystem permissions. Access should be restricted to necessary directories.
Local Secrets: Secrets (API keys, tokens) should be retrieved from the environment.
Sandboxing: Consider running servers in isolated environments (containers, sandboxes) for security.
Remote MCP Architecture
Remote MCP architecture runs the MCP server as a network service, typically using the Streamable HTTP transport.
┌─────────────────────────────────────────────────────────────────────────────┐
│ User │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Web Application │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Agent Runtime │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ MCP Client │ │
│ │ (Streamable HTTP transport) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
└────────────────────────────────────┼────────────────────────────────────────┘
│
│ HTTPS / OAuth 2.1
▼
┌─────────────┐
│ API Gateway │
│ & Auth │
└──────┬──────┘
│
▼
┌─────────────┐
│ Remote │
│ MCP Server │
│ (HTTP) │
└──────┬──────┘
│
▼
┌─────────────┐
│ Enterprise │
│ Systems │
└─────────────┘
Figure 9: Remote MCP architecture—the Server runs as a network service.
Key Considerations
Authentication: Remote MCP servers use OAuth 2.1 for authentication and authorization. The MCP server acts as an OAuth 2.1 resource server.
Authorization: Protected MCP servers act as OAuth 2.1 resource servers, accepting and responding to protected resource requests using access tokens.
TLS: All remote communication should use TLS/HTTPS.
Network Boundaries: Remote servers cross network boundaries and require appropriate security controls.
Rate Limiting: Protect remote servers from excessive requests.
Multi-tenancy: Remote servers may serve multiple tenants with isolation requirements.
Multiple MCP Servers
An agent can connect to multiple MCP servers simultaneously. Each server provides different capabilities.
┌─────────────────────────────────────────────────────────────────────────────┐
│ Agent Host │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Agent Runtime │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────┼──────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ MCP Client │ │ MCP Client │ │ MCP Client │ │
│ │ (stdio) │ │ (HTTP) │ │ (stdio) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
└─────────┼──────────────────────────┼──────────────────────────┼─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ GitHub │ │ Database │ │ Search │
│ Server │ │ Server │ │ Server │
│ (Local) │ │ (Remote) │ │ (Local) │
└─────────────┘ └─────────────┘ └─────────────┘
Figure 10: An Agent Host connecting to multiple MCP Servers via multiple Clients.
Key Considerations
Server Discovery: The Host must know which servers to connect to (configuration or service discovery).
Capability Aggregation: The Host aggregates capabilities from all connected servers.
Routing: The Host routes tool calls to the appropriate server.
Failure Isolation: A failure in one server should not affect others.
Permissions: Each server may have different permission requirements.
MCP in an AI Agent Architecture
MCP fits into a complete AI agent architecture as the protocol layer between the agent's reasoning and external capabilities.
┌─────────────────────────────────────────────────────────────────────────────┐
│ User │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Agent │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Reasoning │ │
│ │ (LLM / Planning / Decision-making) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ Orchestration │ │
│ │ (Task decomposition, workflow management) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ Tool Selection │ │
│ │ (Choosing which tool to call) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ MCP Client │ │
│ │ (Protocol communication) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
└────────────────────────────────────┼────────────────────────────────────────┘
│
▼
┌─────────────┐
│ MCP Servers │
│ │
│ Tool │
│ Execution │
└─────────────┘
Figure 11: MCP in an AI agent architecture—separating reasoning, orchestration, and protocol communication.
Separation of Concerns
- Reasoning: The LLM decides what to do (high-level)
- Orchestration: The agent framework manages workflow and task decomposition
- Protocol Communication: MCP handles the standardized communication with external capabilities
- Tool Execution: MCP Servers execute the actual operations
MCP and Agent Frameworks
MCP integrates with agent frameworks at the protocol boundary, providing a standardized way for agents to access external capabilities.
Integration Patterns
LangGraph: LangGraph agents can use MCP to access tools and resources. The MCP client acts as a tool provider within the LangGraph ecosystem.
OpenAI Agents SDK: Agents can use MCP via the Python MCP SDK, discovering and calling tools from MCP servers.
CrewAI: CrewAI provides a dedicated MCP plugin (crewai-mcp) that enables connecting to MCP servers and using their tools.
AutoGen: AutoGen agents can integrate MCP clients to access external tools and resources.
Semantic Kernel: Semantic Kernel can incorporate MCP tools into its plugin architecture.
Protocol Boundary
The key architectural insight is that MCP operates at the protocol boundary—it defines how agents communicate with external capabilities, regardless of the framework used. This means:
- Framework-specific logic stays in the framework
- MCP handles the standardized communication
- The boundary between framework and MCP is clear and well-defined
MCP Security Architecture
MCP provides security capabilities at the transport level.
Security Boundaries
┌─────────────────────────────────────────────────────────────────────────────┐
│ MCP Host │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ User Consent & Policy │ │
│ │ - User authorizes tool access │ │
│ │ - Policies enforced at Host level │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ MCP Client │ │
│ │ - Authentication credentials │ │
│ │ - Least privilege access │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
└────────────────────────────────────┼────────────────────────────────────────┘
│
│ Authentication / TLS
▼
┌─────────────┐
│ API Gateway │
│ - AuthN/Z │
│ - Rate │
│ - Audit │
└──────┬──────┘
│
▼
┌─────────────┐
│ MCP Server │
│ - Tool │
│ Permissions│
│ - Secrets │
└──────┬──────┘
│
▼
┌─────────────┐
│ Enterprise │
│ Systems │
└─────────────┘
Figure 12: MCP security architecture showing authentication, authorization, and auditing layers.
Authentication
stdio transport: Authentication is handled through environment credentials.
Streamable HTTP transport: Authentication uses OAuth 2.1. The MCP server acts as an OAuth 2.1 resource server. MCP servers MUST use the HTTP header WWW-Authenticate when returning a 401 Unauthorized to indicate the location of the resource server metadata URL.
Authorization
- Tool-level permissions: Each tool should have defined permissions
- Least privilege: Servers should only expose necessary capabilities
- Scope-based: OAuth scopes can restrict access to specific resources
Secrets Management
- Secrets should not be hard-coded in servers
- Environment variables for local deployments
- Secret management services for remote deployments
Security Best Practices
- Validate all inputs at protocol boundaries
- Implement proper authentication for remote servers
- Apply least privilege to tool access
- Log all security-relevant events
- Use TLS for all remote communication
- Implement rate limiting to prevent abuse
MCP Failure Handling
MCP architectures must handle various failure modes gracefully.
Common Failures
| Failure | Description | Handling Strategy |
|---|---|---|
| Server unavailable | Server is down or unreachable | Retry with exponential backoff |
| Connection timeout | Network timeout | Set appropriate timeouts; retry |
| Invalid request | Malformed JSON-RPC | Return error response; log |
| Unsupported capability | Capability not supported | Negotiate; fallback |
| Tool execution failure | Tool throws error | Return error; retry if appropriate |
| Authentication failure | Invalid credentials | Re-authenticate; escalate |
| Network interruption | Connection lost | Reconnect; resume |
Failure Handling Strategies
Timeouts: Set appropriate timeouts for all requests. Different operations may require different timeouts.
Retry: Implement retry logic with exponential backoff for transient failures.
Circuit Breaker: Use circuit breakers to prevent cascading failures when a server is unhealthy.
Error Propagation: Propagate errors to the Host for appropriate handling.
Fallback: Have fallback strategies when a server is unavailable.
MCP Observability
Observability is critical for production MCP deployments.
What to Observe
| Category | What to Observe | Why |
|---|---|---|
| Connection lifecycle | Connection establishment, initialization, shutdown | Detect connection issues |
| Request latency | Time for each request | Identify performance bottlenecks |
| Tool calls | Which tools are called, success/failure, latency | Understand usage patterns |
| Errors | Error types and frequencies | Identify issues early |
| Resource reads | Which resources are accessed | Understand context usage |
| Prompt usage | Which prompts are used | Understand user behavior |
| Authentication failures | Failed auth attempts | Detect security issues |
Observability Tools
- Logging: Structured logging for all operations
- Metrics: Performance metrics and counters
- Tracing: Distributed tracing for end-to-end request flow
Implementation Approaches
- Use OpenTelemetry for distributed tracing
- Implement structured logging with correlation IDs
- Export metrics to monitoring systems (Prometheus, Grafana)
- Set up alerts for error rates and latency anomalies
Production MCP Architecture
A complete enterprise MCP architecture includes multiple layers for security, scalability, and observability.
┌─────────────────────────────────────────────────────────────────────────────┐
│ User │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ API Gateway │
│ (Authentication, Rate Limiting, Routing) │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Agent Runtime │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ Agent Orchestrator │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────▼───────────────────────────────────┐ │
│ │ MCP Client Manager │ │
│ │ (Creates and manages MCP Clients) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────────┼──────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ MCP Client │ │ MCP Client │ │ MCP Client │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
└─────────┼──────────────────────────┼──────────────────────────┼─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Secrets │ │ Metrics │ │ Tracing │
│ Manager │ │ Collector │ │ Collector │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ MCP Server │ │ MCP Server │ │ MCP Server │
│ (Auth) │ │ (Service) │ │ (Service) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Enterprise │ │ Databases │ │ Cloud │
│ APIs │ │ │ │ Services │
└─────────────┘ └─────────────┘ └─────────────┘
Figure 13: Production MCP architecture with API Gateway, Agent Runtime, MCP Clients, and MCP Servers.
Architecture Layers
- API Gateway: Handles authentication, rate limiting, and routing
- Agent Runtime: Hosts the agent orchestration and MCP Client Manager
- MCP Client Manager: Creates and manages MCP Clients for each server
- MCP Clients: Maintain connections to MCP Servers
- MCP Servers: Provide capabilities to the agent
- Observability: Logging, metrics, and tracing
- Secrets Management: Secure storage and retrieval of credentials
MCP Architecture Patterns
Pattern 1: Single Host, Single Server
Architecture: One Host connects to one MCP Server.
┌──────────┐ ┌──────────┐
│ Host │────▶│ Server │
└──────────┘ └──────────┘
Benefits: Simple, easy to deploy, minimal overhead.
Limitations: Limited to one capability source.
Use cases: Simple agents with one tool source, proof-of-concepts.
Pattern 2: Single Host, Multiple Servers
Architecture: One Host connects to multiple MCP Servers.
┌──────────┐ ┌──────────┐
│ │────▶│ Server │
│ Host │────▶│ Server │
│ │────▶│ Server │
└──────────┘ └──────────┘
Benefits: Access to multiple capability sources, capability aggregation.
Limitations: Host must manage multiple connections.
Use cases: Agents needing multiple tool sources (filesystem + database + GitHub).
Pattern 3: Shared MCP Server
Architecture: Multiple Hosts share one MCP Server.
┌──────────┐
│ Host │
└────┬─────┘
│
┌────┼─────┐
│ │ │
▼ ▼ ▼
┌──────────┐
│ Server │
└──────────┘
Benefits: Centralized capability management, reduced duplication.
Limitations: Server must handle multiple clients, potential scalability bottleneck.
Use cases: Teams sharing common tools, centralized data access.
Pattern 4: Per-Tenant MCP Server
Architecture: Each tenant has its own MCP Server instance.
┌──────────┐ ┌──────────┐
│ Tenant A │────▶│ Server A │
└──────────┘ └──────────┘
┌──────────┐ ┌──────────┐
│ Tenant B │────▶│ Server B │
└──────────┘ └──────────┘
Benefits: Strong isolation, per-tenant customization.
Limitations: Higher operational overhead.
Use cases: Multi-tenant SaaS applications.
Pattern 5: Gateway-Based MCP Architecture
Architecture: A gateway aggregates multiple MCP Servers behind one endpoint.
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Host │────▶│ Gateway │────▶│ Server A │
└──────────┘ │ │────▶│ Server B │
│ │────▶│ Server C │
└──────────┘ └──────────┘
Benefits: Single endpoint for clients, unified access, policy enforcement, audit.
Limitations: Additional latency, single point of failure.
Use cases: Enterprise environments with many MCP servers.
Pattern 6: MCP Behind an API Gateway
Architecture: MCP Servers are deployed behind an API Gateway.
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Host │────▶│ API │────▶│ Server │
└──────────┘ │ Gateway │ └──────────┘
│ │
│ Auth / │
│ Rate │
│ Limit │
└──────────┘
Benefits: Centralized authentication, rate limiting, monitoring.
Limitations: Additional latency.
Use cases: Production deployments requiring security and scale.
MCP vs Traditional API Integration
| Aspect | Traditional REST API | MCP Integration |
|---|---|---|
| Discovery | Static (documentation) | Dynamic (runtime discovery) |
| Schemas | OpenAPI / Swagger | JSON Schema in protocol |
| Standardization | Varies by API | Standardized across all MCP servers |
| Tool semantics | Implicit | Explicit (tools, resources, prompts) |
| Interoperability | Custom per integration | Any MCP client works with any MCP server |
| Operational complexity | N×M integrations | N+M (one per client + one per server) |
Key Insight
MCP does not replace REST or gRPC. MCP is the layer that lets LLM agents discover and use tools; REST and gRPC are the layer underneath that the MCP server usually wraps.
MCP vs A2A
MCP and A2A solve different architectural problems:
- MCP: Agent-to-tool/resource integration. Connects agents to external capabilities.
- A2A: Agent-to-agent communication. Connects agents to other agents for collaboration.
They are complementary protocols that can be used together in production systems.
Architecture Best Practices
Server Design
- Keep MCP servers focused: Each server should provide one coherent set of capabilities
- Minimize tool surface area: Expose only necessary tools
- Use explicit schemas: Define clear input schemas for all tools
- Version interfaces carefully: Plan for backward compatibility
Security
- Enforce least privilege: Tools should have minimal required permissions
- Protect secrets: Never hard-code secrets; use environment or secret management
- Validate inputs: Validate all inputs at the protocol boundary
- Audit sensitive operations: Log all security-relevant operations
Operations
- Separate clients from business logic: Keep MCP protocol code separate from business logic
- Treat remote MCP as a network boundary: Apply network security controls
- Implement timeouts: Set appropriate timeouts for all operations
- Monitor every tool invocation: Track usage, errors, and latency
Reliability
- Design for failure isolation: One server failure should not affect others
- Implement retry with backoff: Handle transient failures gracefully
- Use circuit breakers: Prevent cascading failures
Common Architecture Mistakes
| Mistake | Why It's a Problem | Better Approach |
|---|---|---|
| Treating MCP as a replacement for the entire application architecture | MCP is a protocol for context exchange, not a complete application framework | Use MCP for what it's designed for; use other tools for other concerns |
| Putting too many unrelated tools in one server | Violates composability principle; harder to maintain | Split into focused servers |
| Exposing unrestricted capabilities | Security risk | Apply least privilege |
| Coupling agent logic to MCP implementation details | Makes migration difficult | Keep agent logic separate from protocol details |
| Ignoring lifecycle management | Leads to unreliable connections | Follow the defined lifecycle |
| Ignoring security boundaries | Security vulnerabilities | Enforce security at every layer |
| Assuming all MCP servers are trusted | Security risk | Validate and authenticate |
| Failing to monitor tool execution | Blind to failures and usage | Implement observability |
| Using remote servers without authentication controls | Security vulnerability | Implement OAuth 2.1 for remote servers |
MCP Architecture Decision Guide
Use this decision matrix to choose the right architecture pattern:
| Requirement | Pattern Recommendation |
|---|---|
| Local tool access only | Single Host, Single Server (local) |
| Multiple capability sources | Single Host, Multiple Servers |
| Multiple teams sharing tools | Shared MCP Server |
| Multi-tenant isolation | Per-Tenant MCP Server |
| Many MCP servers to manage | Gateway-Based MCP Architecture |
| Production security requirements | MCP Behind an API Gateway |
| Remote enterprise integrations | Remote MCP Architecture |
| Both local and remote | Hybrid (local stdio + remote HTTP) |
Frequently Asked Questions
1. What is MCP architecture?
MCP follows a client-host-server architecture where each host can run multiple client instances. The Host is the AI application, Clients are connectors to individual Servers, and Servers provide capabilities.
2. What is an MCP Host?
The MCP Host is the AI application that coordinates and manages one or multiple MCP clients. Examples include Claude Desktop and Claude Code.
3. What is an MCP Client?
The MCP Client is a component that maintains a connection to an MCP server and obtains context from the MCP server for the MCP host to use.
4. What is an MCP Server?
The MCP Server is a program that provides context and capabilities to MCP clients.
5. How do MCP Clients communicate with MCP Servers?
MCP Clients communicate with MCP Servers using JSON-RPC 2.0 messages over either stdio (local subprocess) or Streamable HTTP (remote service) transports.
6. Why does MCP use JSON-RPC?
JSON-RPC provides a lightweight, language-agnostic messaging format that is simple to implement and widely supported.
7. Can one agent connect to multiple MCP servers?
Yes. A Host can create multiple Clients, each connecting to a different Server.
8. Can an MCP server be remote?
Yes. MCP servers can run remotely using the Streamable HTTP transport.
9. What is the difference between MCP Tools and Resources?
Tools are model-controlled executable functions; Resources are application-controlled contextual data.
10. How does MCP capability negotiation work?
The client declares its capabilities in the initialize request; the server responds with its capabilities. Both parties respect declared capabilities throughout the interaction.
11. How is MCP secured?
For stdio transport, credentials are retrieved from the environment. For HTTP transport, MCP uses OAuth 2.1 with the server acting as an OAuth 2.1 resource server.
12. Can MCP work with LangGraph?
Yes. LangGraph agents can use MCP to access tools and resources via an MCP client.
13. Can MCP work with OpenAI Agents SDK?
Yes. OpenAI Agents SDK integrates with MCP via the Python MCP SDK.
14. How does MCP differ from REST APIs?
MCP provides dynamic discovery, standardized tool semantics, and interoperability. REST APIs typically require custom integration per API.
15. How does MCP relate to A2A?
MCP handles agent-to-tool/resource integration; A2A handles agent-to-agent communication. They are complementary.
Key Takeaways
- MCP separates agent reasoning from external capabilities through a clear architectural boundary
- Host, Client, and Server have distinct responsibilities that enable modular, composable systems
- Tools, Resources, and Prompts represent different capability types with different control models
- JSON-RPC provides a structured, language-agnostic protocol communication foundation
- Lifecycle and capability negotiation are fundamental to interoperability and reliability
- Production MCP architectures require strong security, observability, and failure handling
- MCP and A2A solve different architectural problems and are complementary
Further Reading
- MCP Protocol Overview – An introduction to the Model Context Protocol, its architecture, core primitives, and how it connects agents to tools.
- MCP Server Development – A step-by-step guide to building, configuring, and deploying your own MCP servers.
- MCP Client Development – Learn how to implement an MCP client that discovers and consumes tools, resources, and prompts.
- MCP Tools – Deep dive into the tool primitive: exposing functions, handling parameters, and executing actions.
- MCP Resources – Understanding resources as application-controlled contextual data with URI-based addressing.
- MCP Prompts – Learn how to expose reusable prompt templates that guide language model interactions.
- MCP Security – Best practices for securing MCP servers, including authentication, authorization, and tool-safety measures.
- MCP Deployment – Strategies for deploying MCP servers in production environments.
- MCP Best Practices – Production-ready recommendations for designing, building, and operating MCP-based systems.
- A2A Protocol Overview – A high-level introduction to the Agent-to-Agent Protocol, its task model, and how it enables agent collaboration.
- MCP vs A2A – A deep-dive comparison between the Model Context Protocol and the Agent-to-Agent Protocol.
- Agent Tools – A foundational look at tool design, integration patterns, and common tool categories for AI agents.
- Agent Workflow – Core concepts of agentic workflows: planning, execution, and feedback loops.
- Production Observability – Comprehensive guide to logging, metrics, and tracing for production AI agent systems.
- Production Security – Comprehensive security guidelines for production agents, covering data privacy, authentication, and threat mitigation.
- Production Deployment – Strategies for deploying AI agents at scale, including containerization, monitoring, and rollback.