I've been tracking the Model Context Protocol since Anthropic dropped it in late 2024. At first it felt like another standards proposal that would sit in a GitHub repo and collect dust. That didn't happen.
In the last year, OpenAI adopted it. Google adopted it. Microsoft, Amazon, Cursor, Replit, Sourcegraph, basically every tool that touches LLMs now speaks MCP. And in December 2025, Anthropic handed it over to the Linux Foundation. It's not one company's project anymore.
So here's what I think developers actually need to understand about MCP right now, where it helps, where it's broken, and why the security story should worry you more than it probably does.
The short version of what MCP does
Before MCP, if you wanted your AI agent to talk to GitHub, you wrote a GitHub integration. If you wanted it to talk to Slack, you wrote a Slack integration. Every model-tool combination needed its own connector. It was a mess.
MCP standardizes that. One protocol. Any MCP client talks to any MCP server. People call it "USB-C for AI" which is a bit cheesy but honestly pretty accurate.
The technical layer is JSON-RPC 2.0, nothing wild. The real value is the contract it creates: a structured way for models to know what tools exist, what they do, and how to call them. Instead of stuffing everything into a prompt and hoping for the best, you have an actual interface.
One thing I keep seeing people miss: prompts tell a model how to behave, but MCP defines what the model can see. That's a different thing entirely, and it matters a lot once you move past chatbot demos into actual production systems.
Why this blew up in 2025-2026
Three things happened at the same time.
- First, agents moved out of the sandbox. They stopped being demo projects and started running real workflows. Booking meetings, querying databases, triggering deployments, writing and executing code. When your agent is doing actual things in production, you can't just wing the context. You need structure. MCP gives you that structure.
- Second, tool calling became a standard feature. OpenAI, Anthropic, Google, Amazon, they all support it natively now. But before MCP, every integration was vendor-specific. Build a tool for Claude and it didn't work with GPT. MCP made tools portable across models. That's what really drove adoption.
- Third, the governance people showed up. As soon as agents started touching real data, security and compliance teams wanted answers. Who authorized this tool call? What did the agent access? Can you show me the audit trail? Ad-hoc prompt stuffing doesn't answer those questions. MCP's structured approach does. Or at least it can, if you set it up right.
Here's where I get uncomfortable
I set up MCP with Claude Desktop recently. Filesystem server first (lets Claude read and write files on your machine), then the GitHub server. The filesystem setup took maybe five minutes. The GitHub one needed a personal access token, which I pasted into a JSON config file.
And that's when it clicked for me.
That token sitting in a plaintext config file has access to my repos. If I'd installed a sketchy third-party MCP server from npm instead of the official one, it could have used that token. Or if the LLM hallucinated a tool call I didn't expect, it could have done something I didn't authorize.
This isn't hypothetical. It's already happened to other people.
Researchers showed that a malicious GitHub issue (just text in a public repo) could hijack an AI assistant connected through the GitHub MCP server. The agent accessed private repos and leaked data into a public pull request. The root cause was an over-permissioned token combined with untrusted content flowing into the model's context.
There was also a fake "Postmark MCP Server" package on npm that looked legit but was silently BCC'ing all email traffic to an attacker's server. Invoices, internal memos, everything. Classic supply chain attack, just applied to the MCP ecosystem.
And then Anthropic's own Filesystem-MCP server had sandbox escape vulnerabilities. Their debugging tool, the MCP Inspector, had unauthenticated remote code execution flaws. If the company that created MCP had security holes in their own implementation, what does that tell you about the broader ecosystem?
The Coalition for Secure AI put out a white paper in early 2026 identifying over 40 threat categories in MCP implementations. Forty. Most teams deploying MCP aren't thinking about even a handful of them.
How I think about MCP in production
I don't have all the answers here, but after using it and reading through the breach reports, here's the mental model I've landed on.
Treat it like infrastructure. MCP isn't a cool feature. It's plumbing, like your database connection layer or your API gateway. You wouldn't deploy a database without authentication. Don't deploy an MCP server without it either.
Least privilege, always. The GitHub breach happened because one token had access to everything. Scope your tokens aggressively. Give each MCP server the minimum permissions it needs. This is basic security, but in the rush to make the AI do impressive things, people skip it.
Don't trust the LLM's decisions blindly. This is the hardest part. In normal software, your code calls an API and you trust it because you wrote the code. With MCP, the LLM decides which tool to call and with what parameters. That decision is probabilistic, not deterministic. You need validation between the LLM's decision and the actual execution. Especially for anything destructive or sensitive.
MCP is not a workflow engine. I see people confuse this. MCP handles how context gets to the model. It doesn't handle when tools run, how failures are managed, or where humans stay in the loop. You need orchestration on top of MCP. Skip MCP and your workflows push fragile context into prompts. Skip workflows and MCP by itself won't save you.
Log everything. Every tool call, every parameter, every response. If you can't trace what happened after the fact, you don't have a production system. You have a liability.
Three things I'm watching
The Agentic AI Foundation. Anthropic donated MCP to this new Linux Foundation fund in December 2025. Block and OpenAI co-founded it. This means governance is no longer one company's call. How they balance rapid adoption with security maturity will shape whether MCP becomes the TCP/IP of AI or another abandoned standard.
Google's A2A protocol. MCP connects agents to tools. A2A connects agents to each other. These two protocols are going to either converge or compete. I'd bet on convergence eventually, but it's going to be messy for a while.
The first big production breach. The research-stage vulnerabilities are already bad. When a real production breach happens through an MCP vector (and it will), the ecosystem's response will tell us everything. Either it accelerates security maturity or it causes a trust collapse. We'll see.
Where I land
MCP solves a real problem. The old way of building bespoke connectors for every model-tool combination was unsustainable. Having a standard protocol is genuinely better, and the adoption numbers prove the industry agrees.
But we're in the "move fast" phase right now, and the "don't break things" part hasn't caught up. The security surface is growing faster than the security tooling. The convenience is real, and so are the risks.
We've seen this before. Containers, microservices, serverless. A powerful abstraction shows up, everyone adopts it before the security story is ready, and then we spend years bolting on the guardrails we should have started with.
MCP doesn't have to repeat that cycle. But it will if engineers treat it as a toy instead of infrastructure.
Build with it. Just build carefully.
I'm curious what other developers are seeing. Are you running MCP in production or still experimenting? What security patterns have worked for you? Drop a comment, I'd genuinely like to know.
SOCIAL SHARE CARD GENERATOR