One Year of MCP

In late November 2024, Anthropic released the Model Context Protocol. It showed up on Hacker News and in our LinkedIn feeds. "That's nice," we thought. "I'll make a note to check that out sometime." Some developers tried it out. Most were focused on other things. Turkey probably.

A year later, the turkey is long gone and the AI landscape looks completely different. MCP is now a large part of it.

Over 16,000 MCP servers exist in the wild. OpenAI has adopted it across ChatGPT (sort of), their Agents SDK, and their Responses API. Google DeepMind announced MCP support for Gemini. Companies like GitHub, Block, Apollo, Replit, Sourcegraph, Linear, Zapier and many others have integrated it into their platforms. At Zuplo we launched MCP support to help developers expose their API routes as MCP tools quickly, with all the security trimmings that an API gateway offers baked right in.

MCP went from "interesting protocol" to "rapidly adopted standard" in less than a single year.

This isn't just another AI hype cycle playing out. This is what happens when an open standard begins to solve a real infrastructure problem at exactly the right moment.

The Infrastructure Layer We Didn't Know We Needed#

Before MCP, connecting AI models to data sources meant writing custom code.

Your AI assistant needs to check your calendar? Custom integration. It needs to search your Google Drive? Another custom integration. Access your CRM? Yet another one. Query your internal database? You get the idea. Plenty of companies were working on solving exactly this problem. I know because I worked for one.

Each connection required its own implementation, its own authentication flow, its own error handling, its own maintenance burden (and it really is a burden). Every new AI model meant rebuilding all of those integrations. Every new data source meant adding support across all your AI tools.

It doesn't scale. It can't scale.

We've seen this pattern before. HTTP standardized how computers talk to each other on the web. SQL standardized how applications query databases. OpenAPI standardized how we describe and document REST APIs.

Standards win because they reduce friction. They enable ecosystem growth. They let developers stop building plumbing and start building products.

MCP did for AI context what these protocols did for their domains. It created a universal way for AI systems to access external data and tools. Any AI tool that supports MCP can connect to any MCP server. Write the integration once, use it everywhere.

The "USB-C for AI" metaphor stuck because it's accurate.

From Zero to Ubiquitous#

Let's take a look at the journey so far:

November 2024: The Release#

Anthropic released MCP as an open standard with an open-source implementation. They included SDKs for Python and TypeScript, along with reference implementations for popular services like Google Drive, Slack, GitHub, and Postgres.

Claude Desktop became the first major application to support MCP, as you would expect. Users could edit a JSON configuration file to connect Claude to their local tools and data sources. It worked, but the use case felt narrow. This seemed like a power user feature, not a fundamental shift.

The community started building and developers created MCP servers for their favorite tools. The GitHub repository filled with examples. But adoption was still small, still niche, almost uncertain as to whether this was really worth the time.

March 2025: OpenAI Makes it Legit#

Sam Altman posted on X: "people love MCP and we are excited to add support across our products."

OpenAI adopted MCP across their product line and this was the signal that people had been waiting on. MCP wasn't just Anthropic's thing anymore. It was becoming an industry standard.

With that the attitude to adoption of MCP shifted. Before March, companies were asking "should we support this?" After March, they were asking, "when can we ship this?"

April 2025: Google Agrees#

Demis Hassabis, CEO of Google DeepMind, confirmed MCP support for Gemini models and their infrastructure. His words mattered: "MCP is a good protocol and it's rapidly becoming an open standard for the AI agentic era."

When the three major AI labs (Anthropic, OpenAI, and Google) get behind a standard, that standard becomes something you can build on. You can rely on it (sort of) and begin to make architectural decisions based on it.

Developer tool companies followed quickly. Replit added MCP support. So did Cursor and then VS Code. They were building MCP into the core of their products because their users were asking for it, and because there was now quite a bit of FOMO going around.

Today: The Ecosystem#

Today, the community maintains connectors for almost any service you can think of and enterprise companies are building private MCP servers for internal systems whilst worrying about how to govern unregulated MCP server usage throughout their teams.

Platforms are emerging to make MCP easier to adopt. Zuplo's MCP service lets developers expose their existing APIs as MCP servers without rebuilding everything from scratch. The infrastructure layer is filling in.

This is what early-stage adoption looks like when it's working. The protocol is stable enough that people are starting to build products and even businesses on top of it. More pop up each week!

Why It Worked#

The Timing Was Right#

MCP arrived exactly when enterprises were moving from AI experiments to production deployments.

In late 2024, companies had proven that AI could work in demos and prototypes. The next question became: how do we connect this to our actual systems? How do we give AI access to the data it needs without building a hundred custom integrations?

MCP answered that question. The timing couldn't have been better.

The Design Was Good Enough#

MCP uses a client-server architecture built on JSON-RPC 2.0. This wasn't invented from scratch. The protocol deliberately reuses concepts from the Language Server Protocol (LSP), which standardized how code editors communicate with language tools.

MCP applied the same patterns to a new problem space.

The technical choices made sense at the time. Stdio for local servers. HTTP with Server-Sent Events for remote servers with support for stateful and stateless interactions.

That initial design has changed a lot over the past twelve months. The shift from stdio to HTTP+SSE to Streamable HTTP shows the protocol is still finding its footing in a scramble to support the right use cases. Along with that, the authorization spec is still evolving and the final remote server story is still being figured out.

All that change is actually a sign of health. The protocol shipped with a reasonable design and has been adapting based on real-world usage. Good enough to start, flexible enough to improve, and plenty of feedback to work with.

The Need Was Real#

