My name is Lena — just someone who's spent a lot of time sitting next to AI systems, watching how they behave.

The people who read my writing aren't usually here looking for answers. They're building agents, debugging workflows that keep breaking in the same spot, trying to make systems more reliable without babysitting them constantly. They're smart enough — they just want someone to think through things carefully alongside them.

This piece is about one word: MCP.

It's been showing up everywhere lately. Developer forums, tool documentation, any conversation about AI agents connecting to the outside world — MCP is in all of it. But here's something I keep noticing: a lot of people use the term without anyone really sitting down to explain what it actually does.

So. What is it? What problem did it solve? And where does it stop?

I've been following this protocol since it launched. Some parts feel clear to me now. Others I'm still working through. But one thing I'm fairly sure of: if you're doing anything with AI agents, MCP isn't something you can just skip past.

Let's start from the beginning.

Here's what this piece covers — what MCP is, how it works, who supports it, what's available in the ecosystem, and where its real limits are. No technical background assumed, but nothing oversimplified either.

What Is MCP?

MCP — Model Context Protocol — introduced by Anthropic, aims to standardize how AI systems interact with external tools. In practice, developers use MCP servers to expose capabilities like file access or APIs to agents such as Claude. That's the technical answer. Here's what it actually means in practice:

Before MCP existed, every time a developer wanted their AI assistant to interact with something — a database, a calendar, a GitHub repository, a web search engine — they had to write a custom connector. From scratch. Every single time, for every tool, for every AI platform. If you were building on Claude and also using GPT-4, you'd effectively be writing everything twice.

The problem MCP was built to solve

Think of this like charging cables before USB-C came along. Every device had its own proprietary connector. If you had three devices, you needed three different cables. The cables worked fine individually, but as a system, it was chaos.

Before MCP, developers often had to build custom connectors for each data source or tool, resulting in what Anthropic described as an "N×M" data integration problem — meaning if you had N AI systems and M tools, you potentially needed N times M different integrations. That's a lot of duplicate work.

MCP was announced by Anthropic in November 2024 as an open standard for connecting AI assistants to data systems such as content repositories, business management tools, and development environments. It was open-sourced from day one, which turned out to matter enormously for how fast it spread.

How MCP works — basic architecture

At its core, MCP establishes a shared language. MCP provides a standardized way for applications to read files, execute functions, and handle contextual prompts.

The protocol is built on JSON-RPC 2.0 — a well-established, lightweight remote procedure call standard. MCP re-uses the message-flow ideas of the Language Server Protocol (LSP), which is the same protocol that made code intelligence work consistently across editors like VS Code, Vim, and others. If that architecture sounds familiar, it's because it works: one standard, many implementations.

The key mental model is this: MCP doesn't change what AI models can think — it changes what they can reach.

MCP Architecture by altexsoft

MCP Servers and MCP Clients

Once you understand the two sides of MCP, everything else falls into place.

What an MCP server does

An MCP server is a piece of software that exposes capabilities — tools, data, and resources — in a standardized way. The server is built by whoever owns that capability. GitHub built an MCP server for GitHub. Stripe built one for payments. Figma built one for design files.

The server decides what gets exposed. It defines which tools an AI can call, what data it can read, and what actions it's allowed to take. This is where access control lives.

What an MCP client does

An MCP client is the AI application — the thing you actually talk to. Claude.ai is an MCP client. The ChatGPT desktop app is an MCP client. Cursor (the AI code editor) is an MCP client. When you ask one of these to "look up my GitHub issues" or "check what's in my database," it's using the MCP client layer to call the appropriate server.

The clean separation here is important: the client doesn't need to know how GitHub's API works internally. It just needs to know how to speak MCP — and the server handles the translation to GitHub's actual systems.

How discovery and connection happen

This is one area that's still maturing. Today, if you want to know what an MCP server can do, you have to connect to it first. This makes it difficult for clients to browse available servers or for systems like a registry to automatically catalog capabilities.

The MCP team is actively working on this. Their roadmap includes letting servers advertise themselves through .well-known URLs — essentially giving each server a public-facing "business card" that clients can read without needing to connect first. Think of it like how websites publish metadata that search engines can read without a full page load.

For now, discovery usually happens manually: you configure your MCP client with the server URL, authenticate, and the client learns what tools are available at connection time. MCP uses OAuth 2.1 authentication, meaning you explicitly authorize what the AI can and cannot do. No action can be taken on your account without your permission.

Who Supports MCP and What's Available

Model providers (verified)

The adoption curve here has been fast by any standard. Following MCP's announcement, the protocol was adopted by major AI providers, including OpenAI and Google DeepMind.

Anthropic introduced MCP in November 2024 and open-sourced it immediately. By January 2025, AI developer tools like Cursor and Windsurf had already added support. In March 2025, OpenAI officially adopted the protocol. Google DeepMind followed. Microsoft announced Windows-level MCP support and integrated it into Azure and their Semantic Kernel framework.

In December 2025, the governance situation changed significantly. Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block, and OpenAI. That move matters — it took MCP from being Anthropic's protocol to being the AI industry's protocol.

As of early 2026, the current specification released in November 2025 is the stable base that all major providers are building against. SDKs are available in Python, TypeScript, C#, and Java.

Community MCP server ecosystem

This is where things got interesting fast. By March 2026, MCP had reached 97 million monthly SDK downloads and 5,800+ community-built servers.

Browsing the official MCP server registry gives you a real sense of the breadth: GitHub (repository management, issues, PRs), Stripe (payments and customers), Figma (design context), PostgreSQL (database queries), Slack (team communication), AWS services, Kubernetes management, Elasticsearch, and hundreds more.

