Model Context Protocol (MCP)

If you want to understand why suddenly every piece of software, from the IDE to the shop system, is announcing "MCP support", it is worth taking a close look at what this protocol actually governs.

The basic idea can be summed up in a comparison that has caught on in the industry: MCP is the USB-C port for AI applications. Before MCP, every provider of an AI assistant had to build its own integration for every external system, and every system provider had to maintain its own interface for every AI assistant. With M models and N systems, that adds up to M times N integrations, any one of which can break. MCP replaces this tangle with a single, standardised interface: a system provides an MCP server once, and every MCP-capable AI tool can use it, whether it is called Claude, ChatGPT, Gemini or Microsoft Copilot.

How MCP works: architecture and building blocks

MCP is based on JSON-RPC 2.0, an established, lightweight message format, and defines three roles. The host is the AI application you work with, such as a chat interface or a development environment. The host embeds one or more clients, each of which maintains the connection to exactly one server. The server is the piece of software that connects an external system: a database, a CRM, a file system, a shop system. How the two sides align their capabilities was rebuilt by the 2026 specification: up to the 2025-11-25 revision, an initialize handshake opened a session in which the capabilities were negotiated once. Since the version of 28 July 2026 the protocol has been stateless: every request carries the protocol version and capabilities itself, and anyone who wants to know them in advance calls the server/discover method. For operations this means: MCP servers can be placed behind an ordinary load balancer without sharing session state between instances.

The architecture is explicitly modelled on the Language Server Protocol (LSP), with which Microsoft once standardised how code editors support programming languages. What LSP achieved for development tools, MCP is meant to achieve for AI applications: an ecosystem in which providers of tools and providers of applications can develop independently of each other because the interface between them is stable.

The three server primitives

An MCP server can offer its clients three kinds of capabilities:

• Tools are functions that the AI model can execute, from reading a record to creating an order. Tools are the heart of the protocol, because they turn a model that only generates text into a system that acts.
• Resources are context and data that the server provides, such as documents, database contents or configurations that the model or the user can view.
• Prompts are predefined templates and workflows that the server offers so that recurring tasks run consistently.

Conversely, the server may also need something from the client: a follow-up question to the user (elicitation) or its own request to the language model (sampling). This reverse direction is often overlooked but is decisive for agentic scenarios in which servers do not just passively deliver data but actively take part in the workflow. With the 2026-07-28 revision its mechanism has changed: servers no longer make their own requests to the client. Instead, a follow-up question runs via multi-round-trip requests: the server ends the tool call with a note that it needs input, the client obtains it and repeats the call together with the answer. Roots, sampling and the logging feature are on the deprecation list in the same revision; they may be dropped at the earliest with the first revision from 28 July 2027. As a migration path, the specification names: pass directories and files via tool parameters or resource URIs instead of roots, address the language model directly via the provider's API instead of via sampling, and use stderr (for stdio transports) or OpenTelemetry for logs.

For transport, the specification continues to define two routes: stdio for local servers running as a subprocess, and Streamable HTTP for remote servers. The older HTTP-plus-SSE transport has been deprecated since the 2025-03-26 revision; the register of deprecated features lists it with Streamable HTTP as the migration path. Beyond the core, the specification has had a formal extension system since the 2026-07-28 version: optional extensions such as Tasks (long-running jobs with polling instead of an open connection), MCP Apps (interactive interfaces directly in the conversation) or Enterprise Managed Authorization are opt-in: the client reports the extensions it supports in the capabilities of every request, the server in its response to server/discover. The current version of the specification is dated 2026-07-28 and is publicly available at modelcontextprotocol.io.

From an Anthropic project to an industry standard

The speed with which MCP became the de facto standard is remarkable even by AI standards. Anthropic presented the protocol on 25 November 2024. In spring 2025 OpenAI, Google DeepMind and Microsoft announced support, of all companies the initiator's direct competitors. At the end of 2025 the project reported more than 97 million monthly SDK downloads and more than 10,000 active MCP servers, with client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.

The governance step followed on 9 December 2025: Anthropic handed MCP over to the newly founded Agentic AI Foundation (AAIF), a fund under the umbrella of the Linux Foundation, co-founded by Anthropic, Block and OpenAI and supported by Google, Microsoft, AWS, Cloudflare and Bloomberg. For you as a decision-maker this is more than a footnote: a protocol owned by a single vendor is a risk; a protocol under neutral foundation governance is a basis for investment. It was exactly this handover that turned MCP from a clever Anthropic idea into infrastructure on which architectural decisions can be built.

MCP in e-commerce: the Shopware example

How concretely MCP is arriving in retail is shown by Shopware. At Shopware Community Day 2026 in Cologne, the company announced 100 per cent MCP coverage of the commerce core: every action in the platform, from creating products and pricing rules to maintaining stock, is accessible to AI tools and agents via the protocol. That is a different calibre from a built-in text generator. It means that any MCP-capable AI tool can operate your shop without a proprietary interface having to be built for it.

