Detailed explanation of MCP core architecture

MCP protocol core architecture

The MCP protocol follows the common C/S architecture of the Internet, namely the client-server architecture.

The MCP protocol introduces the concept of host, forming a basic host-client-server architecture.

Next, we will analyze each part of the architecture and its functions in detail.

The host in the MCP protocol is a large model application, similar to the Claude desktop client and Cursor editor. The client process can be scheduled in the host to initiate a connection to the server.

The host acts as a coordinator:

• Creating and managing multiple client instances
• Control client connection permissions and lifecycle
• Enforce security policies and consent requirements
• Handling user authorization decisions
• Coordinated AI / Large Model Integration and Sampling
• Managing context aggregation across clients

The client in the MCP protocol can be understood as a business process within the host, which can connect to the server process to achieve data interaction and help the host application obtain external resources.

The main responsibilities of the client process are:

• Establish a stateful session for each server
• Handles protocol negotiation and capability exchange
• Bidirectional transmission of routing protocol messages
• Manage subscriptions and notifications
• Maintaining secure boundaries between servers

❝

What is a process? A process is a dynamic execution process of a program with certain independent functions on a data set. It is an independent unit for resource allocation and scheduling of the operating system and a carrier for the operation of application programs.

A host application can create and manage multiple client processes, each of which maintains an independent 1:1 connection with a specific server process.

The server in the MCP protocol is an external program that runs outside the host and is used to provide specific resources and capabilities.

Main features of the server program:

• Providing resources, tools and tips through the MCP protocol
• Operate independently with clear responsibilities
• Request sampling through the client interface
• Safety restrictions must be observed
• Can be a local process or a remote service

MCP protocol application scenario examples

To give a practical example, we installed the Claude Desktop application (hereinafter referred to as Claude) developed by Anthropic on our computer.

In Claude's MCP server configuration file, enter the configuration information of the two MCP servers:

{
  "mcpServers" : {
    "amap-maps" : {
      "command" :  "npx" ,
      "args" : [ "-y" ,  "@amap/amap-maps-mcp-server" ],
      "env" : {
        "AMAP_MAPS_API_KEY" :  "amap_api_key"
      }
    },
    "flomo" : {
      "command" :  "npx" ,
      "args" : [ "-y" ,  "@chatmcp/mcp-server-flomo" ],
      "env" : {
        "FLOMO_API_URL" :  "https://flomoapp.com/iwh/xxx/xxx/"
      }
    }
  }
}

• amap-maps It is the MCP of Amap, which provides multiple tools for querying information related to geographic location.

• flomo It is FuMoJi MCP, which provides a note-writing tool that can write text content.

After the configuration is complete, restart the Claude client.

Then you can see the two configured servers on the Claude tools page, with a total of 13 tools provided.

Enter the following into the Claude dialog box:

I want to drive from Guangzhou to Wuhan to see the cherry blossoms. Please help me plan the route and save the itinerary to my notes.

Claude starts processing and calls amap-maps The server provides four tools to query location and weather information, and finally call flomo Server write_note Tool to save the itinerary plan to Fumo Notes.

Use the "host-client-server" architecture of the MCP protocol to understand:

• Claude desktop application is the host

• amap-maps and flomo There are two servers

• There are two clients on the Claude host, connected amap-maps and flomo Two servers

"Host-Client-Server" collaboration process:

1. Read the server configuration file. When the host starts, it reads the server configuration file and finds two servers.

2. Start the local server process. The host runs the server on the local computer according to the configured server operation mode (command + args + env). Each server starts a local process and waits for client connections through process monitoring.

3. Start the client process. The host starts two child processes as clients, connecting to two local servers respectively. The client process exchanges data with the server process to maintain the communication connection.

4. Get the tool collection. The host maintains a 1:1 pairing connection between multiple clients and servers. After the connection is established, the host obtains all tool collections provided by all servers.

5. Process user requests. The host receives the user's input, sends a request to the big model, and passes the tool set provided by all servers to the big model. The big model performs intent recognition and scheduling planning, telling the host which tools should be called to meet user needs.

6. Execute multiple tool calls in parallel. The host locates the corresponding client and server combination according to the tool name and parameters returned by the large model, and the client process sends a tool call (CallTool) request to the server process to obtain the server's response data.

7. Generate a reply. The host uses the content obtained by requesting the server, stitches the conversation context, and requests the large model to make a summary output.

8. Program exit process. When the host exits, all client subprocesses end, the connection with the server is closed, and the server process ends.

In order to help everyone understand this process more vividly, I will show this collaboration process in a picture.

MCP protocol design principles

The MCP protocol is built on several key design principles that guide its architecture and implementation:

• Host applications handle complex orchestration tasks

• Servers are focused on implementing specific and well-defined capabilities

• Use simple interfaces to minimize implementation overhead

• Use clear separation of concerns to make your code maintainable

• Each server is dedicated to providing independent functions

• Multiple servers can be seamlessly combined

• Achieving interoperability with shared protocols

• Support scalability with modular design

• The server receives only the necessary context information

• The complete conversation history is kept with the host

• Each server connection remains isolated

• Cross-server interaction is controlled by the host

• The host process limits the security boundary

• The core protocol provides the minimum required functionality

• The server and client negotiate additional capabilities as needed

• Server and client evolve independently

• The protocol design needs to be extensible to support future features

• The protocol maintains backward compatibility

MCP protocol key components

The MCP protocol consists of several key components that work together:

At the protocol level, basic definitions and constraints are made for the following contents:

• JSON-RPC communication basics: specifies how messages should be encoded during communication between client and server

• Connection lifecycle: defines the complete process of communication between client and server

• Transport mechanism: defines how messages between the client and the server should be delivered

• Capability negotiation: The server and the client negotiate the functions that can be provided to each other.

