Introduction
The Model Context Protocol (MCP) is designed to establish a standardized bridge between large language model (LLM) applications and external data sources and tools. This article takes an in-depth look at MCP's core concepts, lifecycle, key capabilities, and practical utilities. Drawing on the latest 2025-03-26 protocol revision and concrete JSON-RPC request/response examples, it offers developers a comprehensive hands-on guide.
Core MCP Components
MCP consists of several key components that work together:
- Base Protocol: Defines the core JSON-RPC message types.
- Lifecycle Management: Controls connection initialization, capability negotiation, and session management.
- Server Features: Features provided by servers, such as Resources, Prompts, and Tools.
- Client Features: Features provided by clients, such as Sampling and Roots.
- Utility Features: Cross-domain functionality such as Logging, Completion, Progress Tracking, and Cancellation.
All implementations MUST support the Base Protocol and Lifecycle Management. Other components can be implemented selectively based on application requirements.
Base Protocol: JSON-RPC Messages
MCP is built entirely on the JSON-RPC 2.0 specification.
Requests
Used to initiate an operation.
Responses
A reply to a request, containing either a result or an error.
A response MUST set either result or error, but MUST NOT set both.
Notifications
One-way messages that require no response.
Notifications MUST NOT contain an id.
Batching
MCP implementations MAY send batched requests or notifications, but MUST support receiving them.
Lifecycle Management
MCP connections follow a strict lifecycle: initialization -> operation -> shutdown.
Initialization Phase
This is the first interaction between the client and the server, used to negotiate the protocol version and exchange capabilities.
Initialization Request (from the client)
Note: The initialization request MUST NOT be included in a batch.
Initialization Response (from the server)
Version Negotiation: The client sends the latest version it supports. If the server supports it, the server returns the same version; otherwise, it returns the latest version supported by the server. If the client does not support the version returned by the server, the client SHOULD disconnect.
Capability Negotiation: Both parties declare the features they support and their subfeatures (such as listChanged and subscribe) through the capabilities object. Subsequent operations may use only the capabilities that were successfully negotiated.
Initialized Notification (from the client)
After receiving a successful initialize response, the client MUST send this notification to indicate that it is ready to enter the operation phase.
Before receiving the initialize response, the client should not send requests other than ping. Before receiving the initialized notification, the server should not send requests other than ping and logging.
Operation Phase
The parties communicate normally according to the negotiated capabilities and protocol version.
Shutdown Phase
Usually initiated by the client, this phase terminates the connection through the underlying transport mechanism (such as closing the stdio stream or HTTP connection). There is no dedicated MCP shutdown message.
Server Features in Detail
Servers can expose the following core features:
1. Resources
Resources let servers share context data (files, database schemas, etc.), with each resource identified by a unique URI.
Capability: resources (optional subscribe, listChanged)
List Resources (resources/list) (supports pagination)
Read Resource (resources/read)
Subscribe to Resource Changes (resources/subscribe) (requires the subscribe capability)
Resource Update Notification (notifications/resources/updated) (sent by the server to subscribers)
After receiving this notification, the client typically calls resources/read again to retrieve the latest content.
Resource List Changed Notification (notifications/resources/list_changed) (requires the listChanged capability)
After receiving this notification, the client typically calls resources/list again.
Resource Templates: Servers can expose parameterized URI templates (RFC6570) through resources/templates/list.
Common URI Schemes: https://, file://, git:// (implementations may define their own).
2. Tools
Tools let language models invoke external functionality provided by a server (APIs, computations, etc.).
Capability: tools (optional listChanged)
List Tools (tools/list) (supports pagination)
Note: Clients MUST treat tool annotations as untrusted unless they come from a trusted server.
Call Tool (tools/call)
Tool List Changed Notification (notifications/tools/list_changed) (requires the listChanged capability)
Security: Clients SHOULD ask users to confirm sensitive operations and display the tool inputs to prevent data leakage.
3. Prompts
Servers provide structured message templates that users can explicitly select when interacting with an LLM.
Capability: prompts (optional listChanged)
List Prompts (prompts/list) (supports pagination)
Get Prompt (prompts/get)
Prompt List Changed Notification (notifications/prompts/list_changed) (requires the listChanged capability)
Client Features in Detail
Clients can expose the following core features:
1. Roots
Roots let clients expose the boundaries of filesystem access to servers.
Capability: roots (optional listChanged)
List Roots (roots/list) (requested by the server)
Roots List Changed Notification (notifications/roots/list_changed) (sent by the client; requires the listChanged capability)
2. Sampling
Sampling lets a server ask the client to generate content through an LLM (text, images, or audio). The client controls model access and selection.
Capability: sampling
Create Message (sampling/createMessage) (requested by the server)
Security: Clients SHOULD implement a user approval flow that allows users to review and edit prompts before sending them.
Utility Features
MCP provides a range of optional supporting features:
Ping
Used to check whether a connection is alive.
Progress
Used to report the progress of long-running operations.
Request with progressToken: The sender (such as a client) includes a unique progressToken in the request's _meta.
Progress Notification (notifications/progress): The receiver (such as a server) sends progress updates.
Logging
Logging lets servers send structured logs to clients.
Capability: logging
Set Log Level (logging/setLevel): Clients can set the minimum log level that the server should send (debug, info, notice, warning, error, critical, alert, emergency).
Log Message Notification (notifications/message): The server sends a log.
Cancellation
Cancellation lets either party request the cancellation of a previously sent request that is still in progress.
Cancellation Notification (notifications/cancelled): Sent by the sender.
The receiver SHOULD stop processing the canceled request and SHOULD NOT send it a response. The sender SHOULD ignore any response to the canceled request that it may receive afterward.
Completion
The server provides completion suggestions for prompt arguments or resource URIs.
Capability: completions
Request Completion (completion/complete)
Pagination
For list operations that may return a large number of results (resources/list, tools/list, prompts/list, resources/templates/list), MCP uses cursor-based pagination.
Server Response: The server includes nextCursor in the result (if it is non-empty, this indicates that there are more pages).
Client Request for the Next Page: The client includes the received cursor in the request's params.
Clients MUST treat cursors as opaque strings.
Error Handling
MCP uses the standard JSON-RPC error codes.
- -32600 Invalid Request: Invalid JSON or noncompliance with the specification.
- -32601 Method not found: The method does not exist or is unavailable.
- -32602 Invalid params: Invalid method parameters.
- -32603 Internal error: An internal server error.
- -32000 to -32099 Server error: Implementation-specific server errors (for example,
-32002for a resource that was not found).
Security and Trust
MCP implementers MUST carefully consider security and trust issues:
- User Consent and Control: All data access and operations require explicit user consent.
- Data Privacy: User data must not be shared without consent.
- Tool Safety: Tool calls represent code execution, so they must be handled carefully and require user consent.
- Sampling Controls: Users should be able to control sampling requests and review the results.
- Validation: Both clients and servers must validate inputs and outputs.
- Permissions: Implement appropriate access controls.
Conclusion
Through its standardized messages, lifecycle management, and rich feature set, the Model Context Protocol (MCP) provides a strong foundation for building powerful, secure, and interoperable AI applications. Understanding its core concepts and protocol details, along with concrete request/response examples, will help developers use MCP effectively to connect LLMs to the external world.
References: