What Is MCP? The Model Context Protocol Explained for Business and Technical Leaders

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools and data through one common interface. Instead of writing a custom integration every time you want an assistant like Claude, ChatGPT or Copilot to read your CRM or query your database, you (or a vendor) build one MCP server for that system, and any MCP-compatible AI app can use it. Anthropic open-sourced MCP in November 2024, and in December 2025 donated it to the Agentic AI Foundation under the Linux Foundation. The current specification revision is 2026-07-28.

This guide explains what MCP is in plain terms, how the pieces fit together, who has actually adopted it, how it relates to function calling and Google's A2A protocol, the security issues you need to plan for, and when it makes sense for a business to build an MCP server for its own internal systems.

What is MCP, and who created it?

MCP was created at Anthropic by David Soria Parra and Justin Spahr-Summers and announced on November 25, 2024. Anthropic's launch post described it as "a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol." Early adopters named at launch included Block and Apollo, plus developer-tool companies Zed, Replit, Codeium and Sourcegraph, and Anthropic shipped pre-built servers for systems like Google Drive, Slack, GitHub, Git and Postgres (Anthropic).

The problem it solves is simple to describe. Before MCP, every pairing of AI app and business system needed its own integration: one for your assistant and Salesforce, another for a different assistant and Salesforce, another for each of them and your ticketing system. MCP turns that many-to-many mess into a plug-and-socket arrangement. The spec itself says it takes inspiration from the Language Server Protocol, which did the same thing for programming-language support across code editors (MCP specification).

A useful mental model for non-engineers: MCP is to AI assistants roughly what USB is to laptops. It does not make the device smarter. It makes connecting things predictable.

How the Model Context Protocol works

MCP defines three participants. The official architecture docs put it this way:

• Host: the AI application the user works in, such as Claude Desktop, Claude Code or Visual Studio Code. It coordinates one or more clients.
• Client: a connector inside the host. The host creates one client per server, and each client keeps a dedicated connection to its server.
• Server: a program that exposes context and capabilities. It can run locally on the user's machine or remotely as a hosted service.

Messages between client and server use JSON-RPC 2.0. There are two standard transports: stdio for local servers running as a process on the same machine, and Streamable HTTP for remote servers, where the docs recommend OAuth for obtaining access tokens.

The three server primitives: tools, resources and prompts

What a server offers is described in three primitives, and they are the part of MCP worth understanding even if you never write code:

Clients discover what is available by calling list methods such as tools/list, then invoke a tool with tools/call. The docs give a good concrete example: a database server might expose tools for querying, a resource containing the schema, and a prompt with few-shot examples for using those tools.

Clients can offer features back to servers too. The main one today is elicitation, which lets a server ask the user for more information or for confirmation of an action mid-task. That matters for approval flows, which we come back to below.

What changed in the 2026-07-28 specification

If you read an MCP explainer from 2025, parts of it are now out of date. The 2026-07-28 changelog made MCP stateless: the old initialize handshake and protocol-level sessions are gone, every request carries its own protocol version and client capabilities, and servers must implement a new server/discover method. The maintainers' release post frames the goal as making MCP a first-class HTTP workload, so any request can land on any server instance behind an ordinary load balancer.

The same release deprecated the Roots, Sampling and Logging features (they keep working through a minimum 12-month deprecation window), moved long-running Tasks into an official extension, added caching hints to list responses, and tightened authorization, including issuer validation and a shift from Dynamic Client Registration toward Client ID Metadata Documents. For a business, the practical takeaway is that remote MCP servers are now easier to run like any other web service.

Who has adopted MCP?

Adoption is the main reason MCP matters. A protocol only helps if the tools you use speak it. Here is what the vendors themselves have announced:

• Anthropic: MCP support across Claude products. At the December 2025 donation, Anthropic said Claude offered 75+ connectors powered by MCP (Anthropic).
• OpenAI: co-founded the Agentic AI Foundation. Its Agents SDK supports hosted MCP tools through the Responses API as well as stdio and Streamable HTTP servers (OpenAI Agents SDK docs).
• Microsoft: announced general availability of MCP in Copilot Studio on May 29, 2025 (Microsoft Copilot Blog).
• Google: at Google Cloud Next '26, announced more than 50 Google-managed MCP servers either generally available or in preview (Google Cloud Blog, April 29, 2026).

The usage numbers have grown quickly. In December 2025 Anthropic reported more than 10,000 active public MCP servers and 97M+ monthly SDK downloads across Python and TypeScript, with first-class client support in ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and Claude. By the July 2026 spec release, the maintainers reported "close to half-a-billion downloads a month" across the Tier 1 SDKs (MCP Blog).

MCP vs. function calling: what's the difference?

This is the most common point of confusion, and the short answer is that they work at different layers and are used together.

Function calling (also called tool use) is a model capability. You describe a set of functions to the model in your API request, and the model responds with a structured request to call one of them. Your application code then runs the function and sends back the result. Each provider has its own format, and the tool definitions live inside your app.

MCP is a protocol for where those tools come from. It standardizes how an application discovers tools, resources and prompts from an external server and how it calls them. The official docs are explicit that MCP "focuses solely on the protocol for context exchange" and does not dictate how AI applications use LLMs (MCP docs). In practice, a host lists the tools from its connected MCP servers, hands them to the model through that model's function-calling interface, and routes the model's call to the right server.

