# Model Context Protocol

> Source: https://aiwiki.ai/wiki/model_context_protocol
> Updated: 2026-07-29
> Fact-checked: 2026-07-29
> Categories: AI Tools & Products, Artificial Intelligence, Large Language Models
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "Model Context Protocol." aiwiki.ai, 29 Jul 2026. https://aiwiki.ai/wiki/model_context_protocol
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

Model Context Protocol (MCP) is an open protocol for exchanging context and invoking capabilities between applications that use large language models and external programs or data sources. Anthropic announced and open-sourced MCP on November 25, 2024. The project's repository names David Soria Parra and Justin Spahr-Summers as its creators.[1][2] MCP uses a host, client, and server architecture: a host application creates a protocol client for each connected server, while servers expose resources, prompts, tools, and optional features through a versioned JSON-RPC interface.[3]

MCP standardizes communication at the boundary between an AI application and a capability provider. It does not define a model architecture, a complete agent loop, how a host constructs a prompt, or whether returned information is safe or correct. A host decides how to present servers and permissions to a user, how to pass information to a [large language model](https://aiwiki.ai/wiki/large_language_model), and how to handle results.[3]

The project released protocol revision `2026-07-28` as a stable release on July 28, 2026. Its dated specification replaced the connection-scoped initialization model of earlier revisions with stateless requests, per-request version and capability metadata, and a mandatory server-discovery method.[4][5]

| Property | Description |
|---|---|
| Initial public release | November 25, 2024 |
| Creators | David Soria Parra and Justin Spahr-Summers |
| Current stable revision | `2026-07-28` |
| Message format | JSON-RPC 2.0 |
| Standard transports | stdio and Streamable HTTP |
| Main server features | Resources, prompts, and tools |
| Active client feature | Elicitation |
| Deprecated client features | Roots and sampling |
| Governance | Project maintainers using Specification Enhancement Proposals |
| Foundation home | Agentic AI Foundation, a Linux Foundation directed fund |
| Licensing | Apache-2.0 and CC BY 4.0 for new contributions, with some older material remaining MIT |

## Purpose and scope

Before MCP, an AI application that needed access to several data systems commonly depended on a separate integration for each system. MCP provides a shared protocol boundary that can let multiple compatible hosts connect to separately developed servers. The protocol can reduce duplicated adapter work, but it does not guarantee that any two implementations support the same optional features or interpret a capability in the same way.[1][3]

A server can represent a local program launched by a desktop application, a service on the same machine, or a remote network service. Possible integrations include files, databases, source-control operations, search services, business applications, and specialized computation. These are uses that a server may implement; they are not built-in MCP data sources.[3][9][10]

The protocol deliberately separates communication from model choice. An MCP host can use a proprietary or open model, provide a graphical or command-line interface, and decide whether a person or an automated policy approves an operation. MCP also does not require every host or server to implement every optional feature. In revision `2026-07-28`, a client declares relevant capabilities on each request, and a server reports its capabilities through `server/discover`.[6][7][8]

The term "context" in the name is broader than retrieved text. A server can expose readable resources, reusable prompt templates, executable tools, or an elicitation request for additional user input. The host determines whether and how those objects enter the model's context window or application workflow.[3][11][12][13][17]

## Architecture

MCP documentation distinguishes three roles.[3]

- A **host** is the application that coordinates the user experience, model interaction, permissions, and one or more protocol clients. Examples can include a coding assistant, a desktop chat application, or another [AI agent](https://aiwiki.ai/wiki/ai_agents) host.
- A **client** is the protocol component inside the host that communicates with one server. A host normally creates a separate client for each server connection.
- A **server** is a program or network service that exposes capabilities through MCP. It can run locally or remotely.

A dedicated client-server transport relationship is not a protocol session. Under `2026-07-28`, a server must not infer protocol version, client identity, capabilities, conversation identity, or other request context from an earlier exchange on the same connection. State that spans calls must be represented by an explicit identifier that the client sends again.[3][6]

The documentation separates two layers:

1. The **data layer** defines JSON-RPC messages, version and capability discovery, protocol features, and message patterns.
2. The **transport layer** carries those messages between participants and defines framing, connection behavior, and HTTP authorization where applicable.

All MCP messages use JSON-RPC 2.0 envelopes. A client request has a method, an identifier, and optional parameters; a notification has no response; and a server returns either a result or an error. Revision `2026-07-28` requires successful results to include `resultType`. Ordinary final results use `"complete"`, while an interim multi-round-trip result uses `"input_required"`. For compatibility, clients must treat a missing `resultType` from an earlier-version server as `"complete"`.[6]

### Stateless requests and version selection

Every modern MCP request includes two required namespaced fields in `params._meta`: `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities`. A client should also include `io.modelcontextprotocol/clientInfo` unless it has been configured not to identify itself. A server should place its own implementation identity in `io.modelcontextprotocol/serverInfo` in result metadata.[5][6]

Servers must implement `server/discover`. Its response lists the server's supported protocol revisions, capabilities, implementation identity, optional instructions, and caching metadata. Calling it is optional for a client: the client can instead send another request immediately. If the requested revision is unsupported, a modern server returns `UnsupportedProtocolVersionError` with code `-32022` and a list of supported revisions, allowing the client to retry with a mutually supported version.[7][8]

The discovery result is descriptive rather than an authentication proof. Server identity is self-reported, and the specification warns clients not to use it as a security decision. Capability declarations likewise indicate supported protocol behavior; they do not prove that a server is benign or that its implementation is correct.[8]

Optional extensions are advertised in the `extensions` map within client and server capabilities. An extension identifier must use a namespaced key. If only one party supports an extension, it must fall back to core behavior or reject the request as the extension specifies.[7]

The specification calls `2026-07-28` and later revisions **modern** and calls `2025-11-25` and earlier revisions **legacy**. Dual-era clients and servers may support both models. A dual-era stdio client normally probes with `server/discover`; a response or recognized modern error selects modern behavior, while an unrecognized error or timeout can trigger the old `initialize` handshake. HTTP clients use the transport's status and error-body rules for the same distinction.[7][9][10]

## Transports

The current specification defines stdio and Streamable HTTP as standard transports. A custom transport may be defined if it preserves MCP's JSON-RPC message and stateless-request rules.[9][10]

### stdio

With stdio, a client launches a server as a subprocess. The server reads JSON-RPC messages from standard input and writes messages to standard output. Each message occupies one line and must not contain an embedded newline. Diagnostic text can be written to standard error, but neither participant may mix non-protocol text into the protocol stream.[9]

The client sends requests and notifications; the server sends responses and notifications. A `2026-07-28` server must not send a standalone JSON-RPC request back to the client. If it needs elicitation, sampling, or roots information while processing a request, it returns an `InputRequiredResult` and lets the client retry the original request with the requested inputs.[9][16]

stdio is convenient for local integrations because the host controls the child process and no network port is required. It is not a sandbox. Starting a local server executes code with the operating-system rights available to that process. Hosts should identify the command that will run, pass only necessary environment variables, and restrict filesystem or network access where practical.[24][51]

The HTTP authorization framework does not apply to stdio; an implementation that needs credentials should obtain them from its environment. Shutdown normally begins when the client closes the input stream. If a process restarts, in-flight requests are lost and active subscriptions must be established again, because the protocol does not preserve state across the restart.[6][9][21]

### Streamable HTTP

Under `2026-07-28`, a Streamable HTTP server exposes one MCP endpoint that accepts POST. Each client request or notification is a separate POST. A request receives either one JSON response or a request-scoped Server-Sent Events stream containing related notifications and the final response. A successful notification POST returns HTTP `202 Accepted` without a body.[10]

The revision removed the optional HTTP GET stream and the `Mcp-Session-Id` mechanism used by earlier Streamable HTTP revisions. Long-lived change notifications now travel on the response stream of a POSTed `subscriptions/listen` request. Server-to-client input requests are represented through multi-round-trip results rather than independent JSON-RPC requests.[5][10][15][16]

Each request POST includes the protocol revision in `MCP-Protocol-Version` and the method in `Mcp-Method`. Calls to `tools/call`, `resources/read`, and `prompts/get` also require `Mcp-Name`, derived from the request's name or URI. The server validates these headers against the JSON body and returns a `HeaderMismatch` error with code `-32020` when required values are absent, malformed, or inconsistent.[10]

The transport does not support resuming an interrupted SSE stream with `Last-Event-ID`. If a response stream breaks, the in-flight request is lost; a client that retries sends a new request with a new JSON-RPC identifier. Request-scoped notifications stay on their originating response stream, whereas opted-in list and resource changes stay on the corresponding `subscriptions/listen` stream.[5][10][15]

Network deployment introduces origin, authentication, and metadata-discovery risks. Streamable HTTP servers must validate an incoming `Origin` header and reject an invalid origin. A server running locally should bind to loopback rather than all network interfaces, and remote deployments should use appropriate authentication and encrypted transport.[10][21][23]

## Server features

Servers can expose three principal feature groups: resources, prompts, and tools. Each is optional and has a different intended interaction model.[11][12][13]

### Resources

Resources are application-controlled data made available by a server. Each resource has a URI and can contain text or binary data. Metadata can include a name, title, description, media type, size, annotations, and icons.[11]

Clients use `resources/list` to enumerate resources, `resources/read` to retrieve one, and `resources/templates/list` to discover parameterized URI templates. List operations can be paginated. Revision `2026-07-28` requires complete results from these methods to carry `ttlMs` and `cacheScope` caching hints.[11][14]

Resource updates and resource-list changes are opt-in notifications. A client opens `subscriptions/listen` and requests `resourceSubscriptions` for selected URIs or `resourcesListChanged` for changes to the list. This mechanism replaces the earlier `resources/subscribe` and `resources/unsubscribe` methods.[5][11][15]

The protocol does not prescribe one universal resource URI scheme. A server can use familiar schemes such as `file` or `https`, or define a custom scheme. A URI names content in that server's interface; it does not grant access. The server must validate and authorize each read.[11][23]

Resources can also appear in tool results as links or embedded content. Hosts should retain provenance and avoid treating resource text as trusted instructions merely because it arrived in a structured field.[11][24]

### Prompts

Prompts are server-defined templates intended for user-controlled selection. A client discovers them with `prompts/list` and retrieves a named template with `prompts/get`. A prompt result contains messages whose content can include text, images, audio, embedded resources, or resource links.[12]

The "user-controlled" description is an interaction model, not a required graphical design. A host can expose prompts as commands, menu items, buttons, or another interface. List results carry caching hints, and a server that advertises prompt-list changes can deliver them to an opted-in `subscriptions/listen` stream.[12][14][15]

A prompt remains server-supplied content. Hosts should show its source and should not assume that user selection makes every instruction or linked resource trustworthy.[12][24]

### Tools

Tools are executable functions exposed by a server. The specification describes them as model-controlled because a model can select a tool based on a task, but it does not require automatic execution. A client discovers tools through `tools/list` and invokes one with `tools/call`.[13]

Each tool has a unique name and an input schema, plus optional title, description, output schema, icons, execution metadata, and annotations. Schemas use JSON Schema 2020-12. A declared output schema constrains the tool's structured output. The 2026 revision permits the full set of JSON Schema 2020-12 keywords subject to its `$ref` and resource-bound rules.[5][13]

Tool results can contain text, images, audio, resource links, embedded resources, or structured data. A tool can report a tool-level error inside an otherwise successful protocol result. A server can also return `resultType: "input_required"` when it needs a supported client input before completing the call.[13][16]

Tool annotations can describe such properties as read-only, destructive, idempotent, or open-world behavior. They are untrusted hints, not enforcement. Official guidance recommends clear tool provenance, visibility into arguments, and a way for a person to deny sensitive invocations.[13][24][25]

For cache stability, a server should return tools in deterministic order. Complete tool-list results must include `ttlMs` and `cacheScope`; a relevant list-change notification invalidates a cached result even before its time-to-live expires.[5][13][14]

## Client features and shared patterns

### Multi-round-trip requests

Revision `2026-07-28` removes independent server-initiated JSON-RPC requests. When a server needs client input to finish a supported operation, it can return an `InputRequiredResult` with `resultType: "input_required"`. Its `inputRequests` map may contain elicitation, sampling, or roots requests that the client declared it can handle. The result can also contain an opaque `requestState` value.[16]

After satisfying the input requests, the client retries the original operation with `inputResponses` and echoes `requestState` exactly when one was supplied. The server must not assume that the client will comply or retry. This pattern keeps each network exchange client-initiated while supporting more than one interaction round.[16]

### Elicitation

Elicitation is the active client feature through which a server can request additional information from a person. It is available only when the client declares the relevant capability. The current revision supports form mode for structured non-sensitive input and URL mode for an interaction that occurs at an external address.[17]

Form mode uses a restricted schema and must not request secrets such as passwords, API keys, access tokens, or payment credentials. URL mode is suited to authenticated or sensitive input handled outside the MCP client. Under the multi-round-trip design, the client returns the outcome by retrying the original request; the `notifications/elicitation/complete` signal from `2025-11-25` was removed.[5][17]

Clients should display which server is asking, let the user decline or cancel, validate URLs before opening them, and avoid sending information beyond the stated request.[17][24]

### Deprecated roots, sampling, and logging

Roots let a client describe URI boundaries such as project directories to a server. Sampling lets a server ask the host to obtain a model completion. Logging lets a server send structured log messages to a client. All three remain specified and functional in `2026-07-28`, but they are deprecated: new implementations should not add them, and existing implementations should migrate.[18][19][31]

The suggested alternatives are to pass directories or files through tool parameters, resource URIs, or server configuration instead of roots; integrate directly with model-provider APIs instead of sampling; and write logs to standard error for stdio or use OpenTelemetry for observability. Roots were never an access-control boundary, and sampling never transferred the host's model-selection or credential policy to the server.[18][19][31]

The feature-lifecycle policy normally requires at least twelve months between deprecation and eligibility for removal. An expedited removal for an active security risk still requires at least ninety days and Core Maintainer approval. Deprecation therefore does not mean that a feature disappeared from the July 2026 protocol.[31][32]

### Tasks extension

Tasks were experimental core functionality in `2025-11-25`. In `2026-07-28`, they moved into the official `io.modelcontextprotocol/tasks` extension and were redesigned.[5][20]

The extension lets a server return a durable task handle for long-running work. A client polls with `tasks/get`, supplies requested mid-flight input with `tasks/update`, and can request cancellation with `tasks/cancel`. Task status notifications can be delivered through `subscriptions/listen`. Support is negotiated through the extensions capability map; it is not implied by support for the core protocol.[20]

## Authorization

MCP authorization is optional and applies to HTTP-based transports, not to stdio. A protected MCP server acts as an OAuth resource server, and a separate authorization server can authenticate the user and issue access tokens for that MCP server.[21]

The server publishes OAuth Protected Resource Metadata so clients can discover its authorization servers. Clients then validate OAuth Authorization Server Metadata or OpenID Connect Discovery documents. Each authorization-server issuer is a separate security boundary, and stored client credentials must be keyed to the issuer that issued them.[21][22]

Public clients use an authorization-code flow with Proof Key for Code Exchange. Clients send an RFC 8707 Resource Indicator so a token is bound to the intended MCP server. Authorization servers should include the RFC 9207 `iss` parameter in authorization responses, and a client must compare any present value with the validated issuer it recorded before redirecting the user.[21][23]

Client registration has a priority order: use a pre-established client identifier when available, otherwise prefer Client ID Metadata Documents when supported, and use Dynamic Client Registration only as a fallback. Dynamic Client Registration remains available for compatibility but is deprecated in `2026-07-28`. A client that uses it must provide an appropriate OpenID Connect `application_type` and must not reuse the resulting credentials with another issuer.[22][31]

An MCP server must validate that an access token was issued for it. It must not pass that same token through to an upstream API; the server needs a separate token appropriate to the downstream audience. Token passthrough erases the intended resource boundary and can create a confused-deputy vulnerability.[23][24]

Scopes should follow least privilege and can expand when a specific operation requires more permission. Authentication establishes an identity or grant; it does not establish that a server's instructions, tool descriptions, or returned content are trustworthy.[21][23][24]

## Security and trust model

MCP defines an interoperability protocol, not a package-certification, sandboxing, or model-safety system. Security depends on the host, server, authorization service, operating system, deployment configuration, and user interface.[23][24]

Official security material describes several recurring risks.[23][24]

| Threat | Example | Relevant control |
|---|---|---|
| Confused deputy | A proxy reuses an upstream grant for a client the user did not approve | Bind consent to the requesting client and intended resource |
| Token passthrough | A server forwards the MCP access token to another API | Validate audience and obtain a separate downstream token |
| Server-side request forgery | A client follows malicious authorization metadata to an internal address | Validate discovery URLs, restrict redirects, and control network egress |
| Local code execution | A host launches an untrusted local server package | Verify the command and publisher, isolate the process, and grant least privilege |
| Tool poisoning | Tool metadata or output contains deceptive instructions for the model | Preserve provenance, treat annotations as untrusted, and require approval for consequential actions |
| Overbroad access | A server receives more filesystem or API authority than its task needs | Use narrow credentials, resource-specific scopes, and operation-specific confirmation |

Prompt injection remains possible when a model consumes untrusted resources, prompt templates, tool descriptions, or tool results. Structured messages help preserve type and provenance, but they do not make content safe. Hosts should distinguish server data from system policy, validate outputs before consequential use, and keep high-impact actions reviewable.[13][24][25]

`serverInfo` is self-reported, roots are descriptive rather than a sandbox, tool annotations are claims rather than verified behavior, and OAuth grants access rather than wisdom. Treating any of these as a complete trust control creates false assurance.[8][18][23][25]

Local servers require special care because installing or starting one can execute arbitrary code. [Visual Studio Code](https://aiwiki.ai/wiki/visual_studio_code), for example, warns users to understand an MCP server before starting it. Organizations can add allowlists, signed packages, containers, restricted service accounts, network policy, and audit logging, but those are deployment controls rather than base-protocol requirements.[51]

A peer-reviewed survey in ACM Transactions on Software Engineering and Methodology organizes MCP threats across server creation, deployment, operation, and maintenance.[26] Its taxonomy provides a way to review a system systematically; it does not establish that every described attack has occurred or provide a universal incident rate.

## Version history

MCP revisions use dates in `YYYY-MM-DD` form. Implementations must name the revision whose behavior they implement because lifecycle, transport, and feature semantics differ substantially between releases.[7]

### `2024-11-05`

The initial final specification accompanied Anthropic's public launch on November 25, 2024. It established the host-client-server model, JSON-RPC messages, resources, prompts, tools, roots, sampling, capability negotiation, and a stateful initialization lifecycle.[1][27]

Its HTTP transport used separate Server-Sent Events and POST endpoints. That HTTP+SSE transport is now deprecated, but the original revision remains relevant to compatible legacy implementations.[27][31]

### `2025-03-26`

This revision introduced Streamable HTTP as the replacement for HTTP+SSE, an OAuth-based authorization framework, and tool annotations. It retained an initialization handshake and allowed optional HTTP sessions.[28]

### `2025-06-18`

The June revision removed JSON-RPC batching and added structured tool output, elicitation, resource links in tool results, and the HTTP protocol-version header. Authorization changes included OAuth Protected Resource Metadata and Resource Indicators.[29]

Removing batching illustrates why JSON-RPC conformance alone does not determine MCP behavior: JSON-RPC 2.0 permits batch payloads, but MCP revisions from June 2025 onward do not.[29][48]

### `2025-11-25`

The November 2025 revision added or expanded OpenID Connect Discovery, incremental authorization scopes, icons, URL-mode elicitation, sampling with tools, Client ID Metadata Documents, and experimental core tasks. It selected JSON Schema 2020-12 as the default dialect when a schema does not declare another one.[30]

This was the final legacy, initialization-based revision. Its tasks, sessions, server-initiated requests, and several client features must not be described as current `2026-07-28` behavior.[5][7]

### `2026-07-28`

The project published `2026-07-28` as a stable, non-prerelease GitHub release on July 28, 2026.[4] The revision made the core stateless, removed `initialize` and protocol sessions, required per-request version and capability metadata, and added mandatory `server/discover`.[5]

It also replaced the HTTP GET stream and resource-specific subscribe methods with `subscriptions/listen`; replaced standalone server-to-client requests with multi-round-trip results; required `resultType` on successful results; removed SSE redelivery; moved Tasks into an extension; and added standard request headers and cache metadata. Roots, sampling, logging, Dynamic Client Registration, HTTP+SSE, and two sampling `includeContext` values entered or were formalized in the deprecated registry.[5][31]

Because some implementations need legacy compatibility, the revision specifies dual-era detection and fallback rules. Supporting the new revision does not require dropping `2025-11-25`, but a server must process modern and legacy exchanges according to the semantics of the selected revision rather than mixing them.[7][9][10]

## Governance and stewardship

The project uses Specification Enhancement Proposals, or SEPs, for substantial protocol and process changes. SEP-932 established roles that include contributors, maintainers, core maintainers, and lead maintainers. Membership belongs to individuals rather than their employers. Maintainers review proposals and implementations, while core and lead maintainers handle broader project direction and repository stewardship.[33][34]

Proposals, issue discussions, and released specifications serve different purposes. A proposal can document motivation and design discussion without becoming normative. The dated specification and release record determine what was released.

On December 9, 2025, [Anthropic](https://aiwiki.ai/wiki/anthropic) donated MCP to the Agentic AI Foundation, a directed fund of the [Linux Foundation](https://aiwiki.ai/wiki/linux_foundation). The foundation launched with MCP, Block's goose project, and OpenAI's AGENTS.md as founding contributions.[35][36] The donation supplied a neutral organizational home but did not replace the project's technical governance.

### Licensing

The repository is transitioning from MIT to Apache-2.0 rather than operating under one undifferentiated license. Its license file states that new code and specification contributions use Apache-2.0, while documentation contributions other than specifications use CC BY 4.0. Older contributions remain under MIT when their authors have not consented to relicensing.[37]

Because file histories differ, a downstream user should inspect the notices attached to the material it copies or redistributes. Calling the entire project simply "MIT licensed" omits the transition and the separate documentation license.

## Implementations and project tooling

The project maintains official software development kits, an interactive Inspector, and a public metadata registry. These tools aid implementation and discovery but do not certify that a server is secure or interoperable with every host.

### SDKs

On July 28, 2026, the official SDK page classified TypeScript, Python, C#, and Go as Tier 1; Java and Rust as Tier 2; and Swift, Ruby, PHP, and Kotlin as Tier 3.[38] The tiers reflect feature coverage, testing, maintenance, and release commitments and can change over time.

An SDK reduces protocol plumbing but does not validate the business logic behind a tool, select permissions, or guarantee compatibility with custom host behavior. Clients and servers can also implement the specification without an official SDK.

### Inspector

The MCP Inspector is an official interactive testing and debugging tool. It can connect to a server, inspect capabilities and protocol messages, browse resources and prompts, and invoke tools.[39] It is not a certification program, malware scanner, or substitute for automated conformance and security testing.

### Official MCP Registry

The Official MCP Registry entered public preview in September 2025. It stores standardized `server.json` metadata, verifies namespace ownership, and exposes an API for downstream marketplaces and aggregators. It describes public packages and remote endpoints but does not host the packages themselves.[40][41]

The registry authenticates reverse-domain namespaces through verified GitHub accounts or domain ownership. Its moderation policy provides limited curation and does not endorse a listed server or replace vulnerability scanning.[41][42] A registry entry is therefore evidence of published metadata and namespace control, not evidence that the server is safe.

### MCP Apps

MCP Apps became the first official MCP extension on January 26, 2026. A compatible tool can refer to a resource with a `ui://` URI, and a supporting host can render that resource in a sandboxed iframe. The embedded interface and host communicate with JSON-RPC over `postMessage`.[43][44]

Apps are optional. A host without the extension can still use an underlying tool when it provides an ordinary result. Iframe sandboxing limits some browser capabilities, but the host still needs content-security policy, permission controls, origin checks, and clear provenance.

## Adoption

Primary product records show implementations by several vendors, but they do not establish universal support or complete protocol conformance.

- Anthropic's November 2024 announcement included SDKs, reference servers, local server support in [Claude Desktop](https://aiwiki.ai/wiki/claude_desktop), and plans for broader Claude product support.[1]
- [GitHub Copilot](https://aiwiki.ai/wiki/github_copilot) in VS Code 1.99 added MCP server support to agent mode in April 2025.[45]
- [OpenAI](https://aiwiki.ai/wiki/openai) added remote MCP server support to the Responses API on May 21, 2025, after earlier support in its Agents SDK.[46]
- [Google](https://aiwiki.ai/wiki/google) Cloud announced managed remote MCP servers for selected Google services on December 11, 2025.[47]

These implementations differ in protocol revision, transport, authentication, feature coverage, user interface, and policy controls. The phrase "supports MCP" does not mean that two products expose identical behavior. Compatibility should be tested against the specific host, server, revision, transport, and authorization configuration.

Published totals for downloads, repositories, or servers can use incompatible definitions and change quickly. Package downloads do not equal active users, registry entries do not equal secure deployments, and source-code search results do not equal conforming implementations. This article therefore does not use an unsourced ecosystem total or call MCP a universal standard.

## Relationship to adjacent interfaces

### Function calling

[Function calling](https://aiwiki.ai/wiki/function_calling) is a model API feature through which an application supplies function schemas and receives structured arguments selected by a model. MCP defines discovery and invocation between a host-side client and an external server. A host can translate MCP tool definitions into the tool format accepted by its chosen model.[13][46]

Function calling alone does not specify how independently developed capability providers expose resources and prompts, how a client discovers a server's protocol revisions, or how a server obtains additional client input. MCP does not replace a model provider's tool API; it can provide capabilities that the host maps into that API.

### Language Server Protocol

The Language Server Protocol standardizes communication between code editors and language-intelligence servers. MCP follows a similar reuse pattern and also uses JSON-RPC, but its methods, data types, and trust boundaries differ.[49] An LSP server provides programming-language operations such as completion and diagnostics. An [MCP server](https://aiwiki.ai/wiki/mcp_server) can expose tools or context for many domains.

### OpenAPI

OpenAPI 3.2 defines a language-agnostic description format for HTTP APIs. MCP, by contrast, defines a runtime JSON-RPC exchange with server discovery, resources, prompts, tools, client input, and standard transports.[3][6][52] One system can use both interfaces, but adopting either specification does not by itself determine the application's authorization policy or the semantics of an underlying operation.[21][52]

### Agent2Agent Protocol

Google introduced the [Agent2Agent Protocol](https://aiwiki.ai/wiki/a2a_protocol) for communication and task coordination between independent agents. Its launch material presented A2A and MCP as complementary: MCP connects an application or agent to tools and context, while A2A addresses collaboration between agents acting as peers.[50] A system can use both protocols, one, or neither.

## Design limits and interoperability

MCP standardizes message exchange, not the full behavior of an AI system. Practical limits include:

- **Optional features:** A revision can define a feature that an endpoint does not advertise.
- **Version differences:** Modern, legacy, and draft documents can have materially different lifecycle and transport behavior.
- **Semantic differences:** Two tools with similar names can have different side effects, validation rules, and result quality.
- **Host policy:** Hosts can apply different approval, model-selection, logging, and content-handling rules.
- **Server trust:** A conforming server can still be malicious, compromised, overprivileged, or incorrect.
- **Model behavior:** A model can choose the wrong tool, supply invalid arguments, or misinterpret a correct result.
- **Transport constraints:** stdio, remote HTTP, and custom transports create different deployment and security requirements.
- **Authorization boundaries:** An OAuth grant controls access to a server but does not authorize arbitrary downstream token use.

Robust implementations therefore require both protocol conformance and system-level controls. Relevant measures include explicit server identity, least-privilege credentials, operation-specific authorization, schema validation, output provenance, timeouts, rate limits, cancellation, audit logs, package verification, network isolation, and human confirmation for high-impact actions.[23][24]

MCP's principal contribution is a shared, versioned interface at the application-to-capability boundary. It should not be treated as a model-safety mechanism, a package-trust system, or proof that all participating products interoperate without testing.

## See also

- [Agentic AI](https://aiwiki.ai/wiki/agentic_ai)
- [Artificial intelligence](https://aiwiki.ai/wiki/artificial_intelligence)
- [Foundation models](https://aiwiki.ai/wiki/foundation_models)
- [Human-in-the-loop](https://aiwiki.ai/wiki/human_in_the_loop)
- [Prompt injection](https://aiwiki.ai/wiki/prompt_injection)
- [Retrieval-augmented generation](https://aiwiki.ai/wiki/retrieval_augmented_generation)
- [Software development](https://aiwiki.ai/wiki/software_development)
- [Tool use](https://aiwiki.ai/wiki/tool_use)

## References

1. Anthropic. "Introducing the Model Context Protocol." November 25, 2024. https://www.anthropic.com/news/model-context-protocol
2. Model Context Protocol. "Model Context Protocol specification repository." GitHub. Accessed July 28, 2026. https://github.com/modelcontextprotocol/modelcontextprotocol
3. Model Context Protocol. "Architecture overview." Revision 2026-07-28. Accessed July 28, 2026. https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture
4. Model Context Protocol. "Release 2026-07-28." GitHub. July 28, 2026. https://github.com/modelcontextprotocol/modelcontextprotocol/releases/tag/2026-07-28
5. Model Context Protocol. "Key changes, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/changelog
6. Model Context Protocol. "Base protocol, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic
7. Model Context Protocol. "Versioning and compatibility, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning
8. Model Context Protocol. "Discovery, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/server/discover
9. Model Context Protocol. "stdio transport, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio
10. Model Context Protocol. "Streamable HTTP, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
11. Model Context Protocol. "Resources, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/server/resources
12. Model Context Protocol. "Prompts, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/server/prompts
13. Model Context Protocol. "Tools, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/server/tools
14. Model Context Protocol. "Caching, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching
15. Model Context Protocol. "Subscriptions, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions
16. Model Context Protocol. "Multi Round-Trip Requests, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr
17. Model Context Protocol. "Elicitation, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation
18. Model Context Protocol. "Roots, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/client/roots
19. Model Context Protocol. "Sampling, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/client/sampling
20. Model Context Protocol. "Tasks extension overview." Accessed July 28, 2026. https://modelcontextprotocol.io/extensions/tasks/overview
21. Model Context Protocol. "Authorization, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
22. Model Context Protocol. "Client registration, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration
23. Model Context Protocol. "Authorization security considerations, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
24. Model Context Protocol. "Security best practices." Accessed July 28, 2026. https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
25. Model Context Protocol. "Tool annotations: A shared vocabulary for managing tool risk." March 16, 2026. https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/
26. Hou et al. "Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions." ACM Transactions on Software Engineering and Methodology, online February 16, 2026. https://doi.org/10.1145/3796519
27. Model Context Protocol. "Specification 2024-11-05." November 5, 2024. https://modelcontextprotocol.io/specification/2024-11-05/index
28. Model Context Protocol. "Key changes, specification 2025-03-26." March 26, 2025. https://modelcontextprotocol.io/specification/2025-03-26/changelog
29. Model Context Protocol. "Key changes, specification 2025-06-18." June 18, 2025. https://modelcontextprotocol.io/specification/2025-06-18/changelog
30. Model Context Protocol. "Key changes, specification 2025-11-25." November 25, 2025. https://modelcontextprotocol.io/specification/2025-11-25/changelog
31. Model Context Protocol. "Deprecated features, specification 2026-07-28." July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/deprecated
32. Model Context Protocol. "Feature lifecycle and deprecation policy." Accessed July 28, 2026. https://modelcontextprotocol.io/community/feature-lifecycle
33. Model Context Protocol. "SEP-932: Model Context Protocol governance." September 17, 2025. https://modelcontextprotocol.io/seps/932-model-context-protocol-governance
34. Model Context Protocol. "Governance and stewardship." Accessed July 28, 2026. https://modelcontextprotocol.io/community/governance
35. Anthropic. "Donating the Model Context Protocol and establishing the Agentic AI Foundation." December 9, 2025. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
36. Linux Foundation. "Linux Foundation Announces the Formation of the Agentic AI Foundation." December 9, 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
37. Model Context Protocol. "License." GitHub. Accessed July 28, 2026. https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/main/LICENSE
38. Model Context Protocol. "SDKs." Revision 2026-07-28. Accessed July 28, 2026. https://modelcontextprotocol.io/docs/2026-07-28/sdk
39. Model Context Protocol. "MCP Inspector." Accessed July 28, 2026. https://modelcontextprotocol.io/docs/tools/inspector
40. Model Context Protocol. "Official MCP Registry enters preview." September 8, 2025. https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/
41. Model Context Protocol. "Official MCP Registry." Accessed July 28, 2026. https://modelcontextprotocol.io/registry/about
42. Model Context Protocol. "Official MCP Registry moderation policy." Accessed July 28, 2026. https://modelcontextprotocol.io/registry/moderation-policy
43. Model Context Protocol. "MCP Apps: Interactive user interfaces for MCP." January 26, 2026. https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/
44. Model Context Protocol. "MCP Apps extension overview." Accessed July 28, 2026. https://modelcontextprotocol.io/extensions/apps/overview
45. GitHub. "GitHub Copilot in VS Code March release v1.99." April 4, 2025. https://github.blog/changelog/2025-04-03-github-copilot-in-vs-code-march-release-v1-99/
46. OpenAI. "New tools and features in the Responses API." May 21, 2025. https://openai.com/index/new-tools-and-features-in-the-responses-api/
47. Google Cloud. "Announcing Model Context Protocol (MCP) support for Google services." December 11, 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services
48. JSON-RPC Working Group. "JSON-RPC 2.0 Specification." January 4, 2013. https://www.jsonrpc.org/specification
49. Microsoft. "Language Server Protocol." Accessed July 28, 2026. https://microsoft.github.io/language-server-protocol/
50. Google Developers Blog. "A2A: A new era of agent interoperability." April 9, 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
51. Microsoft. "Add and manage MCP servers in VS Code." Accessed July 28, 2026. https://code.visualstudio.com/docs/agent-customization/mcp-servers
52. OpenAPI Initiative. "OpenAPI Specification 3.2.0." September 19, 2025. https://spec.openapis.org/oas/latest.html