It’s talking about passing Python code in that would have a Python interpreter tool.
Even if you had guardrails setup that seems a little chancery, but hey this is the time of development evolution where we’re letting AI write code anyway, so why not give other people remote code execution access, because fuck it all.
I wrote about how to do it with Guix: https://200ok.ch/posts/2025-05-23_sandboxing_ai_tools:_how_g...
Since then, I have switched to using Bubblewrap: https://github.com/munen/dotfiles/blob/master/bin/bin/bubble...
Would be nice if there was a way for agents to work with MCPs as code, preview or debug the data flowing through them. At the moment it all seems not a mature enough solution and Id rather mount a Python sandbox with API keys to what it needs than connect an MCP tool on my own machine.
Started on working on an alternative protocol, which lets agents call native endpoints directly (HTTP/CLI/WebSocket) via “manuals” and “providers,” instead of spinning up a bespoke wrapper server: https://github.com/universal-tool-calling-protocol/python-ut...
even connects to MCP servers
if you take a look, would love your thoughts
The primary differentiator is that MCP includes endpoint discovery. You tell the LLM about the general location of the MCP tool, and it can figure out what capabilities that tool offers immediately. And when the tool updates, the LLM instantly re-learns the updated capability.
The rest of it is needlessly complicated (IMO) and could just be a bog standard HTTP API. And this is what every MCP server I've encountered so far actually does, I haven't seen anyone use the various SSE functionality and whatnot.
MCP v.01 (current) is both a step in the right direction (capability discovery) and an awkward misstep on what should have been the easy part (the API structure itself)
The actual thing that's different is that an OpenAPI spec is meant to be an exhaustive list of every endpoint and every parameter you could ever use. Whereas an MCP server, as a proxy to an API, tends to offer a curated set of tools and might even compose multiple API calls into a single tool.
Because the LLM can't "just connect" to an existing API endpoint. It can produce input parameters for an API call, but you still need to implement the calling code. Implementing calling code for every API you want to offer the LLM is at minimum very annoying and often error-prone.
MCP provides a consistent calling implementation that only needs to be written once.
Fails and i've no idea why, meanwhile python code works without issues but i can't use that one as it conflicts with existing dependencies in aider, see: https://pastebin.com/TNpMRsb9 (working code after 5 failed attempts)
I am never gonna bother with this again, it can be built as a simple rest API, why we even need this ugly protocol?
From my experience context7 just does not work, or at least does not help. I did plenty of experiments with it and that approach just does not go anywhere with the tools and models available today.
https://github.com/CharlieDigital/runjs
Lets the LLM safely generate and execute whatever code it needs. Bounded by statement count, memory limits, and runtime limits.
It has a built in secrets manager API (so generated code can make use of remote APIs) can, HTTP fetch analogue, JSONPath for JSON handling, and Polly for HTTP request resiliency.
In my experience, it’s actually quite the opposite.
By giving an LLM a set of tools, 30 in the Playwright case from the article, you’re essentially restricting what it can do.
In this sense, MCP is more of a guardrail/sandbox for an LLM, rather than a superpower (you must choose one of these Stripe commands!).
This is good for some cases, where you want your “agent”[1] to have exactly some subset of tools, similar to a line worker or specialist.
However it’s not so great when you’re using the LLM as a companion/pair programmer for some task, where you want its output to be truly unbounded.
[0]https://modelcontextprotocol.io/docs/getting-started/intro
[1]For these cases you probably shouldn’t use MCP, but instead define tools explicitly within one context.
I even use it to troubleshoot issues with my linux laptop that in the past I would totally have done myself, but can't be bothered. Which led to the most relatable AI moment I have encountered: "This is frustrating" - Claude Code thought, after 6 tries in a row to get my bluetooth headset working.
Also, there are MCP servers that allow running any command in your terminal, including apt install / brew install etc.
[1] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
That's the C in the protocol.
Sure you can add a session key to the swagger api and expose it that way so that llm can continue their conversation, but it's going to be a fragile integration at best.
A MCP tied to the conversation state abstract all that away, for better or worse.
Sure in some cases it might be overkill and letting the assistant write & execute plain code might be best. There are plenty of silly MCP servers out there.
yxhuvud•2h ago
EDIT: This has since been fixed in link, so it is outdated.
diggan•1h ago
There is a link to a previous post by the same author (within the first ten words even!), which contains the context you're looking for.
yxhuvud•1h ago
dkdcio•1h ago
reactordev•1h ago
It’s pretty well known by now what MCP stands for, unless you were referring to something else…
klez•1h ago
reactordev•1h ago
grim_io•1h ago
The first case doesn't matter at all if you already know what an MCP actually is.
At least for the task of understanding the article.
koakuma-chan•1h ago
Minecraft Coder Pack
tronreference•1h ago
https://www.youtube.com/watch?v=atmQjQjoZCQ
AznHisoka•38m ago
jeroenhd•1h ago
I have no idea what any of the abbreviations in stock market news mean and those stock market people won't know their CLIs from their APIs and LLMs, but that doesn't mean the articles are bad.
jahsome•1h ago
yxhuvud•1h ago
losvedir•51m ago
This is like complaining that HTTP or API isn't explained.
mattacular•40m ago
AznHisoka•39m ago
DrewADesign•13m ago
The balance isn’t really clear cut. On one hand, MCP isn’t ubiquitous like, say, DNS or ancient like BSD. On the other, technical audiences can be expected to look up terms that are new to them. The point of a headline is to offer a terse summary, not an explanation, and adding three full words makes it less useful. However, that summary isn’t particularly useful if readers don’t know what the hell you’re talking about, either, and using jargon nearly guarantees that.
I think it’s just one of those damned-if-you-do/don’t situations.
cgriswald•36m ago
Always consider your audience, but for most non-casual writing it’s a good default for a variety of reasons.