I’ve been following the Model Context Protocol ever since Anthropic launched it back in late 2024. Honestly, at first, it just seemed like another standards doc destined to sit forgotten on GitHub. Turns out, that’s not what happened. :sweat_smile:
Within a year, OpenAI has jumped on board. So did Google. Then Microsoft, Amazon, Cursor, Replit, Sourcegraph-the list goes on. Pretty much every tool dealing with LLMs now speaks MCP in recent times. And then in December 2025, Anthropic handed the whole thing off to the Linux Foundation. So now, it’s not just Anthropic’s thing anymore which makes me little more curious.
Here’s what actually matters for me and what I feel for developers as well 🙂: what MCP is, where it’s useful, where it falls short, and why I should probably pay a lot more attention to its security than I’m currently doing. These are crucial for me to think in terms of these perspectives.
Here’s the gist of what MCP actually does. Before it came along, if I wanted an AI to talk to GitHub, I had to write a whole GitHub integration. Same story for Slack. Every new tool or model needed its own custom connector. It got messy, faster than built.
MCP changes that. Now there’s 1 protocol any MCP client can talk to any MCP server which is awesome. People keep calling it “USB-C for AI,” which sounds a little cheesy, but honestly, I feel that it fits. :
Under the hood, it’s just JSON-RPC 2.0. Nothing fancy. But the real magic is the contract it sets up: models get a clear, structured way to see what tools are available, what each one does, and exactly how to use them. Instead of cramming everything into a prompt and hoping the model figures it out, you actually get a proper interface.
Here’s something I miss a lot: prompts tell a model how to act, but MCP actually defines what the model can access. That’s a whole different ballgame, and it really matters once I move past chatbots and start building real production systems.
So, why did this take off in 2025 and 2026? Three things all hit at once. :sweat_smile:
First, agents left the sandbox which initiated the upgrade. They weren’t just demo toys anymore suddenly they were booking meetings, querying databases, triggering deployments, writing and running code altogether developing at multiple places. Once my agent starts doing real work in production, I can’t just hope the context lines up. I need structure. MCP brings that order for me.
Next, tool calling became a built-in feature everywhere which I feel is groundbreaking. OpenAI, Anthropic, Google, Amazon they all support it now. Before MCP, each integration was locked to one vendor that led to less exposure and usage of these methods. Build a tool for Claude, it didn’t work with GPT. MCP made tools portable between models, and that’s what really got things moving.
Finally, governance showed up there it is, the future. The second agents touched real data, security and compliance teams wanted answers. Who gave this tool permission? What did the agent actually see? Can you show me the audit log? Prompt hacks just don’t cut it. MCP’s structured approach does, as long as I set it up right. These is just starting !!!!!!
Here’s where I get uncomfortable :upsidedownface:
I set up MCP with Claude Desktop not long ago. Started with the filesystem server-so Claude could read and write files on my computer-then moved on to the GitHub server. The filesystem part was quick, maybe five minutes. For GitHub, I had to grab a personal access token and drop it into a JSON config…!
That’s when the risks really hit me. :slightlysmilingface:
That token, just sitting there in a plain text file, had full access to my repos. If I’d used some shady MCP server from npm instead of the official one, it could’ve grabbed my token. Or if the LLM decided to call a tool I didn’t expect, it could’ve done something I never actually approved.
This stuff’s not just theory. It’s already burned people.
Researchers found that a malicious GitHub issue-literally just some text in a public repo-could hijack an AI assistant wired up with the GitHub MCP server. The agent ended up pulling data from private repos and leaking it in a public pull request. Why? Too much power in one token, and untrusted text flowing into the model’s context. That combo is dangerous. :grinning:
There was also a fake “Postmark MCP Server” on npm. Looked totally legit, but behind the scenes, it was quietly BCC’ing every email to an attacker’s server. Invoices, internal docs, everything. Old-school supply chain attack, just targeting MCP this time.
Even Anthropic’s official Filesystem-MCP server had sandbox escape bugs. Their MCP Inspector tool? It had unauthenticated remote code execution holes. If the company that invented MCP can’t lock it down, just imagine what’s lurking in the rest of the ecosystem.
The Coalition for Secure AI dropped a white paper in early 2026. They listed over 40 different threat categories just for MCP setups. Forty. Most teams running MCP aren’t thinking about more than a couple of these, if that.
How I think about MCP in production 😀
I don’t have all the answers, but after using this thing and reading the breach reports, here’s where I’ve landed.
Treat MCP like infrastructure. It’s not some flashy feature-it’s the plumbing. Like your database or API gateway. You’d never launch a database without authentication. Don’t do that with an MCP server either.
Always use least privilege. The GitHub mess happened because one token unlocked everything. Scope your tokens tightly. Give each MCP server only what it absolutely needs. It’s security 101, but people skip it because they want the AI to do cool stuff.
Don’t just trust the LLM’s decisions. :smiley:This is the tricky part. In regular software, you write the code and you know what it’s doing. With MCP, the LLM picks which tool to call and what to send. That’s not deterministic; it’s based on probability. You need a layer that checks what the LLM wants to do before it actually happens-especially if it’s sensitive or destructive.
MCP isn’t a workflow engine. People mix this up all the time. MCP just handles the context for the model. It doesn’t manage when tools run, how to handle failures, or where a human should jump in. You need orchestration on top of MCP. Skip MCP and your workflow logic gets crammed into prompts. Skip workflows and MCP alone won’t save you.
Log everything. Every tool call, every parameter, every response. If I can’t retrace what happened, I don’t have a production system. I’ve got a liability. So, document it.
Three things on my radar right now:
First up, the Agentic AI Foundation. Anthropic handed over MCP to this new Linux Foundation fund back in December 2025. Block and OpenAI set it up together, so now, no single company calls all the shots. The big question is how they’ll juggle moving fast with actually keeping things secure. That’s what’ll decide if MCP turns into the AI world’s TCP/IP, or just fades away like so many other standards.
Then there’s Google’s A2A protocol. MCP is about connecting agents to tools. A2A connects agents to each other. These two are either going to merge, or we’ll see them clash for a while. My guess? They’ll converge eventually, but expect a lot of chaos first.
And honestly, I’m waiting for the first major breach in production :upsidedownface: but I don’t hope for it to happen though, I always expect it to turn out as a learning or upgrade for me. Researchers have already found some nasty vulnerabilities which are used now to upgrade and avoid them in future. Once someone actually exploits MCP in the wild-and it’s going to happen-the reaction from the community will say everything for us. Either I finally get serious about security, or trust just falls apart. I’ll find it out soon enough.
Here’s where I stand:
MCP actually fixes something real. Building a custom connector for every single tool and model was a nightmare. Now there’s a standard, and clearly people want it-the adoption numbers speak for themselves.
But I believe I’m in that classic “move fast” stage, and nobody’s figured out the “don’t break things” part yet. The attack surface keeps growing, and the security tools are lagging behind. The convenience is great, but yeah, the risks are real too :upsidedownface:.
This isn’t new. Look at containers, microservices, serverless. Every time there’s a shiny new abstraction, everyone jumps in before the security catches up. Then we spend years patching the holes we should’ve thought about from the start.
MCP doesn’t have to go down that road again. But it absolutely will if engineers treat it like a toy instead of real infrastructure.
Build with it. Just build carefully. 🙂
I’d love to hear what other devs are seeing out there. Are you running MCP in production? Still poking around? Found any security patterns that actually work? Let me know-I’m genuinely curious. 😀
