---
title: "MCP (Model Context Protocol): history, architecture, current status, and uses"
description: "A verified guide to the Model Context Protocol: how it works, version evolution, current status, security, and real-world use cases."
canonical: https://i8.ro/en/blog/mcp-model-context-protocol-history-architecture-current-status-and-uses
---

# MCP (Model Context Protocol): history, architecture, current status, and uses

> A verified guide to the Model Context Protocol: how it works, version evolution, current status, security, and real-world use cases.

Source: https://i8.ro/en/blog/mcp-model-context-protocol-history-architecture-current-status-and-uses

> **Last updated: September 23, 2026.** This article follows the stable version `2026-07-28`. Draft or roadmap features are presented separately.

The Model Context Protocol, or MCP, has quickly become one of the main bridges between AI applications and external systems. Its role is practical: it provides a common contract through which a language-model-based application can discover data, use tools, and execute workflows—without having to build each integration from scratch.

MCP is not an AI model, an agent, or a database. It does not replace APIs, authentication, RAG, or business logic. Instead, it standardizes the interface between the AI application and the servers that provide it with context and capabilities.

## MCP, in brief

[The official specification](https://modelcontextprotocol.io/specification/2026-07-28) defines MCP as an open protocol for integrating language-model-based applications with external data sources and tools. Communication uses JSON-RPC 2.0 and an architecture made up of three roles:

- **Host** is the AI application. It coordinates the model, user, authorization, consent, and context from multiple sources.
- **The MCP Client** is the connector managed by the host. Typically, each client communicates with a single server.
- **The MCP Server** exposes data and specialized functions. It can run locally as a process, or remotely as a service.

This separation is important. A server does not automatically receive the entire conversation or see data from other servers. The host decides what information to send, applies access policies, and maintains security boundaries.

The analogy to a USB-C port for AI applications is helpful, but incomplete. MCP describes how components discover and communicate with each other. It does not guarantee server quality, the correctness of actions, or the security of the whole system.

## What an MCP server exposes

At the protocol's core, servers may provide three main primitives:

1. **Resources**: data and context identified by URI, such as files, documents, database schemas, or application-specific information.
2. **Prompts**: reusable templates for messages and flows, defined by the server and generally selected by the user.
3. **Tools**: functions the model can discover and call, for example, for search, calculations, queries, updates, or API operations.

The client can also provide **elicitation**, a mechanism for the server to request additional information or confirmations. In the current version, this interaction is done through Multi Round-Trip Requests, or MRTR: the server responds that it needs data, the client collects it from the user, and then resumes the original request.

## How messages flow

MCP defines two standard transports:

- **`stdio`**, mainly suited for local servers. The client launches the server as a subprocess, and JSON-RPC messages travel through the standard input and output streams.
- **Streamable HTTP**, suited for remote services. Each message is sent as a POST request to a single endpoint, and the response can be either JSON or an SSE stream linked to that request.

The version `2026-07-28` is stateless at the protocol level. The handshake `initialize` / `initialized` and the header `Mcp-Session-Id` have been removed. Each request carries its own version and set of capabilities, while `server/discover` allows you to find out the versions and functions the server supports.

This change simplifies traffic distribution and horizontal scaling of remote servers.

A subtlety is important: the old HTTP+SSE transport is deprecated, not the SSE technology itself. Streamable HTTP can still use SSE for responses and notifications.

## Why MCP appeared

Before a common protocol, every combination of AI app and data source needed its own connector. A team wanting to link an assistant to GitHub, a CMS, a document system and an analytics platform had to design four separate integrations, then repeat the work for every AI host.

[Anthropic publicly launched MCP on November 25, 2024](https://www.anthropic.com/news/model-context-protocol), after the protocol was developed internally by David Soria Parra and Justin Spahr-Summers. The initial package included the specification, SDKs, support for local servers in Claude Desktop, and reference implementations.

The architecture was inspired by the Language Server Protocol, the standard that reduced the fragmentation between editors and programming language servers.

There's a difference between the public release date and the name of the first widely used version. The release took place on November 25, 2024, but the protocol revision carries the identifier `2024-11-05`. MCP identifiers use the format `AAAA-LL-ZZ` and indicate a revision with breaking changes, not necessarily the day of public announcement.

## MCP version history

| Version | Key changes |
| --- | --- |
| `2024-11-05` | Initial foundation: JSON-RPC 2.0, host-client-server architecture, stateful connections, capability negotiation, Resources, Prompts, Tools, and Sampling. |
| `2025-03-26` | OAuth 2.1-based authorization framework, Streamable HTTP, tool annotations, audio content, and JSON-RPC batching. |
| `2025-06-18` | Batching removed, structured results for tools, elicitation, resource links, servers treated as OAuth Resource Servers, Resource Indicators, and clearer security rules. |
| `2025-11-25` | OpenID Connect Discovery, incremental consent for scopes, URL elicitation, Client ID Metadata Documents, JSON Schema 2020-12, and Tasks as an experimental core feature. Governance, working groups, and SDK levels were also formalized. |
| `2026-07-28` | Stateless core, removal of handshake and protocol sessions, `server/discover`, MRTR, header-based routing, cacheable results, official extensions, tighter authorization, and a formal deprecation policy. |

There is also an archived revision `2024-10-07`, prior to the public release, but the official documentation doesn’t provide a detailed changelog. Therefore, we don’t attribute specific features to it.

The timeline highlights rapid evolution. In March 2025, JSON-RPC batching was introduced, and in June it was removed after implementation feedback. Tasks appeared experimentally in the November 2025 core version and was later redesigned in 2026 as an official extension.

Protocol versions shouldn’t be confused with SDK versions, which have their own release cycle and may adopt the specification at different rates.

Official changelogs for [March 2025](https://modelcontextprotocol.io/specification/2025-03-26/changelog), [June 2025](https://modelcontextprotocol.io/specification/2025-06-18/changelog), [November 2025](https://modelcontextprotocol.io/specification/2025-11-25/changelog) and [July 2026](https://modelcontextprotocol.io/specification/2026-07-28/changelog) document normative changes.

## From Anthropic project to open governance

In 2025, the project formalized its governance process and a proposal mechanism called SEP (Specification Enhancement Proposal).

On December 9, 2025, MCP became one of the founding projects of the Agentic AI Foundation, operated under the Linux Foundation, alongside goose and AGENTS.md.

The transfer gave the project a neutral administrative framework. [The Linux Foundation reported in December 2025](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation) over 10,000 published MCP servers and adoption in products such as Claude, Cursor, Microsoft Copilot, Gemini, Visual Studio Code, and ChatGPT.

The figure should be understood as a snapshot, not as a real-time updated value.

## Current status: what does state of the art mean in 2026

As of September 23, 2026, the current stable version is `2026-07-28`. The most significant changes are:

- **Stateless core**: each request is autonomous, reducing reliance on persistent sessions and affinity-based routing.
- **MRTR**: the server can request additional data or approvals without independently initiating a JSON-RPC request to the client.
- **HTTP-level routing and control**: the headers `Mcp-Method` and `Mcp-Name` allow gateways, WAFs, and traffic-limiting systems to distinguish operations without parsing the JSON body.
- **Cacheable results**: tool, prompt, and resource listings include information such as `ttlMs` and `cacheScope`.
- **Official extensions**: specialized functions can evolve independently of the core and are enabled only when both client and server declare support.
- **Observability**: conventions for OpenTelemetry trace context are standardized in request metadata.
- **Strengthened authorization**: issuer validation, issuer-bound credentials, and preference for Client ID Metadata Documents reduce known classes of OAuth attacks.
- **Predictable deprecation**: deprecated features generally benefit from a minimum 12-month transition period.

Roots, Sampling, Logging, and the old HTTP+SSE transport are deprecated in the current version. They may continue to work during the transition period, but documentation recommends that new implementations not adopt them.

### Extensions and ecosystem

Tasks is now the official extension `io.modelcontextprotocol/tasks` for long-running asynchronous operations. It provides durable identifiers, states such as `working`, `input_required`, `completed`, `failed` and `cancelled`, plus operations to query, update, and cancel.

In the current version, integration is defined for `tools/call`, not for any MCP method.

[MCP Apps](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/) allows tools to deliver interactive interfaces, such as forms, charts, or dashboards, displayed in isolated containers within the host application. The interface does not bypass consent rules: calls initiated from the UI must be inspectable and authorized.

[Official MCP Registry](https://registry.modelcontextprotocol.io/) facilitates the discovery of public servers, but presence in the registry does not constitute a security audit. The identity of the namespace can be verified, but the server’s code, permissions, and behavior must be evaluated separately.

The current documentation lists official SDKs by maturity levels. TypeScript, Python, C#, Go, and Rust are Tier 1; Java and Ruby are Tier 2; Swift, PHP, and Kotlin are Tier 3. These tiers describe the degree of coverage, support, and maintenance—not the protocol version itself.

The roadmap published in August 2026 highlights future priorities such as agent messaging primitives, strengthening HTTP transport, agent identity and enterprise security, simplifying tool outputs, and improving SDK experience.

These are work directions, not features that should be assumed stable.

## Use cases

### 1. Controlled access to an organization's knowledge

An MCP server can connect an assistant to documentation, knowledge bases, internal catalogs, or databases. Resources provide identifiable context, and tools can perform controlled searches or queries. Notion, Google Developer Knowledge, and Data Commons are official examples of such integrations.

MCP does not replace RAG. A retrieval system can remain responsible for indexing, ranking, and grounding, while MCP offers a standard interface through which AI hosts can use it.

### 2. Software development and operations

The official GitHub MCP server can expose code search, issues, pull requests, GitHub Actions executions, and security alerts.

In an IDE, the agent can bring together context from the repository with analysis, testing, and delivery tools. The value of the protocol lies in integration portability between compatible hosts, not in bypassing GitHub permissions.

### 3. Design connected to implementation

Figma uses MCP to deliver agents information about components, variables, and layout. A well-controlled workflow can reduce the gap between the design system and code, keeping real components and project conventions in context.

### 4. Editorial workflows and content management

An MCP server for a CMS can separate reading, drafting, updating, previewing, and publishing into distinct tools.

An agent can analyze existing content, prepare a draft, and request confirmation before any public action. The separation of draft and publication is essential for editorial control and audit.

### 5. Data analysis and interactive interfaces

A tool may query data, then return via MCP Apps a dashboard with filters, charts, and details.

The user visually explores the result, and the host can relay relevant selections back to the model. This kind of interaction is more suitable than a long text message exchange for analysis, configuration, or review.

### 6. Automations and long-running operations

The Tasks extension is useful for code migration, running extended tests, research, processing large data volumes, or multi-step enterprise workflows.

The client can check status, provide additional information, and retrieve results without keeping a single request open.

### 7. Infrastructure management

MCP servers can expose operations for cloud, DNS, deployment, monitoring, or security.

Cloudflare, for example, documents servers that provide controlled access to services like Workers, R2, DNS, and Zero Trust. In these scenarios, read-only mode, limiting available tools, and requiring human confirmation for changes are basic requirements.

### 8. Payments and financially impactful operations

Stripe offers an MCP server for interacting with its API and documentation.

This use case demonstrates both the protocol’s utility and its limits: a standard interface does not justify the automatic execution of a payment. Financial operations require minimum permissions, parameter validation, and explicit confirmation.

## Risks and limitations

MCP extends a model’s capacity to observe and act. At the same time, it expands the attack surface.

[Official security guide](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) explicitly addresses risks such as confused deputy, token passthrough, SSRF, state hijacking, and compromise of local servers.

### Prompt injection

Malicious instructions can appear in a document, on a web page, in an issue, or in another tool’s result. The content read by the model must be treated as untrusted data.

OAuth controls who can access a resource, but does not determine whether the instruction found in that resource is legitimate.

### Malicious or compromised servers

A server can receive data sent by the host and return deceptive information. Its behavior may change after installation.

Therefore, the source, owner, version, and permissions must be checked continuously, not just at the initial connection.

### Local execution

A local server is software running on the user's computer. If not isolated, it can access files, the network, or credentials.

Installing an MCP server should be approached with the same caution as installing any other program.

### Tokens and authorization

Tokens must be limited to the resource and audience for which they were issued. Token passthrough—that is, forwarding a token intended for another service—is forbidden.

Secure storage is required, along with short-lived tokens, issuer and audience validation, and restrictive network policies for OAuth discovery flows.

### Metadata and annotations

Tags such as `readOnly`, `destructive` or `idempotent` are server statements, not cryptographic guarantees. The host should treat these metadata as untrusted if the server has not been verified.

## A minimal ruleset for implementation

1. Start with a narrow and measurable use case.
2. Choose the right primitive: Resources for context, Prompts for templates, and Tools for actions.
3. For new implementations, target the current stable version and explicitly check host and SDK compatibility.
4. Use `stdio` for controlled local processes and Streamable HTTP for remote services.
5. Expose only the necessary tools and data, with minimal permissions.
6. Enable read-only mode by default where possible.
7. Require confirmation for writing, deleting, publishing, payments, and other external effects.
8. Isolate local servers and limit their access to files and the network.
9. Log calls, maintain traceability, and monitor server changes.
10. Test for prompt injection, authorization errors, invalid results, and service unavailability.

## What MCP doesn't solve

MCP doesn't decide which model to use, doesn't assess the truthfulness of a response, and doesn't automatically turn a poorly designed API into a good tool for agents.

It doesn't replace API management, identity control, input validation, observability, or human approval.

Compatibility is not yet uniform. Extensions are optional, hosts may implement different subsets, and some services only accept approved clients.

A very large tool catalog can increase context costs and reduce selection precision. Progressive discovery and limiting available tools are important directions for mature implementations.

## Conclusion

MCP solves a real interoperability problem: it gives AI applications a common language to discover context, tools, and workflows.

The evolution from the 2024 launch to the stateless core of 2026 marks the transition from a promising experiment to infrastructure designed for production use.

The value of the protocol is not in unlimited autonomy, but in controlled integration. A good MCP system combines a shared technical contract with minimal permissions, explicit consent, auditing, isolation, and human verification for important actions.

## Primary sources consulted

- [MCP Specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)
- [Changelog for version 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
- [Model Context Protocol Launch, Anthropic](https://www.anthropic.com/news/model-context-protocol)
- [Agentic AI Foundation, Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)
- [MCP Roadmap, August 2026](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)
- [Security Best Practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)
- [Official MCP SDKs](https://modelcontextprotocol.io/docs/2026-07-28/sdk)
- [MCP Apps](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/)
- [OpenAI Guide for MCP Servers](https://developers.openai.com/api/docs/mcp)
- [MCP Server GitHub](https://github.blog/ai-and-ml/generative-ai/a-practical-guide-on-how-to-use-the-github-mcp-server/)
- [MCP Server Figma](https://developers.figma.com/docs/figma-mcp-server/)
- [MCP Notion](https://developers.notion.com/guides/mcp/overview)
- [MCP Stripe](https://docs.stripe.com/mcp)
- [MCP Servers on Cloudflare](https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/)