Architecture

MCP System Overview

High-Level Architecture: Host, Client, and Server

Figure: The Host manages multiple clients, each connecting to a specific server. Each client-server pair is isolated, ensuring security and modularity.

MCP Design Principles

How It Works (At a Glance): Practical Example

Scenario: A user interacts with an AI-powered productivity assistant (the host) that integrates both a calendar tool and a weather tool.

1. User: Asks, "Do I have any meetings this afternoon, and what's the weather forecast for that time?"
2. Host: Uses the LLM to interpret the request and determines it needs to:
   • Check the user's calendar for meetings this afternoon (calendar tool)
   • Get the weather forecast for the meeting time (weather tool)
3. Host: Uses Client 1 to connect to Server 1 (Calendar Tool), which returns: "You have a meeting at 3:00 PM."
4. Host: Uses Client 2 to connect to Server 2 (Weather Tool), which returns: "The forecast at 3:00 PM is sunny, 75°F."
5. Security Boundary: Each client only communicates with its assigned server. The calendar server never sees weather data, and vice versa.
6. Host: Aggregates the results and presents: "You have a meeting at 3:00 PM. The weather at that time is expected to be sunny, 75°F."

Key Point: This example shows how MCP enables secure, modular, and orchestrated multi-tool workflows.

Core Message Types

Overview

MCP uses JSON-RPC 2.0 as its foundation for structured, reliable communication between hosts, clients, and servers. There are four core message types—Request, Response, Error, and Notification—which enable both sides to exchange actions, results, errors, and updates in a consistent way. Understanding these types is essential for building and integrating MCP-compliant tools and applications.

Main Message Types

📤 Request

Asks another component to perform an action or provide information.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/read",
  "params": { "id": "abc123" }
}

📥 Response

Returns the result of a request.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": { "id": "abc123", "name": "Resource Name", "data": "..." }
}

❗ Error

Returns an error for a request.

Common error codes:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": { "code": -32601, "message": "Method not found" }
}

🔔 Notification

Sends a one-way event or update; no response expected.

{
  "jsonrpc": "2.0",
  "method": "notifications/resources/updated",
  "params": { "resourceId": "abc123" }
}

Additional Notes

• Batching: MCP (via JSON-RPC 2.0) supports sending multiple requests or notifications in a single batch for efficiency.
• Cancellation: MCP supports cancelling in-progress requests using a special notification (e.g., "notifications/cancelled"), allowing clients or servers to request that a long-running operation be stopped if it is no longer needed. Learn more
• Extensibility: Custom methods and parameters can be defined as long as they adhere to the protocol's structure.

References

• MCP Specification: Core Message Types
• MCP Protocol Schema on GitHub
• JSON-RPC 2.0 Specification

Features

MCP defines a set of features—such as resources, tools, prompts, sampling, and roots—that enable applications to interact with external data, perform actions, and extend AI capabilities in a standardized, secure manner.

Server Features

📦 Resources: Structured data or context a server provides.
How it works: Exposes data (files, DB tables, API results) as resources for the client/LLM.
Example: List of files in a project; customer records from a database.

🛠️ Tools: Functions or actions the AI assistant can invoke.
How it works: Client/LLM calls tools via MCP to perform operations.
Example: Search database, format code.

📝 Prompts: Templated messages or workflows to guide LLM/user.
How it works: Standardizes tasks and interactions.
Example: Summarize a document; onboarding workflow.

Tip: Use a resource for static or subscribable data; use a tool for dynamic, parameterized queries or actions.

Client Features

🎲 Sampling: Lets the server request the client to generate a completion or response from the LLM.
How it works: Server asks the client to use its LLM for tasks like summarization or drafting.
Example: Server requests a summary of a document.

📁 Roots: Defines boundaries of accessible directories/files for the server.
How it works: Client exposes only specific directories to the server.
Example: Only the "/projects/my-app" folder is accessible to a code analysis server.

MCP Connection Lifecycle

The connection lifecycle in the Model Context Protocol (MCP) defines how a session is established, maintained, and terminated between a client and a server, with the host orchestrating the process. This lifecycle ensures robust, secure, and feature-negotiated communication for all MCP-compliant integrations.

Lifecycle Phases

1. Initialization 🤝

• Host: Starts the session and initializes the client.
• Client: Sends initialization request to the server, declaring supported features.
• Server: Responds with its own capabilities.
• Negotiation: Only mutually supported features are enabled. 🔄

2. Active Session 🔄

• Client Requests:
  • User/LLM: Initiates actions (e.g., tool calls, resource queries).
  • Host: Orchestrates the process, routes requests to the correct client/server.
  • Client: Sends structured requests to the assigned server.
  • Server: Processes requests and returns responses.
  • Host: May aggregate, filter, or post-process responses before updating the UI or LLM.
• Server Requests:
  • Server: Can request the client/LLM to perform a task (e.g., generate a completion).
  • Client: Forwards the request to the LLM, under host supervision.
  • Host: May enforce security, consent, or policy checks.
  • Client: Returns the LLM's response to the server.
