A year ago, connecting an agent to a tool meant writing a bespoke integration and hoping it didn't break on the next API version. Now you install an MCP server and you're done in ten minutes. That speed is exactly why the last twelve months have produced both the fastest tool-integration ecosystem we've seen and a fairly serious trust problem that most teams haven't priced in yet.
The numbers are not hype, they're a warning
MCP's adoption curve is genuinely unusual. Anthropic reported over 97 million monthly SDK downloads across languages by December 2025, more than 10,000 active MCP servers running in production, and hundreds of distinct AI clients speaking the protocol. The community catalog of servers passed 5,800 connectors back in April 2025 and has kept growing since. Enterprise uptake is concentrated but real: roughly 28% of Fortune 500 companies have MCP servers in production, with fintech leading at 45% adoption, driven by exactly the kind of heavy multi-system integration work that makes MCP attractive in the first place.
None of that is the interesting part on its own. What's interesting is what happens when you combine that growth rate with the fact that anyone can publish a server, and most teams grant it access with almost no scrutiny. Fast adoption plus low friction plus sensitive data access is a predictable recipe, and the industry is now living through the predictable outcome.
The Wild West problem, stated plainly
Merge's CTO summed up the core issue about as well as anyone has.
MCP's flexible architecture created a Wild West of potentially untrusted code, where community-published servers could be backdoored or abandoned, and blanket access to sensitive services like email and CRMs became common.
That's not a theoretical risk. A community-maintained MCP server for a popular SaaS tool is, functionally, a piece of third-party code with standing access to whatever credentials you hand it. If that server gets compromised, gets abandoned and stops receiving security patches, or was written by someone who never intended malice but wrote sloppy input handling, your agent inherits that risk the moment you point it at the server. The protocol doesn't distinguish between a well-audited connector maintained by a vendor's engineering team and a weekend project with 40 GitHub stars. You have to do that work yourself.
What actually changed in the protocol, and why it matters
This is the part worth understanding before you dismiss MCP security concerns as old news. The March 2025 spec update turned MCP servers into protected OAuth resource servers, capable of proper token-based auth flows instead of relying on whatever ad hoc credential-passing a local stdio connector used. That's the difference between "MCP was a local-only, trust-the-process-on-your-machine tool" and "MCP is cloud-ready infrastructure that can be deployed remotely with real authentication boundaries."
Before that update, most MCP deployments were effectively unauthenticated by default: a local process, running with whatever permissions the host had, no token scoping, no session boundaries. After it, you can issue scoped tokens, expire them, and audit who used what and when. If you're running MCP servers that predate this shift, or you inherited a setup built during the early stdio-only era, that's the first thing to check. A lot of production deployments are running on the old trust model without anyone re-evaluating it.
What we actually check before granting a server access
After connecting agents to a dozen or so MCP servers across different projects, a rough checklist has emerged that we run before adding one more. None of this is exotic. It's the same due diligence you'd apply to any third-party dependency with credential access, just applied consistently instead of skipped because
- Who maintains it, and are they still shipping patches or is the repo quietly stale
- Does it support scoped OAuth tokens, or does it want a blanket API key with full account access
- What's the actual permission surface: read-only where possible, write access only where the workflow truly requires it
- Is there an audit log of tool calls, and can we pipe that log somewhere we actually monitor
- Has anyone reviewed the source, even briefly, or are we trusting a compiled binary from an unknown publisher
- What happens if this server goes down or gets deprecated mid-project, and how hard is it to swap for an alternative
The permission-scoping point deserves more attention than it usually gets. Most teams grant an MCP server the same access level they'd grant a human employee logging into the tool directly, because that's the default the server's setup docs walk you through. That's backwards. An agent calling a CRM's MCP server to look up contact records doesn't need write access to billing fields. A server wired into email doesn't need send permissions if the workflow only ever reads. Scoping down access per-server, per-workflow, is tedious and most integration guides skip it, but it's the single highest-leverage thing you can do to limit blast radius when something goes wrong.
Why the Linux Foundation move is a bigger deal than it sounds
In December 2025, Anthropic donated MCP to the Linux Foundation's newly formed Agentic AI Foundation, with AWS, Google, Microsoft, OpenAI, Bloomberg, and Cloudflare backing the move. It's tempting to read this as a press release footnote. It isn't. It's a governance signal, and governance is exactly what you should care about if you're making a multi-year bet on a protocol.
A vendor-owned protocol can change direction, deprecate features, or shift priorities based on one company's roadmap. A protocol governed by a multi-vendor foundation with major cloud and AI providers at the table has a much stronger commitment to backward compatibility and a slower, more deliberate change process, because breaking changes now have to clear multiple stakeholders with competing incentives instead of one. For a studio deciding whether to build core integration infrastructure on top of MCP versus rolling something custom, this changes the calculus meaningfully. It's less
Anthropic's thing we're betting on
Sorry, that was an editing error, moving on.