What Is MCP? The Standard Behind Every AI Agent in 2026

Before late 2024, connecting an AI model to your company's tools meant writing a custom integration for every pair.

Four AI applications and four data sources? Sixteen integrations, each with its own auth, its own error handling, its own quiet breakage when an API changed. Add a fifth tool and you write four more. The math punishes you for growing.

MCP collapsed that. One protocol, spoken by both sides — so four apps and four tools becomes eight integrations instead of sixteen, and adding a ninth thing costs one connector, not eight.

That's the whole idea. It's unglamorous, and it's why the protocol went from one company's internal experiment to something with over 10,000 public servers and 97 million monthly SDK downloads in roughly twelve months (Anthropic, December 2025).

Then security researchers started scanning those servers, and found that 43% of the ones they tested had command injection flaws. Both halves of that story matter.

Key Takeaways

• MCP is an open protocol that standardises how AI applications connect to external tools and data, replacing N×M custom integrations with N+M.

• Adopted by ChatGPT, Gemini, Cursor, Microsoft Copilot and VS Code; donated to the Linux Foundation in December 2025.

• Public MCP servers passed 10,000, with 97M+ monthly SDK downloads (Anthropic, 2025).

• Security is the unsolved part: independent scans find large shares of public servers carry exploitable flaws.

What Is MCP, in Plain English?

MCP — Model Context Protocol — is a shared language that lets an AI application talk to outside tools without a bespoke integration for each one. The comparison people reach for is USB-C: before it, every device had its own cable; after it, one port fits everything.

Three pieces make up the system, and the naming trips people up at first:

• Host — the AI application the user interacts with (Claude, ChatGPT, Cursor, VS Code).

• Client — the connector inside the host that maintains a link to one server.

• Server — a small program that exposes a specific capability: your GitHub repos, a Postgres database, a Slack workspace, a local filesystem.

The server is the part most people build. And "server" is misleading — an MCP server is often a few hundred lines of code running on your own machine, not infrastructure in a data centre.

Servers offer three kinds of thing to the model. Tools are actions it can take (create an issue, run a query). Resources are data it can read (a file, a record). Prompts are reusable templates a user can invoke. Most servers in the wild are mainly tools and resources.

What Problem Did It Actually Solve?

The integration math, and the duplicated effort behind it. Every AI product company was independently building the same connector to the same twenty services, and none of that work was reusable by anyone else.

MCP made the connector the unit of reuse. Write a Jira server once, and it works with any MCP-speaking host — today's and next year's. That's why adoption moved through the industry so fast rather than staying with its author: OpenAI adopted it across its platform in March 2025, with Google and Microsoft following that spring.

The practical effect shows in who can now build these things. Standing up an MCP server doesn't require you to design an API contract, handle OAuth flows from scratch, or write an SDK integration — the protocol specifies that shape for you. Teams that previously couldn't afford to build agent integrations can now ship one in an afternoon.

Data access is the dominant use. An analysis of roughly 1,400 MCP servers found that supplying better context to AI is the most commonly cited value, with 63% of users adopting servers to reach documentation, knowledge bases and other data sources (Bloomberry, 2026).

Who Controls It Now?

Nobody, by design — which was the point of the most important move in MCP's short history.

Anthropic created the protocol and open-sourced it in November 2024. On 9 December 2025, it donated MCP to the Linux Foundation, under a new Agentic AI Foundation.

Worth being clear about the conflict here: MCP came from Anthropic, an AI lab with a commercial interest in tools that connect to its models. The donation is what defused that. A protocol controlled by one lab is a strategic asset its competitors have every reason to reject; a protocol under neutral stewardship, with OpenAI as a co-founding member, is infrastructure. The second one is what actually gets adopted.

Adoption at donation time spanned ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.

What Does an MCP Server Actually Do?

Walk through a concrete case. You want an AI assistant that can answer questions about your team's support tickets.

Without MCP, you build a custom integration into whichever assistant you use, and you rebuild it if you switch. With MCP, you write a server that exposes two things: a tool called search_tickets and a resource that returns a single ticket by ID. You describe each one in plain language — what it does, what arguments it takes.

Then the loop runs like this:

1. The user asks, "What are customers complaining about this week?"

2. The host shows the model the available tools, including your description of search_tickets.

3. The model decides to call it, with arguments it chooses.

4. Your server runs the query against your real database and returns results.

5. The model reads the results and answers.

Two things about step 3 deserve attention, because they explain both MCP's power and its risk. The model picks the tool and writes the arguments, based on a text description you wrote. There's no compiler checking that decision, and the description is instructions the model reads and follows.

Hold that thought.

The Security Problem Nobody Has Solved

This is where the honest version of the story diverges from the marketing one.

An analysis of public MCP server implementations found 43% contained command injection flaws, 30% permitted unrestricted URL fetching, and 22% exposed the filesystem. Roughly two-thirds showed poor security practices overall. Independent scans since have found somewhere between 30% and 82% of public servers carrying exploitable flaws, depending on methodology and sample.

Peer-reviewed work has since formalised the central attack. In tool poisoning, malicious instructions are hidden in a tool's metadata — the description the model reads before deciding what to call. The user never sees it; the model treats it as guidance. Academic analysis of 1,899 servers found tool poisoning present in about 5.5% of them, and identified it as the most impactful client-side vulnerability class (threat modeling study, 2026).

Three structural reasons this is hard rather than sloppy:

• Tool descriptions are prompts. Anything a server declares becomes text the model may obey. Installing a server is closer to running untrusted code than adding a library.

• Agents are confused deputies. The server acts with your credentials, so an instruction that tricks the model inherits your access.

• Composition multiplies surface. Connect five servers and one can describe a tool that influences how the model uses another.

If you're deploying MCP at work: treat third-party servers as untrusted, pin versions rather than auto-updating, scope credentials to the minimum, require human approval for destructive actions, and log every tool call. Elastic Security Labs publishes a practical attack-vector and defence guide worth reading before you connect anything to production.

Our read: MCP didn't invent these problems, it standardised the surface where they show up. Before, every insecure integration was insecure in its own bespoke way. Now there's one well-documented pattern — which makes attacks reusable, and also makes defences reusable. That trade is normal for young infrastructure. Early HTTP and email had the same shape. It just means "there's an MCP server for that" is not a reason to install one.

Should You Learn It?

Yes, and it's a small investment with an unusually good ratio. Reading the spec and shipping a working server is roughly a weekend, and it's one of the clearest signals available that you've actually built with AI rather than only used it.

Where to start:

1. Build a server for something you already own — your notes, a side-project database, an internal API. Real data teaches you more than a tutorial.

2. Use the official SDK in Python or TypeScript rather than implementing the protocol by hand.

3. Write the tool descriptions carefully. Model behaviour depends heavily on them, and this is the skill that transfers to all agent work.

4. Then break it deliberately. Give it a bad argument, an ambiguous request, a tool it shouldn't need. Watching where it fails teaches you the failure modes that matter in production.

5. Read the security guidance before connecting anything real. Understanding the risks is itself the differentiator in interviews.

The transferable skill isn't the protocol — specs change. It's designing an interface a non-deterministic caller can use safely. That problem is not going away.

[INTERNAL-LINK: engineering skills that hold value as AI spreads → guide to durable skills for early-career developers]

Frequently Asked Questions

Is MCP only for Claude?

No. It was created by Anthropic but donated to the Linux Foundation in December 2025, with OpenAI and Block as co-founding members and Google, Microsoft and AWS as supporting members. ChatGPT, Gemini, Cursor, Microsoft Copilot and VS Code all support it.

How is MCP different from a normal API?

An API is designed for a programmer who reads documentation. MCP is designed for a model that chooses tools at runtime from plain-language descriptions. The protocol standardises discovery, invocation and results so any host can use any server without custom code.

Is it safe to install MCP servers?

Treat them like untrusted code. Analysis of public implementations found 43% with command injection flaws and around two-thirds with poor security practices overall. Use servers from sources you trust, pin versions, and scope credentials narrowly.

Do I need MCP to build an AI agent?

No. You can call tools directly through a model's function-calling API. MCP pays off when you want integrations that work across multiple hosts, or want to use servers other people have already built rather than writing your own.

Why This One Stuck

Plenty of AI standards get announced. This one spread because it solved an integration problem that was pure cost to everyone, and because its creator gave up control before the rest of the industry had to decide whether to trust a competitor's protocol.

For anyone building right now, MCP is worth learning less for the spec itself than for what it forces you to think about: what an autonomous caller should be allowed to do, how you describe a capability to something that reads descriptions literally, and what happens when it gets that wrong. Those questions outlive any protocol.

Just don't confuse a standard with a safe default. Ten thousand servers exist. A meaningful share of them shouldn't be trusted with your credentials.

Sources