MCP vs. A2A (Agent2Agent)

Google announced the Agent2Agent (A2A) protocol in April 2025 and donated it to the Linux Foundation in June 2025; A2A v1.0, its first production-ready version, shipped in March 2026 (Google Open Source Blog).

The two protocols solve different problems. MCP connects an agent to tools and data. A2A connects an agent to another agent, which may be built by a different vendor on a different framework, and treats it as a peer that can take on a task. Google's own summary: "while MCP manages internal tool integration, A2A handles the vital external coordination between autonomous entities." A realistic architecture might use both: your procurement agent uses MCP to read your ERP, and A2A to hand a shipping question to a logistics partner's agent.

Governance: who controls MCP in 2026?

A standard owned by one AI lab is a harder sell to its competitors. On December 9, 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP joined as a founding project alongside Block's goose and OpenAI's AGENTS.md (Anthropic; Linux Foundation).

Per the MCP project's announcement, the AAIF board handles budget and strategy while MCP keeps autonomy over its technical direction, with maintainers making decisions through the Specification Enhancement Proposal (SEP) process. Since then the project has adopted a formal feature lifecycle and deprecation policy, and its August 2026 roadmap lists agent identity and enterprise security as a priority area and notes that Enterprise-Managed Authorization is now stable. For buyers, this is a reasonable signal that MCP is safe to build on: it has a vendor-neutral home, a versioned spec and a published deprecation policy.

MCP security considerations

MCP makes it easy to give an AI model real capabilities. That is exactly why it needs care. The spec is blunt: tools "represent arbitrary code execution and must be treated with appropriate caution," hosts must get explicit user consent before invoking any tool, and tool descriptions should be treated as untrusted unless they come from a trusted server. It also admits that MCP "cannot enforce these security principles at the protocol level" (MCP specification). Security is the implementer's job.

The main risks to plan for:

• Tool poisoning: malicious instructions hidden in a tool's description, invisible to the user but read by the model. Invariant Labs demonstrated a harmless-looking add tool that told the model to read SSH keys and config files and send them out (Invariant Labs, April 2025).
• Prompt injection through tool results: a server returns an email, web page or ticket containing instructions, and the model follows them. See our guide to AI agent security and prompt injection.
• Token passthrough and confused deputy problems: the official security best practices forbid servers from accepting tokens not issued to them, and require per-client consent for proxy servers.
• Local server compromise: a local server runs with your user's privileges. The same guidance calls for showing the exact startup command before install and sandboxing servers with minimal default access.
• Over-broad scopes: a stolen token with wildcard permissions exposes everything. The guidance recommends a minimal initial scope and step-up authorization for privileged operations.

None of these are reasons to avoid MCP. They are reasons to treat an MCP server like any other production API that touches sensitive data: authenticate it, scope it tightly, log every call, and only connect servers you trust or have reviewed.

When should a business build its own MCP server?

Many popular SaaS products now publish their own MCP servers, so first check whether one already exists for the system you care about. Building your own makes sense when:

• You have an internal system no vendor will ever cover: a custom order database, a pricing engine, a legacy ERP, a document store. Wrapping it in an MCP server gives every approved AI tool in your company one controlled way in.
• Several AI apps or teams need the same integration: support uses one assistant, engineering uses another, and a background agent needs the same data. One server beats three bespoke connectors.
• You want central control over what AI can do: an MCP server is a natural choke point for permissions, rate limits, audit logs and approval rules, instead of scattering them across prompts.
• You want to avoid lock-in to one model vendor: because MCP is supported across major hosts, the integration outlives any single model choice.

It is usually not worth it when you have a single agent calling two or three APIs from one codebase. Direct function calling is simpler, and you can wrap the same functions in MCP later if reuse becomes a need. It is also not a fix for a messy process; an MCP server over an unclear workflow just makes the confusion accessible to more tools.

If you do build one, a few design rules save pain later: expose narrow, task-shaped tools (lookup_invoice, draft_refund) rather than a generic run_sql; make read-only resources the default and write tools the exception; require an approval step for anything that moves money, sends external messages or deletes data; and put the server behind the same authentication, logging and monitoring you would use for any internal API. Our post on agent evaluation and observability covers the logging side in more depth.

How Flowrest Labs approaches MCP and agent integrations

We treat MCP as a proven tool, not a strategy. When we scope a custom AI agent or an AI workflow automation project, the first question is which systems the agent needs to reach and what it should be allowed to do in each one. Sometimes the answer is a small set of direct API calls. Sometimes it is an internal MCP server that several assistants, including a private knowledge assistant, can share.

Either way, the same principles apply: least-privilege tools, role-based permissions, activity audit logging, and a one-click human approval in Slack or email before any consequential action runs. Every line of integration code, including any MCP server we build, is handed over with full documentation and 100% IP ownership, so your team is never locked into us or into one model vendor. If your integration needs a web front end or admin console, our custom web app development team builds that alongside it.

Not sure whether MCP, plain function calling or a simple automation is the right fit for your systems? Our AI consulting and workflow audits exist for exactly that question. Start with a free 30-minute workflow audit.