What Is MCP (Model Context Protocol)
Model Context Protocol (MCP) is an open standard that lets AI applications such as Claude, ChatGPT, Gemini, Cursor and VS Code connect to external data and tools through one common interface. Anthropic released it on November 25, 2024, and within eighteen months it became the industry's de facto standard for AI agents.
The easiest way to think about MCP is as a USB-C port for AI. A service implements an MCP server once, and every compatible AI assistant can work with it right away. This article covers how the protocol works, what changed in the current specification released on July 28, 2026, and what MCP means for business.
The problem MCP solves
MCP replaces "one integration per pair" with a single shared protocol. Before it, every AI application needed its own connector to every service: a chatbot to the CRM, an IDE to GitHub, an agent to a database. With N applications and M services, that is N × M separate integrations to build and maintain.
Anthropic's announcement framed it this way: even the most capable models are cut off from data locked in silos and legacy systems, and every new data source needs a custom implementation. With MCP the math becomes N + M: each application implements an MCP client once, and each service implements an MCP server once.
The specification names its inspiration directly: the Language Server Protocol (LSP). LSP let any code editor support any programming language. MCP does the same for AI applications and external tools.
How MCP became an industry standard
In one year MCP went from a single company's project to a neutral standard hosted by the Linux Foundation. It was created at Anthropic by David Soria Parra and Justin Spahr-Summers. The specification is versioned by release date, and the current revision as of October 2026 is 2026-07-28.
| Date | Event | What changed |
|---|---|---|
| Jul 28, 2026 | Specification 2026-07-28 | The protocol became stateless: the initialize handshake and sessions were removed, Tasks moved into an extension, Roots, Sampling and Logging were deprecated |
| Dec 9, 2025 | MCP joins the Agentic AI Foundation | Anthropic donated the protocol to a Linux Foundation fund co-founded with Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg |
| Nov 25, 2025 | Specification 2025-11-25 | Experimental Tasks for long-running operations, tool calling in sampling, icons, formal project governance |
| Jun 18, 2025 | Specification 2025-06-18 | Structured tool output, elicitation (asking the user for input), MCP servers classified as OAuth resource servers |
| Mar 2025 | OpenAI adopts MCP | Support in the Agents SDK, then in ChatGPT and the Responses API. Microsoft had already added MCP to Copilot Studio |
| Mar 26, 2025 | Specification 2025-03-26 | OAuth 2.1 authorization, Streamable HTTP transport replacing HTTP+SSE, tool annotations |
| Nov 25, 2024 | Anthropic announcement | First specification, SDKs, support in Claude Desktop, reference servers for Google Drive, Slack, GitHub and Postgres |
By the time of the Linux Foundation handoff, MCP had more than 97 million monthly SDK downloads and around 10,000 active servers, with first-class support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. The project's maintainers still set its technical direction, while the foundation provides a neutral home and infrastructure.
Architecture: host, client and server
MCP has three roles, and the most important one is the host: it holds the conversation with the model and decides what goes where.
- The host is the AI application a person works in: Claude, ChatGPT, an IDE. It creates clients, manages permissions, asks the user for consent and assembles context for the model.
- The client is a connector inside the host. Each client talks to exactly one server and keeps a security boundary between servers.
- The server is the service that exposes data and actions: a file system, a database, a CRM, a PIM. It can be a local process on the user's machine or a remote cloud service.
One principle sits at the core of the design: a server cannot read the whole conversation and cannot see other servers. The full history stays with the host, and each server receives only what a given request needs. That keeps servers simple to build and easy to combine.
The host keeps the model and the conversation, and each server receives through its own client only the requests addressed to it.
Message format and transports
All messages use JSON-RPC 2.0 encoded in UTF-8. The standard defines two transports:
- Stdio: the client launches the server as a subprocess and exchanges JSON strings via standard input and output streams. Suitable for files, Git, and local databases.
- Streamable HTTP: each message is sent via an HTTP POST request to a single address, and the response is received as a JSON object or an SSE stream. Used for remote cloud servers and SaaS services.
What "stateless" means in 2026-07-28
Until July 2026 a connection started with an initialize handshake, after which the server kept a session. The 2026-07-28 revision removed both. Every request now carries its own protocol version and client capabilities in the _meta field, and servers describe themselves through a new server/discover method.
For businesses the impact is mostly operational. An MCP server now scales like any ordinary web service: requests can go to any instance behind a load balancer, with no sticky sessions. For backward compatibility, clients and servers detect when the other side speaks an older revision and fall back to the previous scheme.
What MCP can carry
An MCP server exposes three kinds of things, and the difference between them is who decides to use them: the model, the application or the user.
| Primitive | Controlled by | What it is | Example |
|---|---|---|---|
| Tools | The model | Functions the model calls to act or fetch data. Each has a name, a description and a JSON Schema for its arguments | "Create product", "search Jira issues", "send email" |
| Resources | The application | Context data addressed by URI that the client loads itself | File contents, Git history, a product record |
| Prompts | The user | Ready-made request templates and workflows the person picks | A "/audit product page" slash command |
In practice tools matter most: they are what turns a chatbot into an agent that acts in your systems. Since 2025-06-18 a tool can return structured data that follows a schema, not just text, and annotations tell the client whether a tool only reads or can delete something.
Client-side features
Sometimes a server needs to ask the client for something mid-task. The current specification keeps one main mechanism for that.
- Elicitation. The server asks the host to show a form or open a link, for example to confirm a product category or approve an action.
- Sampling (asking the client's model) and Roots (file system boundaries) are deprecated in 2026-07-28. Instead of sampling, the specification suggests that servers call the model provider's API directly; instead of roots, paths are passed as tool parameters. The minimum deprecation window is 12 months.
Servers used to send these requests to the client on their own initiative. Now the Multi Round-Trip Requests pattern applies: the server replies "input required" (input_required), the client collects the answer from the user and retries the original request with it. The server does not have to keep state between calls.
Extensions
On top of the core there are official opt-in extensions that client and server enable by agreement:
- Tasks: long-running asynchronous operations with status polling, such as importing or exporting a large catalog.
- MCP Apps: interactive UI (charts, forms, video players) rendered right in the conversation.
- Skills over MCP: structured instructions for agents, distributed through MCP.
How it works in practice
Take a simple example. A content manager types to an assistant: "Find products in the Dresses category with no description." The assistant is connected to a PIM system's MCP server.
- Discovery. The client asks the server for its list of tools (tools/list) and passes their descriptions to the model.
- Selection. The model reads the descriptions and decides it needs the product search tool with a filter.
- Confirmation. The host shows the user which tool will be called and with which arguments. The specification recommends always keeping a human able to reject a call.
- Call. The client sends tools/call; the server queries its database and returns the result.
- Answer. The model reads the result and replies, or calls the next tool if needed, for example to draft descriptions.
This is what a tool description looks like in a tools/list response (shortened):
{
"name": "find_products",
"title": "Find products",
"description": "Searches the catalog by category and attribute completeness",
"inputSchema": {
"type": "object",
"properties": {
"category": { "type": "string" },
"empty_attribute": { "type": "string" }
},
"required": ["category"]
},
"annotations": { "readOnlyHint": true }
}
And here are the call and the response. Since 2026-07-28 the _meta field with the protocol version is required:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "find_products",
"arguments": { "category": "Dresses", "empty_attribute": "Description" },
"_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" }
}
}
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"resultType": "complete",
"content": [{ "type": "text", "text": "Found 14 products with no description" }],
"isError": false
}
}
If an argument is wrong, the server returns a result with isError: true and a clear error message. The model reads it and corrects the call on its own. Since there are no sessions anymore, state across calls (a cart, a transaction, an import job) travels as an explicit ID in the arguments.
Security and authorization
MCP gives a model access to real data and real actions, so security is the foundation, not an add-on. The specification openly states that the protocol itself cannot enforce its security principles; responsibility sits with the people building hosts and servers.
Three core principles
- User consent and control. People explicitly authorize data access and understand which actions will run.
- Data privacy. The host does not pass user data to servers or third parties without consent.
- Tool safety. A tool effectively means running arbitrary code. Tool descriptions and annotations count as untrusted unless the server is trusted.
Authorization
Remote MCP servers use OAuth 2.1 (since 2025-03-26). The server acts as a resource server, and the client gets a token from an authorization server. A server must not accept tokens that were not issued for it, and must not pass them through blindly. The recommended permission model is progressive: start with minimal read scopes and elevate only when a privileged action is first attempted.
Key risks
| Risk | What happens | Mitigation |
|---|---|---|
| Tool poisoning | Hidden instructions for the model sit in a tool description the user never sees | Connect only vetted servers, show descriptions and arguments in full |
| Rug pull | A server changes a tool description after the user approved it | Pin versions and hashes of tool descriptions |
| Shadowing | A malicious server changes how the agent behaves with another, trusted server | Isolate servers and control data flows between them |
| Prompt injection via data | Instructions arrive inside a tool result: an email, a ticket, a web page | Treat everything retrieved as data, not commands; confirm sensitive actions |
| Token passthrough, confused deputy | A proxy server forwards someone else's tokens or skips the consent step | Validate token audience, require per-client consent |
| Local server compromise | A local server runs with the user's privileges and may hide a malicious command | Show the full launch command, run servers in a sandbox |
Researchers at Invariant Labs coined the terms tool poisoning, rug pull and shadowing in April 2025. They showed how an innocent "add two numbers" tool could make an agent leak SSH keys and a config file holding credentials for other services. The practical takeaway for a company is simple: evaluate a third-party MCP server the way you would any dependency with access to corporate data.
Ecosystem
Every major AI platform supports MCP, and the number of active servers is above 10,000.
Clients (hosts). Claude (web, desktop, Claude Code), ChatGPT, Gemini, Microsoft Copilot, Cursor and Visual Studio Code. In consumer products, remote MCP servers usually appear as "connectors" or "apps".
Server registry. Since September 8, 2025 the official MCP Registry has served as an open catalog and API for public servers. Client marketplaces and private enterprise registries can pull from it and extend it.
SDKs. Official libraries for building servers and clients are grouped into tiers by how completely they support the protocol. Tier 1 includes TypeScript, Python, C#, Go, Rust, and Ruby. Next comes Java, while Tier 3 includes Swift, PHP, and Kotlin.
The growth shows in the numbers: by December 2025 the SDKs passed 97 million monthly downloads, with around 10,000 active servers.
MCP vs API vs function calling vs A2A
MCP does not replace APIs or compete with function calling; it sits on top of them. Most MCP servers simply call a service's REST API under the hood, and the model reaches the server through function calling.
| Approach | What it connects | Standardization | Who it's for |
|---|---|---|---|
| REST API | A program to a service | Every service has its own endpoints and auth | A developer hand-writing an integration |
| Function calling | A model to one application's functions | Each model provider has its own function format | The developer of a single AI app |
| MCP | Any AI app to any service (agent to tools) | One open protocol: discovery, calls, authorization | A service owner who wants to be available in every AI assistant |
| A2A (Agent2Agent) | An agent to another agent | Open protocol for delegating tasks between agents across companies | Multi-agent systems |
A2A is often confused with MCP, but they solve different problems. The official A2A documentation calls MCP a "vertical" protocol that deepens a single agent, and A2A a "horizontal" one that connects agents to each other. Real systems use both: agents coordinate over A2A, and each one uses its own tools through MCP. Google created A2A in April 2025, and in August 2026 the protocol joined the same Agentic AI Foundation as MCP.
What MCP means for business and e-commerce
For business, MCP changes one thing: work inside company systems becomes available from a conversation with an AI assistant. An employee describes the task in plain language, and the agent calls the right tools in the CRM, PIM, ERP or task tracker.
Why it matters to software vendors
- One integration instead of ten. A product with an MCP server works in Claude, ChatGPT, Copilot and IDEs at once, without a separate plugin for each platform.
- A new acquisition channel. Connector directories inside AI assistants and the MCP Registry are becoming a storefront where customers look for B2B tools.
- Access control. The agent works through OAuth with a specific user's permissions instead of a shared API key.
Product content scenarios
For PIM systems and teams preparing product listings for marketplaces and online stores, MCP enables scenarios like these:
| Task | What the employee says | What the agent does via MCP |
|---|---|---|
| Catalog audit | "Which Ready products have no main image?" | Filters products by status and attribute completeness, returns the list |
| Enrichment | "Write descriptions for the new dress collection" | Reads the attributes, drafts text, writes it to the attribute after approval |
| Information model setup | "Create an attribute group for the Laptops category" | Creates attributes and groups, links them to the category |
| Syndication readiness | "Why were some products rejected by the marketplace?" | Compares attribute values with the channel's allowed values and finds mismatches |
| Media | "Attach the new photos to these SKUs" | Uploads files to the right media attribute of each product |
One important caveat: how well an agent performs depends on how well its tools are designed. Clear names, precise descriptions, strict argument schemas and readable error messages matter more than the number of tools. Destructive operations (deletion, bulk writes) should carry annotations and always go through human approval.
The MARKETPROVIDER MCP server: an AI agent inside your PIM
MARKETPROVIDER PIM now has its own MCP server. An AI assistant such as Claude can work with your catalog directly: create products, configure information models and prepare content for every sales channel, from a task described in plain language.
What the agent can do
| Area | What the agent does via MCP |
|---|---|
| Information model | Creates and edits attributes and attribute groups, links groups to categories, works with value dictionaries |
| Products | Creates product records and fills in attributes, including from a supplier spreadsheet, a photo of a label or a marketplace listing |
| Search and QA | Finds products by category, status and attribute completeness, checks records before syndication |
| Media | Uploads images and files to the right media attributes |
| Tags and statuses | Tags products and moves them through workflow stages |
| Channels | Configures attribute mappings and transformation operations for marketplaces and online stores, runs the channel and reads the result |
What it looks like
- "Add these 50 products from the supplier spreadsheet to the Sneakers category." The agent parses the file, maps columns to the information model's attributes and creates the records.
- "Create a Technical Specifications attribute group for the Laptops category." The agent creates attributes of the right types and links the group to the category.
- "Which Ready products have no main image?" The agent finds them and, after confirmation, tags them for enrichment.
- "Prepare the feed for our marketplace channel." The agent maps PIM attributes to the channel template and sets up operations: unit conversion, value mapping to the marketplace's allowed values, macros.
Security
The agent acts on behalf of a specific user and within that user's role. If the role has no access to an attribute group or a catalog, the agent will not see it either. Every change is recorded in the product version history, so any action the agent takes can be reviewed and rolled back.
How to connect
The MARKETPROVIDER MCP server uses the standard Streamable HTTP transport and connects to an AI assistant as a custom connector. Once connected, the assistant gets the list of PIM tools and works with the catalogs the user has access to. To see the scenarios on your own data, book a demo.
Key takeaways
- MCP is an open protocol that connects AI applications to data and tools under one set of rules, turning N × M integrations into N + M.
- The architecture is simple: a host with the model, clients inside it, and servers exposing tools, resources and prompts over JSON-RPC.
- The current 2026-07-28 specification made the protocol stateless, so MCP servers now scale like ordinary web services.
- The protocol is governed by a neutral Linux Foundation fund and backed by Anthropic, OpenAI, Google, Microsoft and AWS, which makes it a low-risk bet.
- Security is the main condition for success: vetted servers, least privilege, and a human approving important actions.