In practice this means: an agent can enrich product data, draft pricing rules or run analyses of orders, using the same standardised mechanisms with which another agent operates a CRM or a ticketing system. The value is not created in the protocol itself but in what it makes accessible. An MCP server in front of well-maintained product data is a tool; an MCP server in front of data chaos is an amplifier for the chaos. Anyone thinking about an MCP connection should therefore think about data quality first.

How the specification has evolved

If you use MCP in production, you should know the version history, because the protocol has moved noticeably since its launch. The first edition of 5 November 2024 laid the foundation with tools, resources and prompts. The revision of 26 March 2025 replaced the original HTTP-plus-SSE transport with Streamable HTTP and brought an OAuth-based authorisation framework. The version of 18 June 2025 added elicitation and structured tool output, among other things; the revision of 25 November 2025 sharpened authorisation and security guidelines. The biggest cut came with the current version of 28 July 2026: it replaces the session-based model with stateless individual requests, removes the initialize handshake and the session ID, moves Tasks out of the core into an extension of its own and deprecates Dynamic Client Registration in favour of Client ID Metadata Documents. If you have worked with session identifiers so far, this is where the biggest conversion effort lies. Since then every request names its protocol version, and the server accepts or rejects each one individually; for older, handshake-based counterparts the specification describes a compatibility path. Nevertheless: if you build your own server today, you should develop against the current specification and use the official SDKs. When the new version was released, the SDKs for TypeScript, Python, Go and C# already supported it, the Rust SDK as a beta.

Security: the open flank

MCP gives models access to real systems, and that is precisely where the risk lies. The specification itself names the principles: users must explicitly consent to data access and tool calls, hosts may not pass on data without consent, and tool descriptions from third-party servers are fundamentally regarded as untrustworthy. The last principle targets a real class of attack: prompt injection via manipulated tool descriptions, in which a malicious server slips instructions to the model.

The protocol cannot enforce these principles; that is the job of the implementation. In practice, for use in companies, this means: restrict permissions per tool properly, only integrate servers from trustworthy sources, route write actions through approval processes and log what agents actually do. Anyone who gives an agent write access to pricing rules without putting a review step in front of it does not have an MCP problem but a governance problem.

Distinction: MCP, function calling, UCP

Three terms are regularly mixed up in discussions. Function calling is the proprietary ability of an individual model to generate structured function calls; every provider implements it differently. MCP sits one level above this and standardises how such calls are transported, discovered and authorised across systems. The Universal Commerce Protocol (UCP), in turn, governs a different use case: not how an AI tool operates a system, but how an AI agent buys from a merchant, including catalogue access, basket and payment. The two protocols do not compete; they complement each other. Put simply, MCP makes your shop operable for AI tools and UCP makes it buyable for AI shoppers.

Also related, but not identical: agent-to-agent protocols such as Google's A2A, which govern communication between several agents. MCP remains the link between a model and the systems it works with.

What MCP means for your company

Whether you run an online shop, use custom software or want to automate internal processes, the question is no longer whether your systems will become accessible to AI, but by which route. MCP has become the safest bet here, for three reasons: it is openly licensed and managed vendor-neutrally, it is supported by all the major model providers at the same time, and it has built up an ecosystem of thousands of ready-made servers in record time.

Concretely, there are three fields of action. First, taking stock: which of your systems already come with MCP servers, which need one of their own? Ready-made servers often exist for widely used software; for in-house developments an MCP server is a manageable project, provided the underlying API is clean. Second, prioritisation: not every system has to become agent-capable; you should start where recurring, rule-based work meets a good data situation. Third, control: before the first production agent, define which actions may run automatically and which need human approval.

Frequently asked questions about the Model Context Protocol

Is MCP free to use?

Yes. MCP is an open standard with open-source SDKs for TypeScript, Python, Go, C# and Java, among others. Costs do not arise from the protocol but from using the AI models and running the servers.

Do I need MCP if my systems already have REST APIs?

A REST API describes how machines talk to your system, but that alone does not tell an AI model which actions it should call when. An MCP server translates your API into tools with descriptions that models understand and can use on their own. Often the MCP server is a thin layer over the existing API.

How safe is it to give an AI model system access via MCP?

As safe as you configure it. The protocol provides for consent requirements and capability limits, but granting permissions, choosing servers and approval processes are up to you. A proven approach is to allow read access generously and write access only with a review step.

Who controls the further development of MCP?

Since December 2025 the Agentic AI Foundation under the Linux Foundation, backed by Anthropic, OpenAI, Block and other companies such as Google, Microsoft and AWS. No single vendor can change the protocol on its own.

What does MCP have to do with agentic commerce?

MCP is one of its foundations. For AI agents to really work in retail, they have to be able to operate shop systems, inventory management and product data, and it is precisely this operability that MCP standardises. For the actual purchase by third-party agents, commerce protocols such as UCP come on top.