Model Context Protocol (MCP) Explained for Business Teams

Every AI assistant eventually needs to do something: read a ticket, query a database, create a calendar event. Until recently each of those connections was a bespoke integration, rebuilt for every assistant and every tool. The Model Context Protocol, or MCP, is the attempt to standardize that layer, and in 2026 it has become the default answer to the question 'how do we connect AI to our systems?'

What MCP is, in plain terms

MCP defines how an AI application (the client) discovers and calls capabilities exposed by a server. A server can offer three kinds of things: tools the model can call, such as 'create invoice' or 'search tickets'; resources it can read, such as documents or records; and reusable prompts. The client learns what is available at run time, so adding a new capability means adding a server, not rewriting the assistant.

The analogy people reach for is USB-C: one connector, many devices. It is imperfect, because unlike a cable an MCP server can act on your systems, which is why the security section below matters. What the analogy gets right is the economics. Before, N assistants and M tools meant N times M integrations. With a shared protocol it is N plus M.

How it got here: from one vendor's idea to Linux Foundation project

• November 2024: Anthropic releases MCP as an open standard.
• Through 2025: OpenAI, Google and Microsoft add support in their products, and thousands of community servers appear.
• December 9, 2025: MCP is contributed to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, alongside Block's goose agent framework and OpenAI's AGENTS.md convention. Google, Microsoft, AWS, Cloudflare and Bloomberg back the foundation.
• 2026: The foundation launches a vendor-neutral MCP Associate (MCPA) certification, and the specification receives a major update.

The MCP project's own announcement cites more than 10,000 active servers and over 97 million monthly SDK downloads, with first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. Vendor-neutral governance is the main reason enterprises are comfortable standardizing on it: it lowers the risk of building on a protocol that one company could change or abandon. Details are in the MCP project's announcement.

What changed in the 2026 specification

Industry coverage of the release under the foundation's stewardship describes four changes that matter to teams deploying MCP in production. Check the official specification for exact wording and version numbers before you build against them.

• A stateless architecture, which makes servers easier to scale and to run behind ordinary load balancers.
• Hardened authentication, closing off a known class of attacks in the earlier OAuth-based flow.
• A formal 12-month deprecation policy, so integrations are not broken without warning.
• Two capabilities promoted to official extensions: interactive, server-rendered interfaces and long-running asynchronous tasks.

The async tasks extension is the one to watch for automation. Real business processes, such as generating a report or waiting on an approval, do not finish in a single request, and a standard way to start work and check back later is a prerequisite for agents that run unattended.

MCP is now showing up in the software you already own

The clearest sign of maturity is that enterprise software vendors are shipping MCP servers as a product feature. At Dreamforce 2026, Salesforce announced 'Headless 360', which event coverage describes as exposing more than 60 MCP tools across its clouds, and 'Claudeforce', a prebuilt MCP server that brings Salesforce into Claude. The strategic point, discussed in our analysis of the Salesforce and Microsoft announcements, is that the conversation window is becoming a front end for business software.

Where MCP fits in an automation project

Security: treat every server as a permission boundary

An MCP server gives a model hands. That makes it a security control point and a target. The OWASP Top 10 for Agentic Applications lists tool misuse, identity and privilege abuse and supply-chain risks that apply directly. A workable baseline:

1. 01Least privilege. Give each server the narrowest OAuth scopes and separate read tools from write tools.
2. 02Allow-list servers. Review third-party servers like any software dependency: who maintains it, what does it access, how is it updated.
3. 03Human approval for writes. Anything that sends, pays, deletes or publishes waits for a person until logs show it behaves.
4. 04Assume tool output is untrusted. Text returned by a tool can contain instructions aimed at the model. Do not let it change permissions or goals.
5. 05Log every call with the user, the agent, the tool, the arguments and the result, and review them.

How to start

Pick one internal system with a clear owner, expose two or three read-only tools through an MCP server and connect them to an assistant your team already uses. Watch how people use it for two weeks, then add a write action behind approval. This is the same incremental pattern we recommend in the 90-day roadmap, and if you need a custom MCP server for an internal system, that is squarely backend and API work. The wider picture is in our AI automation guide.

Sources and further reading

• MCP joins the Agentic AI Foundation, Model Context Protocol blog
• Model Context Protocol documentation
• Agentic AI Foundation
• OWASP GenAI Security Project