Model Context Protocol

The Model Context Protocol (MCP) is an open protocol for connecting artificial-intelligence applications to external tools and data. An MCP-compatible application can discover functions, read resources and obtain reusable prompt templates through a common interface instead of implementing a separate integration format for every service.

MCP defines communication between a host application, one or more clients created by that host and independent servers that expose capabilities. Messages use JSON-RPC 2.0. A server can run locally as a child process or remotely over HTTP. The model does not connect to a server by itself: the host chooses what information and operations to make available and remains responsible for authorisation, consent and execution.

Anthropic published MCP in November 2024. The project was subsequently developed as an open ecosystem and donated in December 2025 to the Agentic AI Foundation under the Linux Foundation.

Purpose

An AI application may need access to files, source repositories, business databases, calendars, search services and many other systems. Their conventional APIs differ in authentication, data models and calling conventions. Without a common layer, each AI product must build and maintain a custom adapter for every service.

MCP standardises how a capability is described and invoked from an AI host. A server converts its underlying API, database or local library into MCP tools and resources. Any compatible host can then connect to it, subject to the user's credentials and the application's policies. The protocol does not standardise the underlying service itself and does not remove the need for its normal API.

The separation also limits coupling. A file server does not need to know which model a host uses, and the host does not need service-specific code for every operation. The same server can be used by editors, desktop assistants and automated agents.

Architecture

A host creates a separate MCP client for each local or remote server

Host

The host is the AI application that controls the overall interaction. It presents the user interface, communicates with the model, selects servers and decides which results enter the model context. It also enforces permissions, approval requirements, isolation and logging.

A host can connect to several servers at once. It creates a separate client for each connection so that credentials, capabilities and failures remain isolated. A coding editor, for example, may connect to a local file server, a remote issue tracker and a repository service.

Client

An MCP client is the protocol component inside the host. It sends requests, receives responses and exposes server capabilities to the rest of the application. In a multi-server host, every client maintains the relationship with one server.

The client does not decide business policy on its own. The host determines which tools to show to the model, whether an operation needs approval and how returned data is displayed or stored.

Server

An MCP server provides a related set of tools, resources and prompts. It can wrap a local directory, a database, a web service or a complete business system. The server validates arguments and authorisation and converts MCP requests into the native operation.

A local server typically runs with the user's operating-system permissions, while a remote server uses network authentication. In both cases the server should expose only the capabilities required for its intended purpose.

Protocol capabilities

Capability	Offered by	Purpose	Example
Tools	Server	Callable operations that can read or change an external system	Search, database query, create issue, send message
Resources	Server	Data identified by a URI and suitable for inclusion in context	File, database schema, document, project state
Prompts	Server	Reusable messages and workflows for common operations	Code review or report analysis template
Elicitation	Client	Obtain missing information or confirmation from the user	Select a project, complete a form, approve an action

Tools

A tool has a unique name, a description and a JSON Schema for its arguments. A client obtains the catalogue through tools/list and invokes an operation through tools/call. The server can return text, structured data, images, resource links or an error.

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Bishkek" }
  }
}

The description helps the model decide when to use a tool, but it is not trusted merely because it arrived through MCP. A host may show the operation and arguments to the user before execution.

Resources

A resource is data available at a URI: a text file, image, schema, document or application object. The application can let the user select a resource, retrieve one automatically or read it through resources/read. URI templates describe collections of similar objects.

Resources and tools differ in direction. A resource describes data that the application reads into context; a tool performs an operation and may change an external system. A server can offer both.

Prompts and extensions

Prompts let servers publish named message templates with arguments and embedded resources. A user interface may display them as commands or forms, whereas tools are more often selected by the model.

The 2026-07-28 specification introduced a formal extension system. Published extensions include Tasks for long-running asynchronous operations, MCP Apps for interactive user-interface elements and Skills over MCP for structured agent instructions. An extension is active only when both parties support it and does not alter the minimal core protocol.

Request flow

A typical operation proceeds as follows:

1. The host creates a client for a selected server.
2. The client obtains the capabilities available to the current user.
3. The host passes only relevant descriptions and data to the model.
4. The model chooses a tool and supplies its arguments, or the application selects a resource.
5. The client sends a JSON-RPC request.
6. The server validates authorisation and arguments, performs the operation and returns a result.
7. The host displays the result or provides it to the model as a new observation in an agent loop.