The reference server repository maintained by the MCP steering group is intended to house a small number of reference implementations to demonstrate MCP features and SDK usage — educational examples for developers building their own servers, not production-ready solutions. The real action is in community-built servers and official integrations from major platforms.

A practical note on security: the MCP spec requires user approval before tools run, but not every host was building that approval step properly in early implementations. Prompt injection through malicious server responses is a real concern — a compromised MCP server could try to manipulate the AI's behavior through its output. Always verify what permissions you're granting when connecting to a new MCP server, especially community-built ones.

What MCP Does and Does Not Solve

This is the part that often gets glossed over, and honestly it's where the most interesting questions live.

Connection vs. capability persistence

MCP solves connection. Elegantly, at scale, with broad industry buy-in. That's genuinely significant.

What MCP does not solve is what happens after a successful connection. Think about what actually occurs during a typical agentic workflow: an AI connects to a tool, calls it, gets a result, and uses that result to produce an output. Then the conversation ends — or the context window fills up — and the session terminates.

The tool call happened. The result was used. But nothing about how that interaction went was retained in a persistent, reusable form.

The next time you start a session, the same agent will have no memory of what worked, what failed, or what sequence of tool calls produced the best outcome last time. It starts fresh. It will potentially make the same mistakes. It will re-explore the same search patterns. This isn't a flaw in MCP specifically — it's just outside MCP's scope.

Why a successful tool call doesn't become reusable knowledge

Here's a concrete example. Suppose you use an AI agent to debug a recurring issue in your codebase. The agent connects to your GitHub MCP server, reads several files, runs some searches, and — after a few attempts — finds the root cause and proposes a fix. That works.

Two weeks later, a slightly different version of the same issue appears. The agent connects to GitHub again through MCP — same protocol, same standards, same reliable connection. But it has no memory of what it figured out last time. The successful debugging path isn't stored anywhere structured. It can't be inherited by another agent working on a related problem. The resolution lives in a closed conversation.

This isn't a knock on MCP. It does exactly what it's designed to do: provide a standardized, reliable interface between AI systems and external tools. MCP has moved well past its origins as a way to wire up local tools — it now runs in production at companies large and small and powers agent workflows. That's real progress.

But connection infrastructure and capability persistence are genuinely different problems. MCP solves the first. The second is where the next generation of agent infrastructure work is focused.

Limits and Tradeoffs

A few honest observations after watching this protocol mature:

Scaling stateful servers is still tricky. Current implementations often need to remember things between requests, which makes horizontal scaling across multiple server instances challenging. While Streamable HTTP transport provides some stateless support, pain points remain around server startup and session handling. The 2026 roadmap addresses this directly, but it's worth knowing if you're planning production deployments at scale.

Enterprise authentication is still catching up. The spec supports OAuth-based authorization, and OAuth 2.1 enterprise integrations are on the 2026 roadmap. For regulated industries with strict identity provider requirements, some gaps remain. Enterprises are deploying MCP and running into a predictable set of problems: audit trails, SSO-integrated auth, gateway behavior, and configuration portability.

The security burden sits with implementers. MCP itself cannot enforce security principles at the protocol level — implementors must build robust consent and authorization flows, provide clear documentation of security implications, and implement appropriate access controls. This is a reasonable design choice (the protocol stays lightweight), but it means the quality of security varies significantly across the ecosystem.

Discovery is still mostly manual. As mentioned earlier, you generally have to know which servers you want to connect before you connect them. The registry preview and .well-known URL work will help, but right now this is a friction point for new users exploring the ecosystem.

Community server quality varies. With 5,800+ servers, the range is enormous. Some are maintained by the companies themselves (GitHub's server, Stripe's server) with security actively prioritized. Others are community experiments. Treat unknown servers the same way you'd treat any third-party code — review what access you're granting.

FAQ

Is MCP only for developers?

Not exactly, but today you'll mostly encounter it through developer tools — code editors like Cursor or Windsurf, AI IDEs, and agent frameworks. As more applications embed MCP support internally, end users will interact with it without knowing it's there.

Does using MCP mean the AI can do anything on my computer or accounts?

No. Each MCP server exposes only what its developer chose to expose, and you authorize access explicitly. The connection doesn't grant broad permissions — it grants the specific capabilities defined by that server. That said, reviewing what you're authorizing before connecting to any new server is always wise.

What's the difference between MCP and regular API calls?

A regular API call requires the AI system to have been specifically programmed to talk to that API — custom code, hardcoded endpoints, custom authentication handling. MCP standardizes all of that so any compliant AI client can talk to any compliant server without custom code on either end. It's the difference between writing a new driver for every USB device versus having a standard USB protocol.

Does MCP work across different AI models?

Yes. This is one of its most significant properties. MCP provides a universal interface — a business builds one MCP server and any AI assistant that speaks MCP, whether Claude, ChatGPT, or something else, can connect to it.

How is MCP different from function calling?

Function calling (sometimes called tool use) is the mechanism by which a specific AI model invokes a tool. MCP is the standardized protocol layer above that — it defines how tools are discovered, described, and communicated across different systems. Think of function calling as the mechanism inside one AI, and MCP as the shared language across the entire ecosystem.

Is MCP officially stable?

MCP's current spec release came out in November 2025. The official specification is considered stable for building against. The 2026 roadmap focuses on enterprise readiness, better scaling, and improved discovery — not fundamental protocol changes. For most use cases, what's available today is production-ready.

Where can I find available MCP servers?

The MCP Registry is the official catalog. The community-maintained awesome-mcp-servers list is also comprehensive. For reference implementations, Anthropic maintains the modelcontextprotocol/servers repository on GitHub.

Still watching how this evolves. The connection problem feels genuinely solved — what happens next, at the capability layer, is the interesting question.

What Is MCP? The AI Tool Connection Standard