• Notifications:
  • Client/Server: Can one-way send notifications for events (e.g., resource updates, status changes).
  • Host: Routes/handles notifications, updates UI or triggers further actions.
  Example: Server notifies client that a file has changed, prompting the host to refresh the display.

3. Termination ⏹️

• Who: Server, client, or host can initiate termination (e.g., on completion, user request, or error).
• How: Termination is communicated explicitly via protocol messages or notifications.
• Host: Mediates/coordinates termination, notifies all parties, and updates the UI or application state.
• Cleanup: All resources (connections, memory, temp files) are released.
• Result: Session ends cleanly, and the system is ready for new sessions or safe shutdown.

Lifecycle Diagram

The diagram above illustrates the key phases and message flows in a typical MCP session, including initialization, active session management, requests, notifications, and termination.

Key Points

• Capability negotiation during initialization ensures only mutually supported features are active.
• Requests and notifications flow in both directions, enabling rich, interactive workflows.
• Termination is explicit, ensuring clean shutdown and resource management.

Transport Protocols

Transport Protocols in MCP

• 🖥️ stdio: Client launches the MCP server as a subprocess and exchanges messages via standard input/output.
  Fast and ideal for local tools.
• 🌐 Streamable HTTP: Client and server communicate over HTTP using POST and GET requests. Supports both single-response and real-time streaming.

• POST: Client sends JSON-RPC messages in a POST request (Content-Type: application/json). Accept header signals support for application/json and text/event-stream. Server responds with single or streaming response. Mcp-Session-Id header is used if a session is active.
• GET: Client can open a persistent connection with Accept: text/event-stream. Server responds with Content-Type: text/event-stream. Mcp-Session-Id is included if a session is active.

This approach enables both single-response and real-time, streaming communication, making MCP suitable for a wide range of use cases.
See the MCP Transports documentation for more details.

Authorization in MCP (2025-03-26 Spec)

• Authorization is optional in MCP, but for HTTP-based transports, it is strongly recommended for security.
• 🌐 OAuth 2.1 is the recommended method for secure authorization and access control.
• 🖥️ For stdio, credentials are typically managed via the environment.
• See the MCP Authorization documentation for full details and best practices.

Session Management in MCP

• MCP supports session management for stateful interactions between clients and servers.
• With Streamable HTTP, the server may assign a unique session ID during initialization (Mcp-Session-Id header).
• Client must include this session ID in all subsequent requests for the session's duration.
• Sessions can be explicitly terminated by the client or server, ensuring clean resource management and robust error handling.

For more, see Session Management in the MCP spec.

Security and Trust & Safety

The Model Context Protocol (MCP) enables powerful integrations between LLMs and external tools or data sources. With this power comes significant responsibility: implementers must ensure robust security, user trust, and safety at every stage of development and deployment.

Key Principles

1. User Consent and Control
   Users must explicitly consent to all data access and operations. Users should always understand and control what data is shared and what actions are taken on their behalf. Applications should provide clear UIs for reviewing and authorizing activities.
2. Data Privacy
   Hosts must obtain explicit user consent before exposing user data to servers. Resource data must not be transmitted elsewhere without user consent, and all user data should be protected with appropriate access controls.
3. Tool Safety
   Tools represent arbitrary code execution and must be treated with caution. Descriptions of tool behavior should be considered untrusted unless obtained from a trusted server. Hosts must obtain explicit user consent before invoking any tool, and users should understand what each tool does before authorizing its use.
4. LLM Sampling Controls
   Users must explicitly approve any LLM sampling requests. Users should control whether sampling occurs, the actual prompt sent, and what results the server can see. The protocol intentionally limits server visibility into prompts.

Implementation Guidelines

• Build robust consent and authorization flows into your applications.
• Provide clear documentation of security implications for users and developers.
• Implement appropriate access controls and data protections.
• Follow security best practices in all integrations.
• Consider privacy implications in all feature designs.

While MCP itself cannot enforce these principles at the protocol level, it is the responsibility of every implementer to uphold them in practice.

References

• Model Context Protocol: Introduction (Official) — Overview, motivation, and analogy for MCP.
• Model Context Protocol: Full Specification (Official) — The canonical, up-to-date protocol specification.
• MCP Specification: Architecture (Official) — Authoritative source on host, client, and server roles, security boundaries, and design principles.
• Model Context Protocol: Core Architecture (Concepts) — Explains the architecture, connection flows, and isolation principles in detail.
• Model Context Protocol: Concepts – Resources, Tools, Prompts, Sampling — Deep dives into each feature, with examples and best practices.
• Model Context Protocol (MCP) — A Technical Deep Dive (Medium) — Third-party technical deep dive into MCP's motivation, architecture, and use cases.
• MCP GitHub Documentation — The open-source repository for MCP documentation, including examples and community discussions.
• MCP Detailed Specification - Detailed MCP specification in TypeScript
• Model Context Protocol: Tutorials and Quickstarts — Step-by-step guides for building servers and clients.
• JSON-RPC 2.0 Specification
• Model Context Protocol Java SDK Overview — Official documentation for the Java SDK, including features like tool discovery, resource management, and transport options.