Six months back, if you asked a developer friend what MCP was, half of them would say “some kind of protocol thing Anthropic made” and go back to their terminal. Now every second engineering blog I open has an opinion on it. Cursor supports it. VS Code supports it. Figma has a server for it. Even WordPress shipped an official adapter in February 2026. It went from a niche experiment to something you’re almost expected to know, and honestly, I didn’t see it coming this fast.
This piece is me trying to work through the whole thing properly. Not a hype post, not a hate post. Just what MCP actually is, why it spread the way it did, what it’s costing teams to build on it, where the criticism is fair, and where it’s just people being annoyed at a rough v1. I’ll also get into the questions people keep typing into Google about it, because a lot of the confusion out there is pretty basic stuff that nobody explains simply.
What MCP Actually Is, In Plain Terms
Model Context Protocol is a standard way for an AI model to connect to outside tools and data, instead of every app writing its own custom wiring. Think of a USB port. Before USB, every device needed its own weird cable and driver. Model Context Protocol has been described as the USB-C port for AI, a universal connector that lets any AI application plug into any data source or tool without custom wiring. Anthropic released it in November 2024. It’s open source.
The idea itself is not complicated. An “MCP server” wraps around some tool, say your Google Drive or your company’s internal database, and exposes what it can do in a standard format. Any “MCP client”, which is basically the AI app like Claude or Cursor, can then talk to that server without needing custom code written for it specifically. One server, many clients. That’s the whole pitch.
What’s actually surprised me is how fast this got adopted outside Anthropic’s own walls. The official SDK download figure went from around 100,000 monthly downloads at launch to 97 million by March 2026, a jump Anthropic itself pointed to as evidence of how fast agent developers had standardized on it. For context, someone pointed out that React took about three years to hit 100 million monthly downloads. MCP got there in under two.
Why It Spread Everywhere So Fast
Here’s the thing. This wasn’t really Anthropic pushing a product. In December 2025, Anthropic donated MCP to the Linux Foundation, with OpenAI, Google, and Microsoft coming on as co-sponsors, which is the point where MCP stopped being “Anthropic’s protocol” and started being shared infrastructure. Once your direct competitors are co-sponsoring your open standard, you know it’s not a marketing gimmick anymore.
By mid 2026 the numbers had gotten genuinely big. A pull from the official MCP Registry API in May 2026 counted 9,652 latest server records, and Anthropic separately reported more than 10,000 active public servers in its December 2025 ecosystem update. An independent count by Nerq in the first quarter of 2026 put the number even higher, past 17,000 servers across various registries, because anyone can spin up a server and there’s no single gatekeeper. On GitHub alone, the search API returned nearly 16,000 repositories tagged with the mcp-server topic, and the main modelcontextprotocol/servers repo had over 86,000 stars.
And it’s not just hobby projects anymore. Fortune 500 adoption reportedly reached about 28 percent within 18 months of launch, according to one enterprise deployment guide from early 2026. Figma shipped a native MCP server so a designer’s mockup can go straight into VS Code or Cursor without someone manually re-typing spacing values. Notion has one for its databases. WordPress has one. Slack has one in progress. The pattern is clear: if you’re a SaaS company in 2026 and you don’t have an MCP server, you’re basically betting that AI agents won’t be a channel your customers use to reach your product. That’s a risky bet to make right now.
So why did teams actually adopt it, beyond just following the crowd? A few real reasons. Building N different integrations for N different tools across M different AI clients is an N times M problem, expensive and repetitive. MCP turns it into roughly N plus M, you build the server once and every client that speaks MCP can use it. That’s genuinely useful math, not marketing fluff. It also gives you dynamic discovery, meaning the AI can ask a server “what can you do” at runtime instead of a developer hardcoding every possible action ahead of time. And for teams managing many agents, it gives you one place to plug in auth, logging, and permissions instead of scattering that logic across a dozen custom integrations.
Now the Part that I was thinking about: Is This Over-Engineering?
Okay, tbh, because this is where it gets messy. There’s a real and pretty loud backlash against MCP, and it’s not coming from people who don’t understand the protocol. Some of the sharpest critiques came from inside the AI industry itself.
Around November 2025, a developer named Mario Zechner wrote a post called “What if you don’t need MCP at all?” arguing that large language models already have function calling built in, no major model has any real native knowledge of MCP, and you should actively avoid using it for a lot of use cases. Two days later, Anthropic’s own engineering team published something eerily similar, admitting MCP had real problems in agent code. That’s a strange thing to watch happen, a company publicly agreeing with a critic of their own protocol within 48 hours.
The technical complaint that keeps showing up is token cost. Loading tool definitions eats context before the agent does anything useful. One writeup mentioned a database MCP server with 106 tools that consumed 54,600 tokens just to initialize, before the AI had done a single useful thing. Research from something called the MCPGauge framework found context retrieval through MCP could inflate input token budgets by up to 236 times while often making accuracy worse, not better. That’s not a rounding error, that’s real money and real latency for teams running agents at scale.
Theo Browne, a fairly well known developer YouTuber, put out a video with a title that basically translated to “Anthropic admits MCP sucks,” and it pulled in over 100,000 views. He wasn’t gentle about it either. The core argument from that whole camp is simple: if writing a bit of code to call an API directly is 99 percent more efficient than going through the protocol as designed, why did we build the protocol the way we built it?
I don’t fully disagree with the critics, but I don’t think they’re right about everything either. A lot of the “MCP is dead” energy is coming from solo developers running one agent against one API on their own laptop. For that person, sure, a CLI script probably beats MCP on every metric that matters to them. But that’s not who MCP was ever really built for at scale. The moment you have fifteen engineers, three different AI clients being used across the company, and a compliance team asking who accessed what and when, the math flips completely. A folder of scripts doesn’t give you an audit trail. MCP, done properly, does.
So is it over-engineered? For a hobbyist wiring one tool into one agent, kind of, yeah. For a company connecting two hundred agents across fifteen teams to internal systems with actual governance requirements, not really. It’s not one answer for everyone, and I think a lot of the online arguing happens because both sides are talking about completely different use cases without saying so.
The Actual Cost of Building on It
This part deserves more reality than most vendor blogs give it. Building and running MCP servers isn’t free, and it’s not always simple either.
There’s the token tax already mentioned. There’s also security, and this one is not small. In May 2026 the NSA published a report on MCP security design, which is a fairly unusual thing for a government cybersecurity agency to write about a two year old open source protocol. The report noted that MCP has become the de facto standard for connecting AI driven services and is now used across business, finance, legal, and software development, and it laid out observed security concerns from real deployments. One specific issue that got cited repeatedly across security writeups was a critical remote code execution vulnerability in Anthropic’s own MCP Inspector tool, tracked as CVE-2025–49596. If your protocol’s official debugging tool has an RCE bug, that tells you the tooling was still maturing fast, maybe faster than the security review process could keep up with.
There’s also the plain operational cost. Someone has to build the server, host it, patch it when the underlying API changes, and handle auth. For a while, per-server, per-user login prompts were a genuine mess, enough that Anthropic and partners pushed out a fix called Enterprise-Managed Authorization in mid 2026. That extension went stable and was adopted by Anthropic, Microsoft, and Okta, with servers from Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase supporting it early on. That’s real engineering effort spent just to fix the login experience, which tells you the original design wasn’t fully baked when it shipped.
I’ll admit something here. I spent a while trying to set up a local MCP server for a small side project last month, and the documentation gap between “toy example” and “actually works reliably” was bigger than I expected. It worked, eventually, but I hit a config issue that took me almost an hour to figure out, and the error message gave basically zero hint about what was wrong. Not exactly the seamless plug and play story you read in the marketing pages.
Where the Real Savings Show Up
But it’s not all cost. There’s a version of this where the savings are genuinely real, and it shows up most clearly in two places: documentation access and enterprise integration reuse.
Think about an agent that needs to know how a fast moving library’s API works right now, not what it looked like when the model was trained. A docs MCP server can hand back the current page, current code examples, on demand, instead of the model guessing from stale training data. That’s a legitimate problem solved cleanly, and nobody really argues against MCP for this use case.
The bigger saving is on the integration side for companies with more than a handful of engineers. Once HubSpot builds and maintains an official MCP server, every team using it gets updates for free when HubSpot’s API changes internally. Nobody has to maintain their own script anymore. Multiply that across ten SaaS tools your company depends on, and the maintenance burden that used to sit on your internal platform team basically disappears. That compounding effect is the actual economic case for MCP, more than any single feature.
Anthropic and Cloudflare, working separately, also landed on roughly the same fix for the token cost problem within a few months of each other in late 2025 and early 2026. Instead of exposing every tool as a direct call loaded upfront, the agent gets access to tools as code, essentially browsing a small library of functions and only pulling in what the current task needs. The reported result from one implementation was a 98.7 percent token reduction, dropping from about 150,000 tokens down to roughly 2,000 for the same workflow. That’s the kind of number that actually moves the needle on whether MCP is affordable to run at scale or not.
Where This Is Actually Heading
The 2026 roadmap from the maintainers gives a decent hint at what’s coming, and it’s mostly boring infrastructure work, which honestly is a good sign. Not flashy new features, just plumbing. The four priorities for the year are transport scalability, agent to agent communication, governance maturation, and enterprise readiness, organized around working groups rather than fixed release dates. Streamable HTTP, the transport that lets servers run remotely instead of as local processes, unlocked a wave of production use but is now running into scaling problems of its own, things like stateful sessions fighting with load balancers.
Governance is getting more formal too, because right now every single protocol change has to go through the full group of core maintainers regardless of how small it is, and that’s becoming a bottleneck as the project grows past a small founding team. Enterprise readiness work, meaning audit trails, single sign on, and configuration portability, is expected to land mostly as extensions rather than changes to the core spec, so the base protocol doesn’t get heavier for everyone building small personal projects.
My opinion read is that MCP isn’t going away, but the shape of how people use it is splitting into two clearly different lanes. Solo developers and small teams are drifting toward CLI tools and code-based approaches for pure speed, because token cost matters a lot when you’re paying for it yourself. Larger orgs are leaning further into MCP specifically because of governance, audit, and the fact that they need fifteen different teams to connect to the same tools without each one reinventing the wheel. Both things can be true at once. This isn’t really a story about MCP winning or losing, it’s a story about MCP finding out what it’s actually for after two years of everyone assuming it was for everything.
Long Tail Questions People Are Actually Googling
Is MCP dead in 2026? No, but the hype cooled off a lot from where it was at launch. Enterprise adoption is still climbing, Fortune 500 numbers are in the high twenties percent range, and the Linux Foundation backing with three major AI companies as co-sponsors makes it very unlikely to disappear. What died was the assumption that every single use case needs it.
Do I need MCP if I’m just building a personal AI project? Probably not, at least not right away. If you’re one person calling one or two APIs, a direct integration or a simple script will usually be faster to build and cheaper to run than setting up a full MCP server.
Is MCP the same as an API? Not exactly. MCP standardizes how an AI client discovers and calls tools across different servers, so the client code doesn’t need to change when you swap the underlying tool. A regular API is the thing being wrapped, MCP is the wrapping and the shared language around it.
Why does MCP use so many tokens? Because most clients load full tool definitions into the model’s context window before any actual work happens. With enough tools connected at once this adds up fast, and some research has measured context bloat well beyond what a plain code call would need for the same task.
Is MCP secure? It can be, but it depends heavily on what you connect to. A malicious or poorly built MCP server can trick an agent into unwanted actions, and there have been real vulnerabilities found in official tooling, including at least one serious remote code execution bug. Treat any MCP server you connect to the same way you’d treat any code you’re about to run on your machine.
Should my company build an MCP server for our product? If your customers are likely to use AI agents to interact with your product, probably yes, mainly because your competitors are already doing it and switching cost for users is close to zero once multiple servers exist.
So, Is It the Right Thing?
I don’t think there’s one clean answer, and I’m a little suspicious of anyone who gives you one. MCP solved a real N times M integration problem, and the adoption numbers back that up. It’s also genuinely more expensive in tokens, more work to secure, and rougher around the edges than the pitch decks made it sound in year one. Both of those things are true at the same time.
What I keep coming back to is this: MCP isn’t really “the coding standard” in the sense of one universal right answer for every situation. It’s becoming the default for a specific kind of problem, connecting many tools to many AI clients with some kind of shared governance layer. If that’s not your problem, you probably don’t need it yet, and that’s fine.
If it is your problem, ignoring it at this point is starting to look like the riskier choice, not the safer one.