MCP Architecture

MCP is built on a client-server architecture. This architecture has three distinct roles: the Host (AI application), the Client (communication component), and the Server (tool-providing program). Clear separation of these roles enables scalability and reusability.

Overview

The following diagram shows the communication flow in MCP:

graph LR
    U[User] --> H[Host\nClaude Desktop / Cursor]
    H --> C[Client\nMCP Client]
    C --> S1[Server A\nWeather MCP Server]
    C --> S2[Server B\nFile System\nMCP Server]
    S1 --> T1[Weather API]
    S2 --> T2[Local\nFiles]

The user sends instructions to the Host. The Host communicates with MCP servers through the Client to retrieve tools and information, then generates a response.

The Three Roles

Host

The Host is the AI application that faces the user directly. It is the environment in which the AI model runs.

Responsibilities

Receive user input (text, voice, etc.)
Maintain conversation history and manage context
Call the AI model to generate responses
Initiate connections to MCP servers when needed
Display the final response to the user

Examples

Host Application	Type
Claude Desktop	Desktop AI assistant
Cursor	AI-powered code editor
Windsurf	AI-powered code editor
Zed	AI-powered text editor
Chainlit	AI chat app building framework

Client

The Client is a component embedded inside the Host that handles low-level communication with MCP servers. It acts like an “adapter” or “messenger.”

Responsibilities

Send and receive messages according to the MCP protocol
Retrieve the list of available tools, resources, and prompts from servers
Convert Host instructions into MCP messages and send them to the Server
Return Server results to the Host

Relationship Between Host and Client

Host and Client are conceptually separate but exist within the same application in practice:

Host: Determines the AI’s intent (decides “I should look up the weather”)
Client: Actually communicates via the MCP protocol (sends a request to the weather MCP server)

Server

The Server is an external program or service that provides specific capabilities (tools, data, etc.) to the AI.

Responsibilities

Expose available capabilities (Tools, Resources, Prompts) in a standardized format
Respond to tool-list requests from the Client
Receive tool-call requests and execute the actual processing
Return results to the Client

Deployment Options

Type	Description	Example
Local server	Runs on the same machine	File system MCP server
Remote server	Runs in the cloud	Weather API MCP server

Detailed Communication Flow

The following sequence diagram shows how a tool is invoked through MCP:

sequenceDiagram
    participant U as User
    participant H as Host
    participant C as Client
    participant S as Server

    U->>H: "What is the weather in Tokyo today?"
    H->>C: Fetch available tools
    C->>S: tools/list request
    S-->>C: [get_weather, get_forecast, ...]
    C-->>H: Return tool list
    H->>H: LLM decides to call get_weather
    H->>C: Execute get_weather(location="Tokyo")
    C->>S: tools/call request
    S->>S: Call weather API
    S-->>C: {"temp": 18, "condition": "sunny"}
    C-->>H: Return tool result
    H->>H: LLM generates answer from result
    H-->>U: "Tokyo is 18°C and sunny today."

Implementation Example: Claude Desktop

Using Claude Desktop as an example, here is how the three roles map to the actual application:

Claude Desktop (Host + Client)
├── Chat UI (Host role)
│   - Accepting user input
│   - Displaying conversation history
│   - Communicating with the Anthropic API
│
└── MCP Client (Client role)
    - Managing connections to MCP servers
    - Sending and receiving messages per the protocol

Connected MCP Servers (Server role)
├── filesystem: File system operations
├── brave-search: Web search
└── github: GitHub repository operations

Adding MCP servers to Claude Desktop’s configuration file (claude_desktop_config.json) enables Claude to use the tools those servers provide.

Architectural Characteristics

Loose Coupling

Loose coupling is a design principle that minimizes dependencies between components.

In MCP’s architecture, the Host does not need to know the implementation details of any Server. Because communication happens through the shared MCP protocol interface, a Server can be swapped out without changing the Host or Client code.

One-to-Many Connections

A single Client can connect to multiple Servers simultaneously. For example, Claude Desktop can be connected to a file system server, a search server, and a GitHub server at the same time, using each for its own purpose.

Summary

Role	What It Is	Primary Responsibility
Host	The AI app the user interacts with	User interaction, running the AI model
Client	Communication component inside the Host	Server communication per the MCP protocol
Server	Tool-providing program	Exposing capabilities, executing tool calls

Next Steps

MCP Capabilities — Details on Tools, Resources, and Prompts that Servers provide to Clients
Why MCP? — Revisit the M×N integration problem and MCP’s solution
What is MCP? — Return to the MCP overview

Frequently Asked Questions

Q: Can a single AI app have multiple MCP clients?

A: The MCP specification allows a single Host to have multiple Clients, each connecting to a different Server. However, most implementations use a single Client connecting to multiple Servers simultaneously.

Q: Where do I run MCP servers?

A: MCP servers run either on a local machine or in the cloud. Applications like Claude Desktop can auto-start local MCP servers by specifying a command in a configuration file. For remote servers, I provide an HTTPS endpoint URL.

Q: What programming languages can I use to implement a Server?

A: Because MCP is a protocol, it is language-agnostic. Official SDKs are provided for TypeScript, Python, Java, and Kotlin, among others, making it relatively straightforward to implement an MCP server in any of these languages.

References

Link to this page (Japanese): MCPのアーキテクチャ