---
title: "MCP Specifications"
source: Panaversity Learn Agentic AI
source_url: https://github.com/panaversity/learn-agentic-ai
licence: Apache-2.0
domain: agentic-ai
subdomain: panaversity-agentic
date_added: 2026-04-25
---

# MCP Specifications

[Specs Intro](https://modelcontextprotocol.io/specification/2025-06-18)

[Architecture](https://modelcontextprotocol.io/specification/2025-06-18/architecture)

[Basic](https://modelcontextprotocol.io/specification/2025-06-18/basic)

[Lifecycle](https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle)

[Transports](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports)

[Authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)

[Cancellation](https://modelcontextprotocol.io/specification/2025-06-18/basic/utilities/cancellation)

[Ping](https://modelcontextprotocol.io/specification/2025-06-18/basic/utilities/ping)

[Progress](https://modelcontextprotocol.io/specification/2025-06-18/basic/utilities/progress)

Client Features

[Roots](https://modelcontextprotocol.io/specification/2025-06-18/client/roots)

[Sampling](https://modelcontextprotocol.io/specification/2025-06-18/client/sampling)

[Elicitation](https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation)

Server Features

[Overview](https://modelcontextprotocol.io/specification/2025-06-18/server)

[Prompts](https://modelcontextprotocol.io/specification/2025-06-18/server/prompts)

[Resources](https://modelcontextprotocol.io/specification/2025-06-18/server/resources)

[Tools](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)


## **Introduction to the Model Context Protocol (MCP)**

The Model Context Protocol (MCP) is an open-source protocol designed to standardize the integration of external data sources and tools with Large Language Model (LLM) applications. It provides a structured way for LLM applications, such as AI-powered Integrated Development Environments (IDEs), chat interfaces, and custom AI workflows, to connect with the necessary context. Inspired by the Language Server Protocol (LSP), MCP aims to create a more cohesive and interoperable ecosystem for AI applications by enabling them to share contextual information, expose tools to AI systems, and build composable integrations. The protocol is defined by a TypeScript schema and uses JSON-RPC 2.0 for communication.

### **MCP Architecture**

The MCP architecture is based on a client-host-server model, which promotes clear security boundaries and separation of concerns.

* **Host:** The host is the primary application that manages and coordinates multiple client instances. It is responsible for creating and managing clients, controlling their permissions and lifecycle, enforcing security policies, and handling user authorization. The host also aggregates context from various clients and coordinates the overall AI/LLM integration and sampling process.
* **Client:** Each client is created by the host and maintains a one-to-one relationship with a server. The client establishes a stateful session with its server, handles protocol negotiation and capability exchange, and routes messages between the host and the server. It also manages subscriptions, notifications, and the security boundaries between servers.
* **Server:** Servers are specialized services that provide context, resources, tools, and prompts to the host through the client. They can be local processes or remote services and operate independently with focused responsibilities. Servers must respect the security constraints imposed by the host and can request sampling from the host via the client.

### **Basic Concepts**

The MCP is built on a modular architecture, with a core base protocol that all implementations must support. This base protocol defines the fundamental JSON-RPC 2.0 message types for all interactions. Key components of the protocol include:

* **Lifecycle Management:** This handles connection setup, capability negotiation, and session control between the client and server.
* **Authorization Framework:** Provides a secure way for clients to communicate with servers over HTTP.
* **Server Features:** Allow servers to expose resources and tools.
* **Client Features:** Enable clients to perform tasks such as sampling.

All communication between clients and servers must adhere to the JSON-RPC 2.0 specification, which includes requests, responses, and notifications.

### **Lifecycle of a Context**

The lifecycle of a connection between a client and a server in MCP consists of three distinct phases:

1.  **Initialization:** The lifecycle begins with the client sending an "initialize" request to the server. This request includes the client's supported protocol version, its capabilities, and information about itself. The server responds with its own supported protocol version and capabilities. If the versions are incompatible, the connection is terminated. Once a compatible version is agreed upon, the client sends an "initialized" notification to signal the end of this phase.
2.  **Operation:** After successful initialization, the connection enters the operation phase. During this phase, the client and server exchange messages and perform actions based on their negotiated capabilities. It is crucial that both parties adhere to the agreed-upon protocol version and features to ensure smooth communication.
3.  **Shutdown:** This phase is initiated to gracefully terminate the connection, typically by the client. The MCP relies on the underlying transport mechanism to signal the end of the connection. For example, with a standard I/O transport, the client closes its input stream to the server.

### **Transports**

MCP uses JSON-RPC for encoding messages, and the specification outlines two standard transport mechanisms:

* **stdio:** This is the recommended transport for clients and involves the client launching the MCP server as a subprocess. Communication occurs over the server's standard input and output, with messages delimited by newlines.
* **Streamable HTTP:** This transport allows the server to operate as an independent process that can handle multiple client connections via HTTP POST and GET requests. It can optionally use Server-Sent Events (SSE) for streaming server messages. The specification provides details on the HTTP headers, status codes, and security considerations for this transport, such as validating the `Origin` header to prevent DNS rebinding attacks.

### **Authorization**

The MCP specification includes an optional authorization framework for HTTP-based transports, allowing clients to make requests to restricted servers on behalf of resource owners. This mechanism is based on established specifications like OAuth 2.1 and defines the roles of the protected MCP server, MCP client, and authorization server.

The authorization flow involves the MCP server advertising its associated authorization server to the client. The client then discovers the authorization server's endpoints and capabilities. The specification also details the implementation of resource parameters and access token usage, including token requirements and handling. Additionally, it addresses security considerations such as token audience binding, token theft, and communication security.

### Utilities

These are optional but helpful features for managing the connection between a client and a server.

* **Cancellation:** Allows either the client or the server to cancel a request that is already in progress. This is useful for stopping long-running tasks that are no longer needed. The party that wants to cancel sends a `notifications/cancelled` message with the ID of the request to be cancelled.
* **Ping:** A simple way to check if the connection is still active. Either the client or server can send a `ping` request, and the other party must respond promptly. If a response isn't received, the connection can be considered stale.
* **Progress:** Provides a way for servers to report the progress of a long-running operation to the client. This is useful for providing feedback to the user, for example, by displaying a progress bar.

### Client Features

These are capabilities that the client can offer to the server.

* **Roots:** These are URIs that define the working directories or "safe zones" for a server. By setting roots, a client can restrict a server's access to specific files, folders, or even API endpoints, enhancing security and control. For example, you could limit a file system server to only operate within a specific project directory.
* **Sampling:** This feature reverses the usual flow of information. Instead of the client always making requests to the server, sampling allows the *server* to request that the *client* run a text generation task using the LLM. This is a powerful feature for creating more advanced, agent-like behaviors.
* **Elicitation:** A brand-new feature that allows a server to dynamically request additional information from the user through the client. If a server needs more context to complete a task (like a user's preference or a missing piece of information), it can send an `elicitation/create` request to the client, which will then prompt the user for the needed input.

### Server Features

These are the core capabilities that a server can expose to a client.

* **Overview:** MCP servers can expose three main types of features: resources, prompts, and tools. This allows for a flexible and powerful way to extend the capabilities of an LLM.
* **Prompts:** These are pre-defined message templates or workflows that a server can offer to a client. They provide a standardized way to interact with the LLM for common tasks, guiding the user or the AI model.
* **Resources:** These allow a server to expose data and content to be used as context by the LLM. This could be anything from the content of a file to the records in a database.
* **Tools:** These are executable functions that a server can make available to the LLM. This is what allows the AI to perform actions in the real world, like sending an email, interacting with an API, or running a calculation. Tools are designed to be "model-controlled," meaning the LLM can decide to use them on its own (with user approval).