A server can report that more information is required. The client then obtains it from the user or model and repeats the operation. In the current protocol, this exchange uses multi-step independent requests rather than requiring one permanently open bidirectional session.

Transports

The specification separates message semantics from delivery. Version 2026-07-28 defines two standard transports:

• stdio: the client starts a local server as a child process and exchanges JSON-RPC messages through standard input and output;
• Streamable HTTP: the client sends each message by HTTP POST to one endpoint and receives JSON or a Server-Sent Events stream bounded to that request.

Stdio is suited to local tools and requires no listening network port. Streamable HTTP supports remote and scalable services with network authorisation, routing and observability.

Earlier MCP versions began with an initialize exchange and could maintain a session identifier. The 2026-07-28 core moved to independent requests that carry protocol, client and capability information. Implementations can detect an older peer and use the previous 2025-11-25 behaviour during the migration period.

MCP, APIs, function calling and RAG

MCP and APIs

An API defines the service's own endpoints, operations and data structures. MCP defines a common layer through which an AI host discovers and uses those capabilities. An MCP server often calls a conventional API internally; the protocol therefore complements rather than replaces APIs.

MCP and function calling

Function calling allows a model to produce a structured request for a function already described by its application. MCP addresses how the application obtains function descriptions from an independent server, invokes them and exchanges results. A host can translate MCP tools into the function-calling format of a particular model.

MCP and retrieval-augmented generation

Retrieval-augmented generation retrieves information and inserts selected passages into a model request. MCP may supply resources or a search tool for that pipeline, but it does not specify document chunking, indexing, ranking or answer generation. Either technology can be used without the other.

Example

A code editor can act as a host and connect to file, repository and issue-tracking servers. The user asks it to fix a reported bug. The model reads the issue through one server, reads files through another, edits them using the editor and checks repository state through a third.

MCP provides consistent catalogues and calls, while the editor's agent decides the sequence. File-write approval, permitted directories and permission to publish changes remain under host control.

Versions and governance

MCP versions use the publication date of a specification. The first public release appeared in November 2024. During 2025 the protocol gained a remote HTTP transport, standardised authorisation, asynchronous operations and an official server registry. The 2026-07-28 revision, current in November 2026, replaced the session-oriented core with independent requests, added routing headers, catalogue caching, formal extensions and a revised authorisation design.

The 2026 change is incompatible with parts of the previous communication model, so clients and servers may implement a transition mode. An SDK version and a protocol version are not the same: one library can support several specification revisions.

Authorisation and security

Connecting a server expands an application's abilities and its access surface. A server may see supplied data and a tool may act with the user's account. Publication in a registry does not by itself guarantee that the server or its descriptions are trustworthy.

The specification requires user control. Applications should make connected servers and tools visible, explain which data will be transmitted and allow consequential calls to be rejected. Tool descriptions and annotations are untrusted unless the server is trusted.

Remote HTTP servers use an authorisation design based on OAuth 2.1. The server acts as a protected resource, the client requests limited scopes and an authorisation server issues the token. Passing a token issued for another resource is forbidden because it breaks trust boundaries and hinders auditing.

Defences include trusted installation sources, least privilege, separation of read and write operations, approval for consequential actions, URI and argument validation, process isolation, protection against instructions embedded in documents, token-audience validation and audit logging. The security guidance also covers confused-deputy attacks, SSRF, redirect manipulation, state interception, token passthrough and compromise of a local server.

Frequently asked questions

Does MCP work only with Claude?

No. Anthropic created the protocol, but it is an open standard under independent governance. Any AI application or model can implement a compatible client or server.

Must an MCP server be on the internet?

No. Local servers commonly run as child processes over stdio. Remote servers use Streamable HTTP.

Does MCP give a model direct access to all data?

No. A server exposes only implemented capabilities, authorisation limits the current user and the host decides what to provide to the model. A poor configuration can still grant excessive privileges, so controls must exist at every layer.

See also

• AI agent
• Retrieval-augmented generation

External links

• Official Model Context Protocol documentation
• Project repositories on GitHub