MCP: What Is the Model Context Protocol (2026)
MCP (Model Context Protocol) is an open protocol that standardizes how AI models connect to tools and data. Anthropic created it and open-sourced it in November 2024, then donated it on 9 December 2025 to the Agentic AI Foundation under the Linux Foundation. Every major client supports it. We explain what it changes for a company and where the protocol ends and your deployment work begins.
MCP (Model Context Protocol) is an open protocol that standardizes how AI models connect to tools and data. Anthropic created it and open-sourced it in November 2024, then donated it on 9 December 2025 to the Agentic AI Foundation under the Linux Foundation. Every major assistant supports it: Claude, ChatGPT, Gemini, Microsoft Copilot, Cursor, and VS Code.
What is MCP?
MCP is a shared language that an AI model uses to talk to your tools and data. Instead of teaching each assistant separately how to reach your CRM, inbox, or document store, you describe those tools once, on the MCP server side, and different assistants can use them. The easiest way to picture it is a "USB-C for AI integrations": one plug instead of a separate cable for every device.
Technically, MCP works in a client-server setup. The client (an assistant such as Claude or Copilot) connects to an MCP server that exposes tools (actions the model can take), resources (data it can read), and prompt templates. The server can sit next to your business system, and the model reaches it through a standardized interface. So the same integration you write once works across many assistants, not just one.
Who created MCP and who backs it now
MCP was created by Anthropic (the maker of the Claude models) and open-sourced in November 2024. It answers a recurring problem: every AI provider had its own way of connecting tools, so integrations had to be rewritten for each one.
The next step matters more from a buyer's point of view. On 9 December 2025 the protocol was donated to the Agentic AI Foundation (AAIF), a directed fund operating under the Linux Foundation, co-founded by Anthropic, Block (maker of the goose tool), and OpenAI (author of the AGENTS.md convention). Platinum founding members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI (source: Linux Foundation, December 2025). Today MCP is supported by every major AI client: Claude and Claude Code, ChatGPT, Gemini, Microsoft Copilot, Cursor, and VS Code.
It is a rare situation where competing providers stand behind a single standard. For a company, that means MCP is not tied to one vendor and its business decisions, which we return to below.
Function calling vs MCP: what is different
Start one layer down, because this is where most of the confusion lives. Function calling is a mechanism inside one provider: the model gets a description of the available functions, and when it decides one is needed, it returns a structured request ("call check_order_status with this number"), which your code executes and hands back. It works very well, but the format is tied to that provider's API. Switch providers, rewrite the integration.
MCP sits one layer up. It standardizes how those tools are described and exposed, so the same server works across different providers. Function calling stays the mechanism the model uses to reach a tool; MCP is the shared wrapper that keeps that tool from being locked into one ecosystem. The table below sorts out the three levels this plays out on.
| Level | What it standardizes | When it is enough | Where the boundary is |
|---|---|---|---|
| A plain conversation with a model | Nothing beyond text: the model answers from what it knows and what you paste in. | Questions, summaries, drafts, brainstorming. No access to your systems. | The model cannot take an action or reach current company data. |
| Function calling in one provider | The format in which one model asks for a function and gets a result back. | Connecting tools to one chosen provider you do not plan to change. | Ties the integration to that provider's API; moving to another means a rewrite. |
| MCP (across providers) | How tools and data are described and exposed, independent of the provider. | When you want one integration to work across many assistants and survive a provider change. | Standardizes the plug, not the boundaries, access, or trail: that stays on your side. |
What MCP changes for a company
In short: you write the integration once, and it works across many assistants. That has three concrete consequences worth counting before you decide.
Less integration work. You build an MCP server to your CRM or document system once, and Claude, Copilot, and Cursor all use it. You do not maintain a separate integration for each provider and each change to its API.
Less vendor lock-in. With a shared standard, switching from one model to another does not mean building the integration from scratch. That is real negotiating leverage and a hedge in case a provider changes its pricing or terms.
An answer to the procurement question "what if the vendor pivots or disappears." The old answer was "we rewrite the integration." Now the standard is stewarded by a foundation under the Linux Foundation, not a single company, so its governance does not hang on one vendor's decisions. That is not a guarantee, but it changes the risk conversation.
It is also worth knowing where the standard is heading. A new spec revision is announced for 28 July 2026 (the release candidate was locked on 21 May 2026). It is set to introduce a stateless core, extensions, OAuth-aligned authorization, and a formal deprecation policy. As of today it is an upcoming release, not a shipped production version, so when planning a deployment, treat it as direction rather than something you already rely on.
What MCP is NOT
Confusion builds up around every loud acronym, so let us cut the four most common mix-ups before they enter the budget conversation.
- MCP is not a model. It does not replace Claude, GPT, or Gemini. It is how a model connects to tools, not the intelligence that does the work.
- MCP is not an agent. The protocol alone does not run anything from ticket to result, does not judge, and does not escalate. An agent still has to be designed and built; MCP is one of the layers it uses.
- MCP is not a product with a price list. You do not buy "MCP." You buy or build a deployment that uses the standard: an integration, an agent, or an app.
- MCP is not a compliance stamp. The fact that something "supports MCP" says nothing about your boundaries, GDPR, or security. A communication standard is not a certificate.
The boundary: the protocol standardizes the plug, not the safety
Here is the most important sentence in this piece: MCP standardizes the plug, not the safety. The protocol sets how a model talks to a tool. It does not decide for you what that tool is allowed to do, who can access it, or how you check afterwards what happened. Boundaries, access, an audit trail, and escalation are still your deployment work, exactly the work we take on.
There is a concrete risk here. An MCP server with broad permissions is exactly the attack surface we describe under prompt injection: if the model processes content from outside (an email, a document, a web page), crafted instructions can trick it into using a connected tool in an unintended way, for example to send data or change a record. The broader the permissions, the greater the damage from a single successful attack. How this works and how to defend against it, we break down in the piece on prompt injection in AI agents.
The spec revision announced for 28 July 2026 tidies up authorization (OAuth-aligned), which helps but does not remove the responsibility. You are the one who decides that a server holds only the permissions it truly needs, that sensitive actions require human approval, and that every decision leaves a trail you can check. The protocol gives you a shared plug; you install the safety catch yourself.
FAQ
What is MCP? MCP (Model Context Protocol) is an open protocol that standardizes how AI models and assistants connect to external tools, systems, and data. Instead of writing a separate integration for each provider, you build one MCP server and different assistants understand it. Anthropic created it and open-sourced it in November 2024. It is sometimes called the "USB-C for AI integrations" because it acts as a shared plug (source: Anthropic, Linux Foundation, 2026).
Who created the Model Context Protocol and who backs it? MCP was created by Anthropic and open-sourced in November 2024. On 9 December 2025 the protocol was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI. Platinum founding members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Every major AI client supports MCP: Claude, ChatGPT, Gemini, Microsoft Copilot, Cursor, and VS Code (source: Linux Foundation, 2026).
How is function calling different from MCP? Function calling is a mechanism inside one provider: the model recognizes it should call a function and returns a structured request that your code executes. It works well but ties you to that provider's API. MCP sits one layer up: it standardizes how those tools are described and exposed so the same server works across providers. In short, function calling is the engine inside one provider, MCP is the shared cross-provider standard.
Is MCP secure? MCP standardizes the plug, not the safety. The protocol does not set your boundaries, access, or audit trail for you, that is still your deployment work. An MCP server with broad permissions is exactly the attack surface we describe under prompt injection: a model can be tricked into using a tool in an unintended way. The new spec revision announced for 28 July 2026 tidies up authorization (OAuth-aligned), but responsibility for access and escalation stays on the deployment side.
Is MCP a product you buy? No. MCP is not a model, not an agent, and not a product with a price list, nor a compliance stamp. It is an open standard, a way to connect models to tools. You buy or build a deployment that uses the standard: an integration, an agent, or an app, with boundaries, access control, and an audit trail on your side.
How to start
The cheapest sensible first step is to name the process, not to buy "MCP."
- Name the tools and data the model would reach: CRM, inbox, documents, ERP. List which actions it should only read and which it should perform.
- Set boundaries and access: what the system may do on its own, what requires human approval, and how you will know afterwards what happened.
- Decide who builds it: whether your team should build integrations carefully in-house, or you want a finished deployment with maintenance.
Where you go next depends on who builds it. If you want your team to design integrations and agents with boundaries themselves, that is what the AI-Native Course teaches: to build safely, not just plug servers in. If you would rather someone design and maintain the integration in production, that is the job of AI apps. Either way, start with a conversation about one specific process.
Book a free process scan | AI-Native Course | AI apps