Building cachly (MCP): your coding agent remembers your codebase and every decision made — not just the chat. Follows you between editors, stays when someone leaves. I post what I learn shipping it.
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?
Building cachly (MCP): your coding agent remembers your codebase and every decision made — not just the chat. Follows you between editors, stays when someone leaves. I post what I learn shipping it.
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?
Thank you so much for this thoughtful comment! My MCP problems listed here are really just scratching the surface of everything that can go wrong. 😅
I find your point about human-in-the-loop and endless approvals particularly interesting. I catch myself doing exactly the same thing when working with agents! I might click "Approve" 20 times and be absolutely right to do so, but then comes that one time when I really should have clicked "Decline" instead.
And of course, documentation promising something that the implementation doesn't actually deliver is such a classic problem! All of this just shows how much work we still have ahead of us when it comes to building reliable agents!
Hahaha, you know what, I actually work with a Grzegorz, and let's just say… Steve might have been the safer choice! 🤣🤣 And yes, he promoted me to legendary status… as a legendary BAD developer! 😂 But hey, I'll take it! As they say, there's no such thing as bad publicity, as long as they spell your name right! 😆
Developer educator and advocate who still ships code. 15 years teaching developers at MongoDB, Heroku, Cisco, and Treehouse. Now writing about AI-assisted development, agent memory, and provenance.
I love that Steve turned a deliberately broken demonstration into an actual HR record. And then decided the same offense deserved a different severity on the next run.
One distinction I'd explore further is the boundary between the model's interpretation and the system's authority to act on that interpretation. Steve can reasonably identify suspicious code and recommend a complaint, but that doesn't necessarily mean his assessment should be sufficient to create a durable personnel record.
I'd be inclined to have the MCP tool accept a proposed finding with supporting evidence, while a separate policy determines whether that finding is eligible to become an official complaint. That policy could check whether the code is actually part of a production review, whether the issue has already been recorded, whether the agent has the appropriate authority, and whether the severity meets defined criteria. The model can help interpret the evidence without defining the consequences.
Of course, that doesn't automatically make the policy correct. We still have to test whether it handles the right cases, including ones nobody anticipated when the rules were written.
That's what I find interesting about MCP. Standardizing how tools are discovered and called is useful, but it doesn't establish what those calls should be permitted to accomplish. Steve has learned how to file paperwork. Now somebody needs to decide whether he should be running HR.
I really like this approach! What you're essentially proposing is an architecture where the LLM is responsible for reasoning and interpreting evidence, while a deterministic system is responsible for enforcing business rules and deciding what actions are actually permitted. And I think that's a very important distinction!
Because you're absolutely right: just because an agent can identify a problem doesn't mean it should automatically have the authority to act on it. Especially when those actions have real-world consequences. There's a huge difference between saying "this code looks suspicious" and creating an official HR record about someone's performance. Poor Sylwia! 😂
And I think this is actually a much broader problem with agentic systems, not just MCP. We're giving LLMs increasingly powerful tools and more autonomy, but we still need to figure out where that autonomy should end. The fact that an agent is technically capable of performing an action doesn't necessarily mean it should be allowed to perform it.
Of course, as you pointed out, deterministic rules aren't magically perfect either. Someone still has to define them, maintain them, and test all those edge cases. And that's where things get particularly interesting, because we can't possibly anticipate every scenario an autonomous agent might encounter.
I also think this brings us back to one of the fundamental challenges of building production-ready agents: the protocol itself is often the easy part. It's everything surrounding it, that makes the difference between a fun demo and a reliable system.
And I'm genuinely happy that Steve has once again managed to turn his questionable behavior into a serious discussion about security and agent architecture! 😂 Apparently, he's contributing to the community after all. Just not quite in the way he intended!
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 really enjoyed the idea of using MCP to help a grumpy senior developer like Steve work more effectively. 😹
And who knows, maybe there are a few real engineers like Steve out there too. 😹😹😹
MCP is simple, but that simplicity is exactly what makes it so useful.
Now that AI is becoming a normal part of how we build software, making tools and services easier for AI to understand and use feels like a very friendly design choice. Instead of teaching every AI client a completely different integration, MCP gives them a common language.
Also, thank you so much for the mention! 😸🙌
At the Necoz organization, we want contributions from everyone to be welcome, and I’d love for it to become a place where people can participate casually without feeling too much pressure.
I especially hope we can build a culture where members contribute to each other’s OSS projects, share ideas, open issues, and help each other improve things little by little. 🐈💚
Really fun article! Looking forward to seeing what Steve does next. 😹🚀
Thank you so much! 😻 And yes, that's exactly what I love about the idea behind Necoz! Someone actually contributed to one of my projects recently, just casually, with no pressure, and it was SUCH a great experience! 💚 So I'm fully on board with this vision. We really need more welcoming, safe spaces like that on the internet!
And of course, I completely agree about MCP. It's one of those things that's easy to learn but hard to master! Which, honestly, makes it even more interesting! 😄
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Great article! Exactly shows the huge gap between MCP demo and real‑world production usage. The human‑in‑the‑loop approval and idempotency are two points easily ignored when we play with MCP.🎉 Also, I’m finally seeing your posts pop up in my notifications!🤣
Thanks, Lingfeng! Honestly, other people's posts show up pretty randomly in my notifications too! 😂 And exactly! MCP looks so simple at first, and then people wonder why nothing works in production. 😜 By the way, are you guys using or building any MCP tools in your QA team?
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
For our company right now, we mainly use the mainstream, off-the-shelf MCP tools. If client companies have special requirements, we help them build custom MCP implementations. Man, clients have so many requests, and testing all of them keeps us busy, hahaha 😂
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Ahhh, that phrase is terrifying! In meetings now it’s always: “Can’t AI just do this?” Just now the product manager behind me thought frontend development was moving too slow, so he had AI rewrite the frontend code and shipped it directly, hahaha 😂
Aaaaa noooo! 😂😂 We see exactly the same thing! The first iteration is super easy, but then comes a ton of testing, debugging, and fixing things, and in the end we ship the code in pretty much the same amount of time as if we'd written it by hand. 😂
"80 lines for an agent, 150 for the tools" matches my experience, and the tutorials that make it look like a dark art don't help anyone. The hard part for me was never the protocol, it's tool descriptions: one vague sentence and the model calls the wrong tool with full confidence. Good luck in Berlin!
Thank you! 😄 And yes, exactly! The protocol itself is ridiculously simple, but one careless sentence in a tool description, one missing security check, and we're doomed! 😂
The Steve example makes the gap concrete in a way a checklist never would. Filing the same complaint twice, with a different severity each time, is the detail that stuck with me, because it shows the problem is not only access control. Even a permitted tool call can produce nonsense if there is no idempotency check and no stable rule for severity. I also liked the point that a tool description is not proof of what the implementation does. That is the part I would want tested first before exposing any MCP server beyond a local demo.
Exactly! That's why thorough testing is absolutely essential before exposing these tools to real-world usage. It's so easy to overlook things that seem harmless in a demo but can cause serious problems in production. And with agents making decisions on their own, things can go wrong in ways we didn't even anticipate! 😅
Founder & CEO, OBR Group. Leading innovation in business automation, AI, apps & financial systems. Empowering businesses to organize data & automate workflows with privacy-first digital ecosystems.
Education
Life has taught me a lot.
Pronouns
He/Him
Work
Founder & CEO, OBR Group. Leading innovation in AI, business automation & privacy-first systems.
The truth is that MCP didn't appeal to me — the idea of a tunnel and an external connector.?
Imagine they say: tools, references, and skills are not enough.??
Also, an internal engine must be added — it's not enough
And there is what's called LoRA, and SDXL, and FLUX, and the salad bowl
As if I've become an engineer for them, preparing the agent through hundreds of pieces, so it gives me impressive results and the salad bowl becomes complete, and through subscriptions and paid spaces,
The past period: I was working for ChatGPT like a home delivery connector — it just tells me go and download such and such and subscribe with such and such a site and do it, and I'm running around, and so on, and we try to see what comes out. I actually built a component and I'm still developing it and offering it for free to try
The truth is, when you subscribe with them with your money. And you put your project files and your articles and everything, and when your subscription ends, 99% of your work you can't access it. And I have spoken about this topic — that the idea is re-selling your data and your work back to you ..
I completely understand your frustration! And I think your experience really highlights how new and immature many of these technologies still are. We're constantly being promised that AI will make everything easier, faster, and more accessible, but in practice, getting things to actually work often requires a surprising amount of effort, experimentation, configuration, and troubleshooting.
I sometimes feel the same way when working with AI agents. Instead of having an assistant that takes work off my shoulders, I end up babysitting the agent, checking every step, fixing its mistakes, explaining the same things over and over again, and occasionally wondering whether doing the task myself would have been faster. 😂
And then there's the whole ecosystem of tools, integrations, subscriptions, and services that we're expected to navigate. It can definitely become overwhelming, especially when you just want to build something useful rather than spend half your time figuring out how to connect everything together.
I also think your point about ownership and access to your own work is important. We shouldn't have to worry about losing access to things we've created just because a subscription ends.
Hopefully, as these technologies mature, we'll get to a point where they genuinely reduce complexity instead of sometimes introducing even more of it. But right now, there's still a LOT of work ahead of us!
And kudos for building something yourself and making it available for others to try!
The distinction between describing a tool and enforcing its effects is the part that stands out here. A tool description saying a call is read-only does not make it so if the implementation can write, delete, or trigger an external action, and the model has no way to check that from the description alone.
How would approval be tiered in practice — for example, requiring human confirmation for any state-changing call, while also treating calls whose side effects are unclear or depend on runtime arguments as state-changing by default? That seems safer than relying on a naming convention or a flag in the schema, but it also risks approval fatigue if the boundary is drawn too broadly.
Is there a practical way to keep tool descriptions and implementations in sync over time, for example by generating the description from the implementation, or by testing that a tool labelled read-only really cannot mutate anything?
I completely agree, and I think this is a really important issue! It also raises an interesting architectural question: who should actually enforce these restrictions? The agent, the MCP client, or the server itself? Personally, I think we can't rely on the agent to enforce security boundaries. The server needs to be responsible for what it actually allows, regardless of what the tool description says or what the model decides to do.
As for approvals, Heinrich raised a very interesting point about approval fatigue in another comment here. If we're constantly asking humans to approve everything, sooner or later they'll just start clicking "Approve" without really thinking about it. So finding the right balance is another challenge.
I like the idea of generating tool descriptions from the implementation, but even that isn't a silver bullet. If we're using LLMs to generate those descriptions, they can misunderstand the code, overlook side effects, or confidently describe behavior that isn't actually guaranteed. And even with deterministic generation, we can only describe what we've explicitly captured in the implementation's metadata, not necessarily every possible runtime side effect.
So I think we need multiple layers here: clear contracts, proper permission enforcement, automated tests that verify actual behavior, and human approval where it genuinely matters. And importantly, those tests need to keep running as implementations evolve.
It's fascinating how something as seemingly simple as exposing a few tools to an AI agent opens up so many architectural and security questions! 😅
I am a professional DevOps Engineer with a demonstrated history of working in the internet industry. I am an avid Linux lover and supporter of the open-source movement philosophy.
Haha, hard to disagree! 😄 But MCP is still relatively new, and the specification is evolving rapidly, so I think it's especially important to raise awareness of these issues before people rush into production with it.
JavaScript enthusiast with a growing passion for Python. I love exploring the world of programming, experimenting with code, and discovering new ways to turn ideas into reality.
I test what ships and publish what I find, failures included.
Kubernetes, AWS and supply chain security.
Docker Captain, CNCF Ambassador, IBM Champion. 1.5M+ Docker Hub pulls.
Steve's rights have a concrete answer in the agent I run: it acts for a person, with that person's rights, and the MCP server checks identity and every argument on each call. The agent never decides what it may do.
In the benchmark's first signed run, three small models on CPU each got 18 planted instructions and acted on 6, 3 and 1 of them. Nothing reached the outside: the server stopped all 16 calls aimed there.
It still queued one email inside the company's domain, for an address nobody named. That's your Problem #1 in a real run. A boundary stops the leak, not the complaint, so a tool that acts on a person still needs the approval step you describe.
I write when an idea won't leave me alone 🧠 Building AI agents and the tools to build AI agents. Love connecting AI with other fields and yapping about all of them.
To your closing question, the thing I watch most in my servers is what a tool returns. Whatever get_employee_record hands back lands straight in the model's context, so I trim tool outputs to the fields the task asked for instead of passing the whole record through.
We're a place where coders share, stay up-to-date and grow their careers.
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_complaintanswering "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?
Thank you so much for this thoughtful comment! My MCP problems listed here are really just scratching the surface of everything that can go wrong. 😅
I find your point about human-in-the-loop and endless approvals particularly interesting. I catch myself doing exactly the same thing when working with agents! I might click "Approve" 20 times and be absolutely right to do so, but then comes that one time when I really should have clicked "Decline" instead.
And of course, documentation promising something that the implementation doesn't actually deliver is such a classic problem! All of this just shows how much work we still have ahead of us when it comes to building reliable agents!
I’m literally heartbroken over the agent’s name. Where is my beloved Grzegorz?! 🤣
Great article! I especially loved this line from Grzegorz (Steve… 🙄):
´´´21 │ Sylwia │ legendary │ Introduced multiple critical security flaws...´´´
Grzegorz (Steve) promoted you to legendary status… So you’re officially a legendary developer according to AI 🤣🤣
Hahaha, you know what, I actually work with a Grzegorz, and let's just say… Steve might have been the safer choice! 🤣🤣 And yes, he promoted me to legendary status… as a legendary BAD developer! 😂 But hey, I'll take it! As they say, there's no such thing as bad publicity, as long as they spell your name right! 😆
I love that Steve turned a deliberately broken demonstration into an actual HR record. And then decided the same offense deserved a different severity on the next run.
One distinction I'd explore further is the boundary between the model's interpretation and the system's authority to act on that interpretation. Steve can reasonably identify suspicious code and recommend a complaint, but that doesn't necessarily mean his assessment should be sufficient to create a durable personnel record.
I'd be inclined to have the MCP tool accept a proposed finding with supporting evidence, while a separate policy determines whether that finding is eligible to become an official complaint. That policy could check whether the code is actually part of a production review, whether the issue has already been recorded, whether the agent has the appropriate authority, and whether the severity meets defined criteria. The model can help interpret the evidence without defining the consequences.
Of course, that doesn't automatically make the policy correct. We still have to test whether it handles the right cases, including ones nobody anticipated when the rules were written.
That's what I find interesting about MCP. Standardizing how tools are discovered and called is useful, but it doesn't establish what those calls should be permitted to accomplish. Steve has learned how to file paperwork. Now somebody needs to decide whether he should be running HR.
I really like this approach! What you're essentially proposing is an architecture where the LLM is responsible for reasoning and interpreting evidence, while a deterministic system is responsible for enforcing business rules and deciding what actions are actually permitted. And I think that's a very important distinction!
Because you're absolutely right: just because an agent can identify a problem doesn't mean it should automatically have the authority to act on it. Especially when those actions have real-world consequences. There's a huge difference between saying "this code looks suspicious" and creating an official HR record about someone's performance. Poor Sylwia! 😂
And I think this is actually a much broader problem with agentic systems, not just MCP. We're giving LLMs increasingly powerful tools and more autonomy, but we still need to figure out where that autonomy should end. The fact that an agent is technically capable of performing an action doesn't necessarily mean it should be allowed to perform it.
Of course, as you pointed out, deterministic rules aren't magically perfect either. Someone still has to define them, maintain them, and test all those edge cases. And that's where things get particularly interesting, because we can't possibly anticipate every scenario an autonomous agent might encounter.
I also think this brings us back to one of the fundamental challenges of building production-ready agents: the protocol itself is often the easy part. It's everything surrounding it, that makes the difference between a fun demo and a reliable system.
And I'm genuinely happy that Steve has once again managed to turn his questionable behavior into a serious discussion about security and agent architecture! 😂 Apparently, he's contributing to the community after all. Just not quite in the way he intended!
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 really enjoyed the idea of using
MCPto help a grumpy senior developer like Steve work more effectively. 😹And who knows, maybe there are a few real engineers like Steve out there too. 😹😹😹
MCPis simple, but that simplicity is exactly what makes it so useful.Now that AI is becoming a normal part of how we build software, making tools and services easier for AI to understand and use feels like a very friendly design choice. Instead of teaching every AI client a completely different integration, MCP gives them a common language.
Also, thank you so much for the mention! 😸🙌
At the Necoz organization, we want contributions from everyone to be welcome, and I’d love for it to become a place where people can participate casually without feeling too much pressure.
I especially hope we can build a culture where members contribute to each other’s OSS projects, share ideas, open issues, and help each other improve things little by little. 🐈💚
Really fun article! Looking forward to seeing what Steve does next. 😹🚀
Thank you so much! 😻 And yes, that's exactly what I love about the idea behind Necoz! Someone actually contributed to one of my projects recently, just casually, with no pressure, and it was SUCH a great experience! 💚 So I'm fully on board with this vision. We really need more welcoming, safe spaces like that on the internet!
And of course, I completely agree about MCP. It's one of those things that's easy to learn but hard to master! Which, honestly, makes it even more interesting! 😄
I first read this as "MCP is Dead" and I thought — oh crap I need to learn a whole new thing? 😰
Hahaha, with how fast agentic AI is evolving, that might actually be the headline next week or next month! 😂😂
Great article! Exactly shows the huge gap between MCP demo and real‑world production usage. The human‑in‑the‑loop approval and idempotency are two points easily ignored when we play with MCP.🎉 Also, I’m finally seeing your posts pop up in my notifications!🤣
Thanks, Lingfeng! Honestly, other people's posts show up pretty randomly in my notifications too! 😂 And exactly! MCP looks so simple at first, and then people wonder why nothing works in production. 😜 By the way, are you guys using or building any MCP tools in your QA team?
For our company right now, we mainly use the mainstream, off-the-shelf MCP tools. If client companies have special requirements, we help them build custom MCP implementations. Man, clients have so many requests, and testing all of them keeps us busy, hahaha 😂
Hahaha, I can imagine! 😂 And I bet everything needs to be done ASAP, because "we have AI now, right?" 😆
Ahhh, that phrase is terrifying! In meetings now it’s always: “Can’t AI just do this?” Just now the product manager behind me thought frontend development was moving too slow, so he had AI rewrite the frontend code and shipped it directly, hahaha 😂
Aaaaa noooo! 😂😂 We see exactly the same thing! The first iteration is super easy, but then comes a ton of testing, debugging, and fixing things, and in the end we ship the code in pretty much the same amount of time as if we'd written it by hand. 😂
"80 lines for an agent, 150 for the tools" matches my experience, and the tutorials that make it look like a dark art don't help anyone. The hard part for me was never the protocol, it's tool descriptions: one vague sentence and the model calls the wrong tool with full confidence. Good luck in Berlin!
Thank you! 😄 And yes, exactly! The protocol itself is ridiculously simple, but one careless sentence in a tool description, one missing security check, and we're doomed! 😂
The Steve example makes the gap concrete in a way a checklist never would. Filing the same complaint twice, with a different severity each time, is the detail that stuck with me, because it shows the problem is not only access control. Even a permitted tool call can produce nonsense if there is no idempotency check and no stable rule for severity. I also liked the point that a tool description is not proof of what the implementation does. That is the part I would want tested first before exposing any MCP server beyond a local demo.
Exactly! That's why thorough testing is absolutely essential before exposing these tools to real-world usage. It's so easy to overlook things that seem harmless in a demo but can cause serious problems in production. And with agents making decisions on their own, things can go wrong in ways we didn't even anticipate! 😅
The truth is that MCP didn't appeal to me — the idea of a tunnel and an external connector.?
Imagine they say: tools, references, and skills are not enough.??
Also, an internal engine must be added — it's not enough
And there is what's called LoRA, and SDXL, and FLUX, and the salad bowl
As if I've become an engineer for them, preparing the agent through hundreds of pieces, so it gives me impressive results and the salad bowl becomes complete, and through subscriptions and paid spaces,
The past period: I was working for ChatGPT like a home delivery connector — it just tells me go and download such and such and subscribe with such and such a site and do it, and I'm running around, and so on, and we try to see what comes out. I actually built a component and I'm still developing it and offering it for free to try
The truth is, when you subscribe with them with your money. And you put your project files and your articles and everything, and when your subscription ends, 99% of your work you can't access it. And I have spoken about this topic — that the idea is re-selling your data and your work back to you ..
I completely understand your frustration! And I think your experience really highlights how new and immature many of these technologies still are. We're constantly being promised that AI will make everything easier, faster, and more accessible, but in practice, getting things to actually work often requires a surprising amount of effort, experimentation, configuration, and troubleshooting.
I sometimes feel the same way when working with AI agents. Instead of having an assistant that takes work off my shoulders, I end up babysitting the agent, checking every step, fixing its mistakes, explaining the same things over and over again, and occasionally wondering whether doing the task myself would have been faster. 😂
And then there's the whole ecosystem of tools, integrations, subscriptions, and services that we're expected to navigate. It can definitely become overwhelming, especially when you just want to build something useful rather than spend half your time figuring out how to connect everything together.
I also think your point about ownership and access to your own work is important. We shouldn't have to worry about losing access to things we've created just because a subscription ends.
Hopefully, as these technologies mature, we'll get to a point where they genuinely reduce complexity instead of sometimes introducing even more of it. But right now, there's still a LOT of work ahead of us!
And kudos for building something yourself and making it available for others to try!
The distinction between describing a tool and enforcing its effects is the part that stands out here. A tool description saying a call is read-only does not make it so if the implementation can write, delete, or trigger an external action, and the model has no way to check that from the description alone.
How would approval be tiered in practice — for example, requiring human confirmation for any state-changing call, while also treating calls whose side effects are unclear or depend on runtime arguments as state-changing by default? That seems safer than relying on a naming convention or a flag in the schema, but it also risks approval fatigue if the boundary is drawn too broadly.
Is there a practical way to keep tool descriptions and implementations in sync over time, for example by generating the description from the implementation, or by testing that a tool labelled read-only really cannot mutate anything?
I completely agree, and I think this is a really important issue! It also raises an interesting architectural question: who should actually enforce these restrictions? The agent, the MCP client, or the server itself? Personally, I think we can't rely on the agent to enforce security boundaries. The server needs to be responsible for what it actually allows, regardless of what the tool description says or what the model decides to do.
As for approvals, Heinrich raised a very interesting point about approval fatigue in another comment here. If we're constantly asking humans to approve everything, sooner or later they'll just start clicking "Approve" without really thinking about it. So finding the right balance is another challenge.
I like the idea of generating tool descriptions from the implementation, but even that isn't a silver bullet. If we're using LLMs to generate those descriptions, they can misunderstand the code, overlook side effects, or confidently describe behavior that isn't actually guaranteed. And even with deterministic generation, we can only describe what we've explicitly captured in the implementation's metadata, not necessarily every possible runtime side effect.
So I think we need multiple layers here: clear contracts, proper permission enforcement, automated tests that verify actual behavior, and human approval where it genuinely matters. And importantly, those tests need to keep running as implementations evolve.
It's fascinating how something as seemingly simple as exposing a few tools to an AI agent opens up so many architectural and security questions! 😅
agree but also keep in mind that all software now is easy to build and hard to make safe so mcp servers are just no exception
Haha, hard to disagree! 😄 But MCP is still relatively new, and the specification is evolving rapidly, so I think it's especially important to raise awareness of these issues before people rush into production with it.
🥰🤩
😍😍
Steve's rights have a concrete answer in the agent I run: it acts for a person, with that person's rights, and the MCP server checks identity and every argument on each call. The agent never decides what it may do.
In the benchmark's first signed run, three small models on CPU each got 18 planted instructions and acted on 6, 3 and 1 of them. Nothing reached the outside: the server stopped all 16 calls aimed there.
It still queued one email inside the company's domain, for an address nobody named. That's your Problem #1 in a real run. A boundary stops the leak, not the complaint, so a tool that acts on a person still needs the approval step you describe.
The run
To your closing question, the thing I watch most in my servers is what a tool returns. Whatever get_employee_record hands back lands straight in the model's context, so I trim tool outputs to the fields the task asked for instead of passing the whole record through.