Skip to main content

​
MCP Core Concepts

​
1.1 What Problem Does MCP Solve

Every AI application needs to connect to external systems. Before MCP, each AI application had to write custom integration code for every external system. N AI applications x M external systems = N x M integrations. MCP reduces this to N + M: each AI application implements one MCP Client, and each external system implements one MCP Server. They communicate through a standard protocol, enabling arbitrary combinations. This design is directly inspired by Microsoft’s Language Server Protocol (LSP). LSP solved the “every editor x every language” integration explosion problem; MCP applies the same approach to solve the “every AI application x every external system” problem. Protocol Version: 2025-11-25 Specification: modelcontextprotocol.io Specification Repository: github.com/modelcontextprotocol/specification

​
1.2 Three Participants

​
MCP Host

The AI application itself. Responsible for managing one or more MCP Clients. Examples: Claude Desktop, VS Code (Copilot), ChatGPT, Cursor Host responsibilities:
  • Starting and managing MCP Client connections
  • Exposing MCP Server capabilities (tools, resources) to the AI model
  • Handling user interactions
  • Enforcing security policies (e.g., requiring user confirmation for tool calls)

​
MCP Client

A component created internally by the Host for each Server connection. Each Client maintains a 1:1 dedicated connection with one MCP Server. You typically do not need to develop a Client directly — the Host creates and manages them automatically. A Client can also expose its own capabilities to the Server (Sampling, Roots, Elicitation), enabling the Server to make reverse requests for LLM inference or user input.

​
MCP Server

A program that provides tools, data, and prompts. This is the component most developers need to build. Examples:
  • Filesystem Server: lets AI read and write local files
  • Database Server: lets AI query databases
  • Sentry Server: lets AI view error logs
  • Your commerce Server: lets AI search products, check orders

​
Architecture Diagram

┌─────────────────────────────────────────┐
│           MCP Host (AI Application)     │
│                                         │
│  ┌──────────┐  ┌──────────┐            │
│  │ Client 1 │  │ Client 2 │  ...       │
│  └─────┬────┘  └─────┬────┘            │
└────────┼─────────────┼──────────────────┘
         │ 1:1         │ 1:1
    ┌────┴────┐   ┌────┴────┐
    │Server A │   │Server B │
    │(local)  │   │(remote) │
    │stdio    │   │HTTP     │
    └─────────┘   └─────────┘
A single Host can connect to multiple Servers. Each Client-Server pair maintains an independent stateful connection. Local Servers communicate via stdio, while remote Servers communicate via Streamable HTTP.

​
1.3 Protocol Lifecycle

MCP is a stateful protocol. A connection goes through three phases: initialization, operation, and shutdown.

​
Phase 1: Initialization

The Client sends an initialize request. Both sides negotiate the protocol version and supported capabilities. 
// Client -> Server: initialize request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "sampling": {},
      "elicitation": {},
      "roots": { "listChanged": true }
    },
    "clientInfo": { "name": "my-app", "version": "1.0.0" }
  }
}

// Server -> Client: initialize response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "prompts": { "listChanged": true }
    },
    "serverInfo": { "name": "my-server", "version": "1.0.0" }
  }
}

// Client -> Server: initialized notification (confirms initialization is complete)
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}
Key aspects of capability negotiation:
  • The Client declares what it supports (e.g., sampling for LLM inference, elicitation for user interaction, roots for filesystem boundaries)
  • The Server declares what it provides (e.g., tools, resources, prompts)
  • Both sides only use capabilities declared by the other party
  • Protocol versions must match; otherwise initialization fails
Timeout mechanism: The initialization phase has a timeout. If the Server does not respond within the specified time, the Client should disconnect.

​
Phase 2: Operation

After initialization completes, the normal operation phase begins. The Client can discover and invoke Server capabilities: 
// Client -> Server: discover tools
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

// Server -> Client: tool list
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "search_products",
        "title": "Product Search",
        "description": "Search the product catalog",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": { "type": "string", "description": "Search keyword" }
          },
          "required": ["query"]
        }
      }
    ]
  }
}
Tool execution: When the AI model decides to use a tool, it invokes it through the Client: 
// Client -> Server: call tool
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "search_products",
    "arguments": { "query": "running shoes" }
  }
}

// Server -> Client: tool result
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      { "type": "text", "text": "[{\"name\": \"Nike Air Max\", \"price\": 899}]" }
    ]
  }
}
Notification mechanism: The Server can proactively notify the Client of tool list changes (must be declared during initialization with listChanged: true): 
// Server -> Client (notification, no id, no response expected)
{ "jsonrpc": "2.0", "method": "notifications/tools/list_changed" }
Upon receiving this, the Client re-requests tools/list to get the latest list.

​
Phase 3: Shutdown

Either side can initiate connection closure. After shutdown, all pending requests should be cancelled and resources should be cleaned up.

​
1.4 Complete Primitive Overview

MCP Primitives are divided into Server-side and Client-side categories:

​
Server-Side Primitives (Server provides to Client)

PrimitiveControlled ByDiscovery MethodExecution MethodPurpose
ToolsModeltools/listtools/callExecutable functions (query databases, call APIs, etc.)
ResourcesApplicationresources/listresources/readData sources (files, records, API responses)
PromptsUserprompts/listprompts/getReusable interaction templates
What “Controlled By” means:
  • Model-controlled (Tools): The AI model autonomously decides when to call which tool
  • Application-controlled (Resources): The Host application decides when to read which resources to provide to the model
  • User-controlled (Prompts): The user actively selects which prompt template to use

​
Client-Side Primitives (Client provides to Server)

PrimitiveMethodPurpose
Samplingsampling/createMessageServer requests LLM inference from the Host. Supports model preference settings: hints (model suggestions), costPriority / speedPriority / intelligencePriority (priority trade-offs)
Rootsroots/listServer queries the Client’s filesystem boundaries. Returns a list of file:// URIs indicating which directories the Server can access
Elicitationelicitation/requestServer requests the Client to ask the user for information. Suitable for scenarios requiring user confirmation or supplementary input

​
Content Types

Tool results, resource data, and other outputs use a unified content type system:
TypeDescriptionExample
textPlain textJSON data, descriptive text
imageImageBase64-encoded or URI reference
audioAudioVoice data (Base64-encoded)
resource_linkResource linkReference to an MCP resource URI
embedded_resourceEmbedded resourceInline resource data
All content types support an annotations metadata field for marking audience, priority, and other information.

​
1.5 Experimental Features

​
Tasks

Tasks is an experimental feature that provides a wrapper for long-running operations. When tool call results cannot be returned immediately (e.g., asynchronous processing, long-running computations), the Task mechanism enables deferred delivery.

​
1.6 What MCP Does Not Do

MCP focuses on context exchange and does not cover:
  • How AI models process context (that is the AI application’s concern)
  • AI model selection and configuration
  • User interface design
  • Business logic and workflow orchestration
MCP is solely responsible for: standardized communication between AI applications and external systems.
Next Chapter: Data Layer Protocol — JSON-RPC 2.0 message format and capability negotiation in detail