Both the server and the client can implement rich features.

The server can provide the following functions to the client:

• Resources: contextual information and data for users or AI models to use

• Tips: Template messages and workflows for users

• Tools: Functions provided to AI models for execution

The client can provide the following capabilities to the server:

• Sampling: Implementing server proxy functionality
• Root directory: restricts the operable directory of the server

The MCP protocol also defines some additional tools for server and client communication:

• Configuration
• Progress Tracking
• Cancel communication
• Error Reporting
• Logging

MCP provides an authorization framework for use with HTTP. Implementations using HTTP-based transports should conform to this specification, while implementations using stdio transports should not follow this specification and instead obtain credentials from the environment.

Additionally, clients and servers can negotiate their own custom authentication and authorization policies.

Implementers of the MCP protocol must support JSON-RPC communication infrastructure and lifecycle management. Other capabilities can be implemented based on the specific needs of the application.

The MCP protocol adopts a modular design, which ensures rich interactions between clients and servers while clarifying and separating concerns.

MCP protocol message type

All messages between MCP clients and servers must follow the JSON-RPC 2.0 specification. The protocol defines the following types of messages:

Requests are sent from the client to the server and vice versa to initiate an operation.

{
  jsonrpc:  "2.0" ;
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

• The request must contain a string or integer ID.

• Unlike basic JSON-RPC, ID must not be null.

• The request ID must not have been used previously by the requester in the same session.

A response is sent as a reply to a request and contains the result of the operation or an error.

{
  jsonrpc:  "2.0" ;
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}

• Responses MUST contain the same IDs as the requests they correspond to.

• Responses are further broken down into either a successful result or an error. One of result or error MUST be set. Responses MUST NOT set both.

• Results can follow any JSON object structure, while errors must contain at least an error code and a message. The error code must be an integer.

Notifications are sent from a client to a server or vice versa as a one-way message. The receiver MUST NOT send a response.

{
  jsonrpc:  "2.0" ;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

• The notification must not include an ID.

JSON-RPC also defines a way to batch multiple requests and notifications by sending them in an array. MCP implementers MAY support sending JSON-RPC batches, but MUST support receiving JSON-RPC batches.

MCP protocol capability negotiation mechanism

The MCP protocol uses a capability-based negotiation system, where the client and server explicitly declare the capabilities they support during initialization. Capabilities determine the protocol features available during a session.

• Server-declared capabilities include resource subscriptions, tool support, and prompt templates

• Client-declared capabilities include sampling support and notification handling

• Both parties must respect the declared capabilities throughout the session

• Additional functionality can be negotiated through extensions to the protocol

The process of capability negotiation between the MCP client and the MCP server is as follows:

Each capability unlocks a specific protocol-supported feature for the duration of the session. For example:

• A server that implements the capability MUST indicate the capabilities it supports in its capabilities field.

• Issuing resource subscription notifications requires the server to declare support for subscriptions

• Tool calls require the server to declare tool capabilities

• Sampling requires the client to declare support in its capabilities

This capability negotiation ensures that clients and servers have a clear understanding of supported functionality while keeping the protocol extensible.

MCP protocol communication security

The MCP protocol provides powerful capabilities through arbitrary data access and code execution paths. Along with this powerful capability comes important security and trust considerations that all implementers must handle with care.

Key principles:

• Users must explicitly consent and understand all data access and operations

• Users must retain control over what data is shared and what actions are taken

• Protocol implementers should provide a clear user interface to review and authorize activities

• Hosts must obtain explicit consent from users before exposing user data to servers

• The host shall not transfer resource data to other places without the user's consent

• User data should be protected through appropriate access controls

• Tools represent arbitrary code execution and must be treated with caution.

In particular, descriptions of tool behavior (such as comments) should be considered untrustworthy unless coming from a trusted server.

• The host must obtain explicit consent from the user before invoking any tool

• Users should understand the functionality of each tool before authorizing its use

• The user must explicitly approve any LLM sampling request

• Users should control:

• Whether to perform sampling

• The actual reminder to send

• The results that the server can see

• The protocol intentionally limits the server's visibility into hints

Implementation Guide

While MCP itself cannot enforce these security principles at the protocol level, MCP protocol implementers SHOULD:

1. Build robust consent and authorization flows into their applications

2. Provide clear documentation of security impacts

3. Implement appropriate access controls and data protection

4. Follow security best practices in their integrations

5. Consider privacy implications in their feature designs

Summarize

The MCP protocol is a communication protocol based on a host-client-server architecture, designed to provide a secure and scalable external capability integration solution for large model applications. This article details the core architecture and key features of the MCP protocol:

• Adopt host-client-server three-tier architecture
• The host is responsible for coordinating and managing multiple client instances
• The client and server establish a 1:1 independent connection
• External programs that provide specific resources and capabilities to the server

• Simple server construction, focusing on specific capabilities
• The server is highly combinable and supports modular expansion
• Server isolation design, does not read the full conversation
• Functionality can be added incrementally, maintaining backward compatibility

• Basic protocol: JSON-RPC communication, connection lifecycle, transmission mechanism
• Features: resources, prompts, tools, samples, etc.
• Additional tools: configuration, progress tracking, error reporting, etc.
• Authentication and authorization: HTTP-based authorization framework

• Request: a two-way message containing methods and parameters
• Response: result matching the request ID or error
• Notification: One-way message, no response required
• Support batch processing of messages

• Emphasis on user consent and control
• Protecting data privacy
• Strictly control tool execution
• Manage LLM sampling permissions

Through this architectural design, the MCP protocol achieves secure and efficient integration of large model applications with external services while maintaining good scalability and flexibility. This design enables large model applications to securely access and use external resources, providing users with a richer functional experience.