EN
Română (Romanian)
Last updated: September 23, 2026. This article follows the stable version 2026-07-28. Functions that are in draft or on the roadmap are presented separately.Model Context Protocol, abbreviated MCP, has rapidly become one of the main connection points between AI applications and external systems. Its role is practical: it provides a common contract through which an application based on language models can discover data, use tools, and execute workflows without every integration being built from scratch.
MCP is not an AI model, an agent, or a database. It does not replace APIs, authentication, RAG, or business logic. It standardizes the interface between the AI application and the servers that provide it with context and capabilities.
The official specification 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 comprising three roles:
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 transmit, applies access policies, and maintains security boundaries.
The analogy with a USB-C port for AI applications is helpful, but incomplete. MCP describes how components discover each other and communicate. It does not guarantee server quality, action correctness, or the overall system's safety.
At the core of the protocol, servers can provide three main primitives:
The client can also offer elicitation, a mechanism through which the server requests additional information or confirmations. In the current version, this interaction is handled through Multi Round-Trip Requests (MRTR): the server responds that it needs data, the client collects it from the user, and then resumes the initial request.
MCP defines two standard transports:
stdio, especially suited for local servers. The client launches the server as a subprocess, and JSON-RPC messages travel over standard input and output streams.Version 2026-07-28 is stateless at the protocol level. The initialize / initialized handshake and the Mcp-Session-Id header have been removed. Each request carries its own version and capabilities, and server/discover allows querying the versions and functions supported by the server.
This change simplifies traffic distribution and the horizontal scaling of remote servers.
A nuance is important: the old HTTP+SSE transport is deprecated, not the SSE technology as a whole. Streamable HTTP can still use SSE for responses and notifications.
Before a common protocol, every combination of an AI application and a data source required its own connector. A team wanting to connect an assistant to GitHub, a CMS, a document system, and an analytics platform had to design four different integrations and then repeat the work for each AI host.
Anthropic publicly released MCP on November 25, 2024, after the protocol had been 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 integration fragmentation between editors and programming language servers.
There is a difference between the public release date and the name of the first widely used version. The launch took place on November 25, 2024, but the protocol revision has the identifier 2024-11-05. MCP identifiers use the format YYYY-MM-DD and indicate a revision with breaking changes, not necessarily the day of the public announcement.
| Version | Main 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 | Authorization framework based on OAuth 2.1, Streamable HTTP, tool annotations, audio content, and JSON-RPC batching. |
| 2025-06-18 | Removal of batching, 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 function. Governance, working groups, and SDK levels were also formalized. |
| 2026-07-28 | Stateless core, removal of protocol handshake and sessions, server/discover, MRTR, header-based routing, cacheable results, official extensions, enhanced authorization, and a formal deprecation policy. |
There is also an archived revision 2024-10-07, prior to public release, but the official documentation does not provide a detailed changelog. For this reason, we don't attribute it specific features.
The timeline highlights a rapid evolution. In March 2025, JSON-RPC batching was introduced, and in June it was removed based on implementation feedback. Tasks appeared experimentally in the November 2025 core version and was later redesigned as an official extension in 2026.
Protocol versions should not be confused with SDK versions, which have their own release cycles and may adopt the specification at different rates.
The official changelogs for March 2025, June 2025, November 2025 and July 2026 document the normative changes.
In 2025, the project formalized its governance process and the SEP proposal mechanism, standing for Specification Enhancement Proposal.
On December 9, 2025, MCP became one of the founding projects of the Agentic AI Foundation, managed under the Linux Foundation, alongside goose and AGENTS.md.
The transfer provided the project with a neutral administrative framework. The Linux Foundation reported in December 2025 over 10,000 MCP servers published and adoption in products such as Claude, Cursor, Microsoft Copilot, Gemini, Visual Studio Code, and ChatGPT.
This figure reflects a snapshot in time, not a real-time updated value.
As of September 23, 2026, the current stable version is 2026-07-28. The most relevant changes are:
Mcp-Method and Mcp-Name allow gateways, WAFs, and traffic limiting systems to distinguish operations without parsing the JSON body.ttlMs and cacheScope.Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated in the current version. They may still function during the transition period, but documentation recommends new implementations not to adopt them.
Tasks is now the official io.modelcontextprotocol/tasks extension for long-running asynchronous operations. It provides durable identifiers, states such as working, input_required, completed, failed and cancelled, plus query, update, and cancellation operations.
In the current version, integration is defined for tools/call, not for arbitrary MCP methods.
MCP Apps lets tools deliver interactive interfaces like forms, charts, or dashboards, displayed in isolated containers within the host app. The interface does not override consent rules: calls initiated from the UI must remain inspectable and authorizable.
Official MCP registry facilitates discovery of public servers, but registry presence does not constitute a security audit. The namespace identity can be verified, but code, permissions, and server behavior must be evaluated separately.
The current documentation lists official SDKs by maturity level. 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 coverage, support, and maintenance, not the protocol version itself.
The roadmap published in August 2026 identifies upcoming priorities as agentic messaging primitives, hardening HTTP transport, agent identity and enterprise security, simplifying tool results, and improving SDK experience.
These are areas of ongoing work, not features to be assumed stable already.
An MCP server can connect an assistant to documentation, knowledge bases, internal catalogs, or databases. Resources offer 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, and MCP provides a standard interface for AI hosts to use it.
The official GitHub MCP server can expose code search, issues, pull requests, GitHub Actions executions, and security alerts.
In an IDE, the agent can combine repository context with tools for analysis, testing, and delivery. The protocol’s value is portable integration across compatible hosts, not bypassing GitHub permissions.
Figma uses MCP to relay information about components, variables, and layouts to agents. A well-controlled flow can reduce the gap between the design system and code, preserving real components and project conventions in context.
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 taking a public action. Separating draft and publish steps is essential for editorial control and auditability.
A tool can query data, then return a dashboard with filters, charts, and details via MCP Apps.
The user visually explores the results, and the host can forward relevant selections back to the model. This sort of interaction is better suited than long text exchanges for analysis, configuration, or review.
The Tasks extension is useful for code migration, running extended tests, research, large-scale data processing, or multi-step enterprise workflows.
The client can check status, provide additional information, and retrieve the result without keeping a single request open.
MCP servers can expose operations for cloud, DNS, deployment, monitoring, or security.
Cloudflare, for example, documents servers providing controlled access to services like Workers, R2, DNS, and Zero Trust. In these scenarios, read-only mode, restricted tools, and human confirmation for changes are basic requirements.
Stripe offers an MCP server for interacting with its API and documentation.
This case illustrates both the protocol’s utility and its limits: a standard interface does not justify automatically executing a payment. Financial operations require minimal permissions, parameter validation, and explicit confirmation.
MCP expands a model’s capacity to observe and act. At the same time, it also increases the attack surface.
The official security guide explicitly addresses risks like confused deputy, token passthrough, SSRF, state hijacking, and local server compromise.
Malicious instructions may exist in a document, a web page, an issue, or another tool’s output. Content read by the model must be treated as untrusted data.
OAuth controls who may access a resource but does not determine if an instruction found in that resource is legitimate.
A server may receive data from the host and return misleading information. Its behavior may change after installation.
That’s why the source, owner, version, and permissions must be continuously verified, not just at initial connection.
A local server is software running on the user’s computer. If not isolated, it may have access to files, network, or credentials.
Installing an MCP server should be treated as cautiously as installing any other software.
Tokens must be limited to the resource and audience for which they were issued. Token passthrough—retransmitting a token meant for another service—is forbidden.
Secure storage, short-lived tokens, issuer and audience validation, and strict network policies for OAuth discovery flows are required.
Tags like readOnly, destructive or idempotentthese are server statements, not cryptographic guarantees. The host should treat this metadata as untrusted if the server has not been verified.
stdio for controlled local processes and Streamable HTTP for remote services.MCP doesn't decide which model should be used, doesn't evaluate the truth of a response, and doesn't automatically turn a poorly designed API into an effective tool for agents.
It doesn't replace API management, identity control, input validation, observability, or human approval.
Compatibility is still inconsistent. Extensions are optional, hosts may implement different subsets, and some services accept only approved clients.
A very large catalog of tools can increase context cost and reduce selection accuracy. Progressive discovery and restricting available tools are important directions for mature implementations.
MCP solves a real interoperability problem: it gives AI applications a common language for discovering context, tools, and workflows.
The evolution from the 2024 launch to the stateless core of 2026 shows the shift from a promising experiment to infrastructure designed for production use.
The value of the protocol isn't in unlimited autonomy, but in controlled integration. A good MCP system combines a common technical contract with minimal permissions, explicit consent, auditing, isolation, and human verification for important actions.
If you are considering an MCP integration and want to clarify what data it can access, which tools should be exposed, and where human approval is required, contact us. We can help turn the idea into a realistic architecture with clear implementation steps, responsibilities, and security boundaries.