With AI, it's context that matters. An AI agent that can't access your calendar, your email, your CRM, or your internal databases is limited to generic responses and surface-level help based on whatever the model you're using was trained on.

Custom integrations don't scale. Every new tool means more code to write, more authentication flows to implement, more edge cases to handle, more maintenance burden to carry.

MCP aimed to solve a problem that was getting worse every day. As AI capabilities improved, the integration bottleneck became more obvious. Companies needed a way to connect AI to their systems quickly and reliably.

The Approach Was Right#

Anthropic released MCP as an open standard, not a proprietary protocol. This matters.

Open standards can become accepted infrastructure because no single company controls them. It has to be that way for developers to build on them without vendor lock-in concerns. It also means that competitors can collaborate on implementation without too much strategic risk.

MCP is Still Maturing#

MCP solved the core integration problem, but there are still challenges to overcome. These aren't failures, far from it. They're the growing pains of a protocol moving from early adoption to mainstream use whilst being heavily relied upon and solving for a target that is constantly moving. No small feat.

Security Concerns#

In April 2025, security researchers published analysis of MCP's attack surface. They found issues. Prompt injection vulnerabilities. Tool permission problems where combining tools could exfiltrate files. Lookalike tools that could silently replace trusted ones.

A critical RCE vulnerability (CVE-2025-49596) was discovered in Anthropic's MCP Inspector and patched by June 2025.

This is normal for infrastructure protocols. Security researchers find problems. The community fixes them. The protocol gets stronger.

The challenge is that MCP makes AI more powerful, which means security is significantly more critical. An AI agent with access to the wrong tools can do real damage. The community responded with tools like MCP-Scan, which audits MCP servers for security issues and insecure configurations.

Security will continue to be a focus area. This is healthy. Better to find and fix these issues now than after widespread deployment in production systems.

Authentication Struggles#

MCP includes an authorization spec based on OAuth 2.1. This is necessary for remote MCP servers that need to authenticate users and control access to resources.

The current implementation has limitations. It requires the MCP server to act as both the resource server and the authorization server. This creates complexity and limits flexibility in deployment architectures.

The spec recommends Dynamic Client Registration to let clients automatically register with authorization servers, but it's optional. When it's not supported, developers have to manually configure client credentials.

So far implementation of DCR has been somewhat limited, with many MCP servers still opting for straight API key authentication instead.

The challenge is standardizing auth without creating security holes. OAuth is complex. Getting it right in the context of AI agents with broad permissions is even harder.

Remote or Local#

Early MCP focused on local servers using stdio. This worked great for desktop applications like Claude Desktop, where the MCP server runs on the same machine as the client.

But it also created a high barrier to entry. Getting stdio servers running meant editing config files, managing local processes, and understanding how to install and run server code. This kept MCP in the hands of technical users comfortable with command-line tools and local development environments.

Remote servers changed that. They make MCP accessible to a much broader audience. No config files to edit. No local processes to manage. Just a URL and authentication. This is the unlock that moves MCP from developer tool to mainstream capability.

The protocol shifted to support HTTP with Server-Sent Events, then added experimental support for Streamable HTTP. This eliminates the requirement for persistent, stateful connections and enables more traditional stateless server architectures.

Stateless servers are easier to deploy and scale. But persistent connections enable richer interactions, like streaming results and maintaining conversation context.

The community is still figuring out the right balance. Different use cases will likely require different approaches. The protocol is flexible enough to support both, which is good.

Monetization#

For many use cases, monetization isn't a problem. If you're using an MCP server to access a service you already subscribe to, there's no additional monetization needed. The MCP server is just another interface to existing functionality.

But what about standalone MCP servers? Services built specifically as MCP servers that aren't tied to an existing subscription? There's no standard approach here. What about when there is no human in the loop at all?

The real question is whether MCP should facilitate payment through complementary protocols, or if monetization should remain entirely outside the protocol's scope. Should there be standardized ways to handle metering, billing, and rate limiting at the protocol level? Or should each provider solve this independently?

Is this even MCP's problem to solve? For sure it's something that will develop rapidly in 2025 as more companies experiment with MCP-native services, and as more agent based marketplaces begin to emerge.

What This Means for the Next Year#

The ecosystem layer will fill in in 2026. Tools for discovering MCP servers, services for securing and authenticating servers, agentic monetization, and frameworks for faster development will be a constant.

2026 will also see the first production ready MCP Apps bring interactive UIs to the protocol. Tools can now render results as dashboards, visualizations, or custom interfaces instead of just text.

The spec is still in draft, but momentum is rapid and the UI seems like it will be quite standardized. Hopefully this saves us from the iframe-based HTML horrors that we experienced back in the days of Facebook Apps.

The API opportunity is shifting. MCP servers are becoming another way to expose services alongside REST. It doesn't replace existing APIs, far from it. It complements them, but it changes how developers think about integrations and it's forcing many to finally up their API game when it comes to design and quality of responses.

MCP all the way?#

The question now is whether MCP becomes the standard or just a standard. The next year will tell us. Will it be about maturation (fixing security issues, improving authorization, properly solving remote deployment, figuring out monetization)? Or will fragmentation emerge with competing approaches?

The momentum suggests MCP is winning. Open standards win when they solve real problems at the right time. MCP began solving the AI integration problem exactly when it felt like it needed to be solved. The timing was perfect. The design was strong enough. The approach was open. The adoption followed naturally.

But, it's only been a year. It's still so early.

MCP didn't just arrive in 2025. It helped define what 2025 meant for AI. The year when AI went from demos to production. The year when agentic AI became practical... and now it's getting UI.

One year down. The real work is just beginning.