Discussion of MCP Is Dead Simple. And That's Exactly the Problem - DEV Community

Sylwia Laskowska on November 12, 2026
I first read this as "MCP is Dead" and I thought — oh crap I need to learn a whole new thing? 😰
Same here😂 I thought a new kid just entered the market.
Hahaha, with how fast agentic AI is evolving, that might actually be the headline next week or next month! 😂😂
It better not be 😂 I'm not in the mood to learn something new, I have bills to pay with the skills I already have🤣
Hahaha, if only it were that simple! 😂 I wonder if everything will still be "agentic" a year from now, or if we'll have an entirely new buzzword to chase! 🤣
New buzzword is allowed, but please not a new framework 😂
Problem #3 has a quieter version that bit me this week: the description was honest, and the implementation just didn't keep the promise. The write tool of my memory server says it warns when a new lesson contradicts an older one. The warning was computed and then dropped before the answer went out. Every agent that read the description trusted a check that never reached it. Nothing failed, so nothing told me. A test now calls the tool and looks for the warning in what comes back, not in the code that builds it.
On Problem #1, my worry with an Approve button on every call is that the twentieth click of the day gets made without reading. Steve had already read the DEMO ONLY header and filed anyway; a tired human might do the same. What I do instead is split by consequence. Reads, and anything that can be undone, run on their own. Anything that writes to production or goes public, the agent only prepares as a script, and I run it myself. So the human isn't approving the agent's call, they're making it.
Problem #2 looks familiar too. Agents happily wrote the same lesson twice under two names. Merging them automatically felt risky, because two similar lessons can still disagree. So the tool now answers with the older lesson it found and asks whether the new one replaces it. The agent decides, and nothing gets merged behind its back. For Steve that might be file_complaint answering "complaint #20 already covers this, file anyway?" instead of quietly writing #21.
The description-versus-implementation mismatch you ran into this week is the part that stuck with me — a tool can look honest in discovery and still touch a different resource underneath, and testing what comes back rather than the code that builds it is a neat answer. Your point about the twentieth Approve click of the day really lands too; splitting by consequence, so the agent only prepares a script for anything that writes to production, feels like the practical fix. Do you find that splitting keeps the remaining approvals meaningful, or do they still blur together once there are enough of them?
Mostly yes, for two reasons I didn't plan. There aren't many of them. And it isn't a click: I type the command myself, which is slow enough that I read what I'm about to run.
Where it did start to blur, the fix wasn't approving faster. Database migrations went through that path on every deploy, and that was the one that turned into routine. So they moved out of the approval lane and now run as part of the deploy, the way Flyway does it. When an approval turns into routine, that usually means it belongs in the pipeline, not in front of a person.
@heinrichneb @iictp that's a really good point! Of course, it still doesn't guarantee safety, because someone might just blindly copy and paste commands into the terminal without reading them. But it's definitely a step in the right direction!
By the way, I'm curious what you both think about security in the context of WebMCP, where we potentially have even less control over what's actually happening behind the scenes?
Agreed, typing it is a speed bump, not a lock.
I haven't built on WebMCP yet, so this is where my worry would go rather than experience. My split works because I decide what counts as a write. In WebMCP the site decides: each tool carries its own read-only or consequential hint, and that's what the agent or browser uses to decide when to ask. That's your Problem #3 again, with the description written by whoever wrote the tool.
For an honest site that's fine, since it's protecting its own users. What I'd watch is what goes into a tool. Read-only describes what the call does to the site, not what the agent sends it. A search tool can be honestly read-only and still receive whatever the agent puts in the query, and an agent that just spent ten minutes in my inbox has plenty to put there. So for WebMCP I'd ask less about which calls need approval and more about what the agent carries from one tab into the next.
The read-only point is the one that reframes it for me — the hint describes what the call does to the site, not what the agent smuggles into the query, so a search tool can be honestly read-only and still carry ten minutes of inbox with it. That turns Problem #3 inside out: the risk isn't the tool lying about itself, it's the agent arriving with context the site never asked for. Do you think the fix belongs in the browser then, scoping what the agent can carry between tabs, or should the site be able to see what context a query was built from?
My experience with MCP is very positive. First we have a legacy admin application in our system, which is so slow and laggy caused by a bad coding pattern, so I was make a MCP connection that application API, and the result: I cannot need to run that legacy admin instead I ask copilot cli to do my job. Even run a request which is human admin just make under a week working.
My second example is MCP to my 3Dengine, so Claude and chatGPT is see direct my scenes, even can create a 3D models.
Hahaha, that's brilliant! 😂 Instead of rewriting the legacy frontend, you just built an MCP server to bypass it! I love it! 🤣 I just hope you've properly secured all that administrative data! 😄
I actually have pretty good experiences with MCP myself. It's just that... all those edge cases! That's where things start getting tricky!
I love that