Rendered at 08:36:03 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rutierut 57 minutes ago [-]
In this thread I’m seeing a couple of the typical skill arguments. Skills don’t pollute the context window and, skills are more flexible and composable.
In this specific post the SQL example gets around this by being super low-level, inherently composable, and low context consumption itself. I’m not sure this works for everyone.
Looking at the Linear MCP for example, they basically just want to expose an API surface and provide 32 MCP tools as a result of that. My agents do run into composability problems here all the time and fall back to the tool they included which allows you to run arbitrary GraphQL. This takes a couple tries usually. I don’t really know what the sensible alternative to this is.
Cloudflare switched to “code mode” which basically provides 2 MCP tools: search and execute. Both take a TS arrow function, the first allows you to programmatically search a TS api spec, the second to compose and run the methods in that spec.
I think this is a very interesting approach, and certainly better than providing the ~1000 actions as MCP tools but I feel the jury is still out on exactly how well this pans out.
Eldodi 15 minutes ago [-]
MCP context bloat is a solved problem since at least February. Both OpenAI and Anthropic support Client-side MCP tool search, which makes MCP context loading as efficient as the Skills one (progressive discovery).
Code mode is great but not needed anymore in 95% of use-cases.
troupo 13 minutes ago [-]
> Skills don’t pollute the context window
Of course they do. Do you really think that there's a magical bag of holding for the potentially infinite amount of skills?
ai_critic 2 hours ago [-]
It is amazing that folks getting paid several hundred thousand dollars a year...reinvented RPC-over-HTTP/JSON. You too, fellow web developers, are smart enough to work at Anthropic.
I would love to see a proper engineering post-mortem for how this happened.
firasd 2 hours ago [-]
I wonder if part of it was the bias of how the chat apps work with the streaming maybe they use SSE
But I wouldn't discount how uphill it was to probably even argue for something like MCP cause the labs still very scientist-driven and focused on solving everything in token space. The idea that tool use could be super transformative probably wasn't obvious from inside before Claude Code
hahahaa 2 hours ago [-]
I had to double take and say "I coulda dun that!!"
The "just use a CLI" crowd is implicitly assuming:
1) You're a developer 2) On a laptop 3) With a shell open inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project
That's maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
eddythompson80 3 hours ago [-]
I think part of the “just use a CLI” crowd might also be building similar agents as ChatGPT and Claude.ai web interface. I know at least 4 teams doing that in one company.
All those teams, including ChatGPT and Claude.ai, have figured out that you will eventually need to give your agent a small sandbox Linux environment to unlock the same level of “intelligence“ those coding harness exhibit. Stitching together the results of a cli command through scripting or coding gives the agent a ton more flexibility in what it can do as it can utilize its text generation capability into executable logic. toolcalls mostly work for actions rather than complex and novel problem solving. You are making the agent represent a programming control flow through toolcalls while carrying the context between them in a lossy, nondeterministic, wasteful, slow and rigid way.
It’s one thing if you want to artificially limit that agent to a very strict set of available APIs that it must use in a specific way while transferring context between them through the LLM and you don’t want to incur the cost of the extra sandbox compute. But coding harnesses have demonstrated that letting the agent write a small shell or python script can let the agents solve problems that you haven’t even really anticipated in your toolcall approach or that tool calls make prohibitively expensive or not even possible.
But also the token cost tends to dwarf the sandbox compute cost, so why not pay the $0.05/hour to have a sandbox where the agent can run free when you are already paying orders of magnitude more for the tokens
firasd 3 hours ago [-]
Hmm yeah but I think at some point ad-hoc code becomes a signal that something is wrong. eg. If your LLM is continuously writing python to join customers to orders at some point that's a signal that customers_aggregate('topspenders') needs to be a thing like a deterministic API call
eddythompson80 50 minutes ago [-]
Every arbitrary REPL or program written by an LLM to solve a problem can absolutely become a toolcall that does the same thing. Are you planning to provide hundreds, or thousands, of tools to cover all the possibilities an agent might consider AND have the foresight to include all of them?
I think that’s a future plenty of people see or want. But simpler and composable Linux commands are far more flexible than pre-defined Windows or Mac “Settings App”. The barrier to entry for the former was knowledge and familiarity, while the latter optimizes for simpler user experience. Agents don’t have to worry about knowledge or familiarity the way users do.
Ok, now you have customers_aggregate(‘topspenders’), but the prompt to the agent was “Get me the top spenders that are public companies and show me ones that increase their spend proportionally to their revenue increase and ones that don’t”. If the agent had access to the needed APIs (or CLIs) for your data and a finance API provider, it can generate a script that crunches down the top 10 or 10,000 for all that data. You could obviously come up with a toolcall that encapsulates that or rely on multiple toolcalls and on the LLM to fill in data correctly between them then do the math using inference.
Edit: even if you look at that customers_aggregate(‘topspenders’) tool, you wouldn’t have needed that if the agent could execute a SQL query. It can also express anything the data can do. You obviously trade the control and correctness guarantees you can give for a `customers_aggregate(‘topspenders’)` vs a potentially wrong SQL query generated by the LLM with the infinite flexibility of a SQL query to be able to express far more than you could in a customers_aggregate call.
drdexebtjl 3 hours ago [-]
At that point you would add a `your-service-cli list-customers --order-by=spent` command, which would also be useful to humans and scripts, as opposed to an MCP tool call, which is only ergonomic to models.
firasd 3 hours ago [-]
Right we can quibble about the wire protocol but the point remains that the arbitrary REPL becomes suboptimal as a solution when there’s not a deterministic endpoint. So ‘scripting’ is not really what we are looking for; we just want the final data output and scripting is fine when it’s a one off
1 hours ago [-]
drdexebtjl 2 hours ago [-]
They’re not the same thing under a different wire protocol!
An MCP tool call that returns the top N spenders puts the result in the agent’s context window.
A CLI tool call on the other hand… The agent can pipe their results into other completely unrelated CLI tools. It can write a loop that calls multiple tools.
These things are not possible with MCP but are trivial with CLIs.
I don't even need to read that to know they're re-inventing PowerShell now.
Edit: I read it. Yep.
We have text interfaces refined by humans for decades and there's an endless sea of training data for them, but they imagine these amateur-hour homegrown solutions will ever outdo an agent with shell access?
lukebuehler 2 hours ago [-]
Fully agree that in the end sandboxes are required to get frontier performance out of the models.
But you can have both: rund the agent outside the vm/sandbox and orchestrate work on it, either directly via shell calls or kicking off an ephemeral subagent on the box.
This makes the agent and session that runs outside the vm more durable and opens new orchestration pattern.
The "CLI crowd" is also primarily using LLMs on their own computer. Where they have their CLI tools.
This doesn't cover the case when you're talking to an LLM from web, or via Slack or Linear, etc. There, you will want MCP so the LLM can use services on your behalf as you. That's portability.
drdexebtjl 3 hours ago [-]
Why can’t the LLM you’re talking to on the web have access to your CLI tools?
When you talk to an LLM on the web, the harnesses spin up a fresh environment (I would hope it’s a VM…) so that the LLM can do stuff like run arbitrary Python and Bash scripts to complete the task you asked it for.
There’s no reason why you shouldn’t be able to customize this environment to add whatever CLI tools and credentials you need for the agent to act on your behalf.
The UX would be exactly the same.
drdexebtjl 3 hours ago [-]
I don’t think the “just use a CLI” crowd really are assuming you’re a developer in a coding harness.
All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code.
Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses.
So why not augment their repertoire of CLI tools instead of a completely new protocol?
Eldodi 19 minutes ago [-]
- CLI tools don't have standardized auth, nor do they have granular tool permissions. MCP does
- CLI tools need to access your secrets in your .env. With MCP the model never sees the secrets and refresh tokens.
- CLI tools don't have auditing and telemetry. MCP provides all this for free.
- CLI tools imply full bash access, a nightmare in terms of security and very costly if you have to spin up a machine for every request for billions of users.
- etc
firasd 3 hours ago [-]
I guess if the agent is strongly trained to reach for the container then maybe
But let’s take my MCP clock for example if you ask ChatGPT what’s the time in Tokyo it’s not even gonna think of booting up the code interpreter. It’s gonna just do web search and give you the wrong time (I just tried it and there may be an OpenAI built in widget it pops up now—but again that’s a specific tool call with an iframe output not arbitrary code)
drdexebtjl 3 hours ago [-]
Because there’s probably a tool call for web search, and a tool call for arbitrary code. There’s no discovery for the CLI tools it has available unless it has already chosen to run arbitrary code.
The point is that even web search should be a CLI tool, and all ChatGPT would know to do other than talk to you is how interact with a shell.
Then if you ask it what’s the time in Tokyo, it would likely reach for the POSIX date command, instead of web search, because both would be equally visible.
firasd 2 hours ago [-]
The amusing thing here though is that if we do high frequency container usage like you’re suggesting eventually we’re gonna reimplement MCP right. Cause then it’s like npx thiscommand —help (aka MCP tools/list) and then OAuth and all that ..
drdexebtjl 2 hours ago [-]
In the same vein, if we do evolve MCP to support composable tool calls and more tools, eventually we’ll reimplement Bash.
The difference is that we already have Bash :)
kristjansson 3 hours ago [-]
Also:
your messages causing your LLM (harness) to run CLIs on your computer? charming, thrilling, great fun.
other people’s messages causing your LLM to run CLIs on your (cloud) computer? terrifying, awful, sickening, no fun at all
floren 2 hours ago [-]
The LLM can't tell the difference between your messages and theirs, however many times you say "No mistakes"
panghy 1 hours ago [-]
[dead]
panghy 2 hours ago [-]
[flagged]
drdexebtjl 3 hours ago [-]
In retrospect, stateful MCP was clearly wrong.
This essentially makes MCP just another REST API endpoint, and lets you use the same infrastructure you already have set up for REST APIs (like load balancers, API gateways, progressive rollouts, etc).
bloppe 3 hours ago [-]
MCP is basically just:
1. a REST-like API
2. with a spec (OpenAPI, introspection, etc.)
3. with harness-level authz (the ability to allow / deny specific methods in the harness)
The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.
So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.
panghy 2 hours ago [-]
Honestly MCP is geared mainly for the non-technical folks who don't understand a thing about REST or OpenAPI (otherwise, of course folks can just ask models to search/parse/code/parse and get things done -- don't need to ask for an MCP endpoint at all). Models also do a lot better with tool calls than asking them to string together instrospection, web-search, curl, etc. (that's a lot of tokens) rather than having the endpoint expose a single URL that the model can take, auth, understand, and use.
I maintain https://endara.ai and you can very quickly introduce a ton of capabilities for Claude/Cursor/ChatGPT by configuring all the stuff you use in a single place (and slicing them with profiles if needed).
alooPotato 48 minutes ago [-]
The user experience for a rest api and for mcp can be the same. For MCP, you have to give the mcp server url. For REST, you could provide a url to the openapi spec. The open API spec has everything you'd need - oauth url + all the endpoints and params.
Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the Gmail plugin".
9dev 2 hours ago [-]
The spec is more than just an OpenAPI scheme; it’s a strict wire format with shared semantics for a huge range of features.
bloppe 2 hours ago [-]
Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?
9dev 2 hours ago [-]
Kind of--I'm saying that RESTful APIs are just an abstract vocabulary to describe state transfer operations, whereas MCP describes a concrete set of such operations. REST sits on top of the HTTP protocol layer, MCP sits on top of REST (if we accept how the meaning of REST has been butchered, but you know what I mean.)
This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.
bloppe 27 minutes ago [-]
See my point #2. There are already standards to describe APIs.
This is easy to see when you think in terms of a developer. The natural way to adapt an existing REST API into an MCP server while keeping the two synchronized is to simply write a basic translation tool that takes your OpenAPI spec and turns it into an MCP manifest, mapping each HTTP endpoint to an MCP method, and copying over all the request / response type signatures and descriptions for everything. Then, all of the sudden, it hits you: there is no need for this translation layer.
drdexebtjl 2 hours ago [-]
I think OpenAPI does all you mentioned in your comment too. Maybe MCP is more strict, in the sense that it requires natural-language descriptions, which are optional in OpenAPI, but I don’t see the distinction.
There are multiple products that turn OpenAPI schemas into front-ends nowadays.
speedgoose 1 hours ago [-]
Isn’t that the case? Aren’t REST people still debating about what makes a true beautiful REST API?
bloppe 14 minutes ago [-]
When I say REST, I basically mean HTTP/JSON. I know. Shame on me.
But there's a pretty large body of RFCs that define what makes a good REST API. For instance POST should create things, PUT should re-define them, PATCH should incrementally update them, GET must be side-effect-free, etc. And there's a ton of standard HTTP headers. Pair it with OpenAPI and the whole thing is self-documenting. You can achieve the same effect with gRPC + reflection, or GraphQL + reflection, and there's plenty of mature tooling and interoperability for each system.
By comparison, MCP actually has relatively few conventions. LLMs are very familiar with REST and OpenAPI already. Just use that.
dymk 2 hours ago [-]
The wire format certainly isn’t strict
pjmlp 3 hours ago [-]
Something that anyone doing distributed systems knows after a few scars, stateless servers are always better, and stateful only if there is no way around it.
I learnt this with Sun RPC and the whole "The network is the computer".
Somehow this keeps having to be relearnt.
shermantanktop 2 hours ago [-]
I keep encountering mistakes by people who are convinced that agentic interactions are nothing new, that all the decades of hard-won lessons about service API design are 100% relevant and nothing more is needed, that agents can be relegated to the role of just-another-caller and left to the dismal domain of client developers.
It’s not true. It’s not totally untrue, but don’t hide your head in the sand.
tibbe 2 hours ago [-]
You didn't provide any arguments to support your claim. Calling people names isn't going to convince anyone.
wongarsu 31 minutes ago [-]
If agents are "like humans" (whatever we mean by that), then shouldn't all the lessons we learned over the decades on how to build APIs for direct and indirect human consumption be extremely relevant?
zeafoamrun 32 minutes ago [-]
I came here to ask why it was ever stateful?
3 hours ago [-]
cheema33 2 hours ago [-]
My main issue with MCP servers has been context bloat. Skills have progressive disclosure, and allow me to turn off auto invocation with something like this in the SKILL.md file:
disable-model-invocation: true
Most MCP servers still bloat up my context even when I am not using them at all. Why can't they be configured to allow me to keep them out unless I really need to use them?
SyneRyder 1 hours ago [-]
> Most MCP servers still bloat up my context...
Modern harnesses don't do that, MCP is also progressive disclosure now. MCP tool descriptions aren't included anymore, and have to be found via tool_search. I actually find that to be a regression. Sometimes the models will start coding a python script for something that is already available via a pre-compiled MCP tool call.
In Claude Code you can enable / disable MCP servers at will, just use the /mcp command. You can also lock down permissions in claude -p headless mode to individual tools within an MCP server (eg maybe you only want to allow the reading tools, and none of the write-enabled tools for your automated session).
hahahaa 2 hours ago [-]
Yes run a side agent to evaluate if they are needed.
I am guessing keeping them all in every request is cache efficient though.
Foobar8568 2 hours ago [-]
I still don't get MCP. Most likely because I didn't really check but the first feeling is creating a problem to solve a problem that doesn't exist in the first place.
mmasu 2 hours ago [-]
In enterprise MCP allows users to access resources that could either be unsafe or impractical to consume via API or CLI. It is a powerful pattern, supported by virtually all clients (Cursor, Claude Code, Codex, whatever) and easily implemented in custom harnesses. If you don’t need it you don’t, but it has many useful applications. Stateless will make it a lot more practical to expand applications.
DarkNova6 11 minutes ago [-]
I don't get it. I thought the advantage is that you have a client as a library with integrated auth & other tech stuff handled so you can just focus on using the API? Because otherwise you could just use REST with basic endpoint code.
cheeze 44 minutes ago [-]
What is an example of something that is unsafe to consume via API or CLI?
Isn't MCP _an API_?
qalmakka 2 hours ago [-]
It's mostly useful to allow sandboxed AI apps to access external functionality. If an LLM has any kind of access to a CLI then it stops making sense, because LLMs are very good at CLI and almost always they use less tokens doing that. Plus, you human can easily use a cli tool, while mcp is just for agents.
bob1029 1 hours ago [-]
MCP is most useful for extending agent loops with external tools. If you are building your own loops from scratch and don't intend to support external tools, MCP doesn't add anything.
hahahaa 2 hours ago [-]
Well for a non-coding (no CLI tooling) flow it means you don't need a sandbox and it provides a plugin architecture.
kmarc 2 hours ago [-]
I my mind it's mostly corporate socio-political. Your management have no idea what a (rest) API is, but they saw MCP in countless LinkedIn slop and therefore you are allowed to work on one / use an upstream solution to connect the agents to your 23 year old monolithic unmaintained homebrew CRM that only runs because overcompensated Frank is still willing to pet it manually.
cush 3 hours ago [-]
But is it composable like cli? The main issue to be with MCP is the entire response ends up in the context window. Whereas a decent harness and agent is usually going to pipe together and filter many tools in one long command without spending all the extra tokens.
nextaccountic 9 minutes ago [-]
That's a harness concern, not a protocol concern. For example, maki [0] allows that automatically for all tools
> code_execution tool - uses monty to run an interpreter that has all other tools available as async functions. Maki uses it to filter / summarize / transform / pipe data to other tools as input, without it ever reaching and polluting the context window. Sandbox limited by time & memory.
Failing that, you can just disable native MCP in your harness and have your agent use a CLI tool that calls MCP, like mcp-cli [1], and then the agent can use regular unix pipes to filter or transform the output. Here, rather than raw grep or sed (which are line oriented), the agent would probably use things like jq.
In our startup, we build harness that allows people to call endpoints like the ones that MCP supports. we looked it as 2 class of problems. One is sources like databases where the protocol is not http/json/rpc. Here we support MCP based calling. then there are ones where the protocol is just http/json/rpc - say calling shopify or linear or others. Now the harness itself comes with a generic http execution engine. So if you know the endpoint, auth and operation - the harness converts this into a yaml structure for internal purpose and directly calls the endpoint. all info that LLM needs like how the endpoints are, what can be passed and how to check response etc., is all english defined and stored in yaml. Now the harness uses this info to expose these to LLM and when LLM wants to makes a tool call that needs to call the http endpoint the http engine in the harness executes it on behalf of it and gives response back to LLM.
this way every server dont have to expose and maintain an MCP server to expose them to LLM. allow us to connect to any endpoint and teams dont have to maintain and scale one more info.
Not sure whats the downside of this approach is but its serving us well so far.
bkaraaslan 2 hours ago [-]
can postgREST be helpful for this? Clickhouse also has an http endpoint to send queries
mailmrg 1 hours ago [-]
we havent done postgres as endppoint. we were worried abt performance but may be we will consider. this also avoid the problem of running curl in shell (no shell access is given) and validations are done before its being sent - like call parameters, check for injections with standard libraries etc., so we dont have to worry abt the quality of existing MCP servers.
2 hours ago [-]
2 hours ago [-]
SoKamil 1 hours ago [-]
> and then became somewhat eclipsed by Skills (another Anthropic invention)
I can find articles and Reddit posts about Dia Browser’s Skills from July 2025.
luciana1u 3 hours ago [-]
we invented a stateful protocol, discovered state is hard to scale, stripped it out, and arrived at "just send a POST request." the REST crowd has been smugly waiting for this moment for 20 years.
ameshkov 5 hours ago [-]
> I couldn’t find a great CLI tool for interactively probing an MCP server
What about mcp-inspector? It’s a nice tool, can be used interactively, can be used as a CLI.
Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.
hobofan 3 hours ago [-]
I would generally agree, but a word of caution for anyone trying it out from this thread: Try the latest pre 2.x version. The 2.0.0 that was released last week is highly broken even for some of the most common connection scenarios.
garazy 2 hours ago [-]
Hi Simon and HN checkout https://rmcp.dev - it's part of BuiltWith's MCP discovery and lets you sniff around all of the MCP servers (remote at least) that we've discovered - allowing you to connect to them etc. and see what they do. Thought it might be relevant vis your mcp-explorer.
CSDude 2 hours ago [-]
I createad an MCP server for my company I worked at for almost a year now with all Dynamic Client Registration (DCR). We just ignored the state as with most other MCPs wre doing it, just used it for logging.
tosh 4 hours ago [-]
I'm glad MCP is getting simpler
a few months ago I tried to implement an MCP server from scratch in python (instead of using the existing reference implementation) and I could not get it to work reliably across clients
CharlieDigital 4 hours ago [-]
Stateless MCP was already possible before this and made sense for whole classes of use cases where it helps to have a remote fleet of servers.
MCP is going to be a foundational piece of enterprise agent infra.
hchja 4 hours ago [-]
MCP was much more important when agents weren’t able to accurately make tool calls.
Nowadays, these agents are more capable and I think you can replace MCP (which is a pain on macOS), with simple CLI tools and expose them to agents via system prompt, skills, or other API documentation.
spike021 3 hours ago [-]
How well does that work in enterprise setups?
charcircuit 3 hours ago [-]
Well assuming a browser is able to access whatever enterprise thing, the LLM can emulate being one using apps like curl.
rixed 2 hours ago [-]
why is MCP a pain in Macos?
pianopatrick 4 hours ago [-]
Maybe someone could set up a CLI tool for agents such that you can give them a shell but they use this CLI tool instead of raw curl.
Like a tool where the AI can only call out to certain APIs based on a config file the agent cannot change.
That way you can leverage all the shell knowledge agents already have while still limiting what network calls they can make, and you wouldn't have to set up a server to use an agent.
nickstinemates 4 hours ago [-]
This is basically what Swamp is[1]. You give an agent a typed interface to extend itself (or use other peoples extensions) into the systems you need to fulfill your request. Think of it like on-demand tool calls. Then it records everything that happens in the swamp. The swamp can be single machine, multi-machine, or centralized with your co-workers.
As a result, everything compounds. The work I do doesn't need to be re-derived by the work you do. Typed models keep everything repeatable and deterministic. Huge reduction in token spend and huge increase in speed.
Maybe. I'm just spitballing but as I've been thinking about this, maybe just like a set of shell scripts.
The idea could be that the agent runs as a unix user. That user has execute access to these scripts but not read or write access.
So the agent can only do what those scripts allow, the scripts present an API. You could let agents call the scripts with -h to get instructions, and just put some text into context saying like "to access helper scripts call ./showHelp".
In this specific post the SQL example gets around this by being super low-level, inherently composable, and low context consumption itself. I’m not sure this works for everyone.
Looking at the Linear MCP for example, they basically just want to expose an API surface and provide 32 MCP tools as a result of that. My agents do run into composability problems here all the time and fall back to the tool they included which allows you to run arbitrary GraphQL. This takes a couple tries usually. I don’t really know what the sensible alternative to this is.
Cloudflare switched to “code mode” which basically provides 2 MCP tools: search and execute. Both take a TS arrow function, the first allows you to programmatically search a TS api spec, the second to compose and run the methods in that spec.
I think this is a very interesting approach, and certainly better than providing the ~1000 actions as MCP tools but I feel the jury is still out on exactly how well this pans out.
Code mode is great but not needed anymore in 95% of use-cases.
Of course they do. Do you really think that there's a magical bag of holding for the potentially infinite amount of skills?
I would love to see a proper engineering post-mortem for how this happened.
But I wouldn't discount how uphill it was to probably even argue for something like MCP cause the labs still very scientist-driven and focused on solving everything in token space. The idea that tool use could be super transformative probably wasn't obvious from inside before Claude Code
1) You're a developer 2) On a laptop 3) With a shell open inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project
That's maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
All those teams, including ChatGPT and Claude.ai, have figured out that you will eventually need to give your agent a small sandbox Linux environment to unlock the same level of “intelligence“ those coding harness exhibit. Stitching together the results of a cli command through scripting or coding gives the agent a ton more flexibility in what it can do as it can utilize its text generation capability into executable logic. toolcalls mostly work for actions rather than complex and novel problem solving. You are making the agent represent a programming control flow through toolcalls while carrying the context between them in a lossy, nondeterministic, wasteful, slow and rigid way.
It’s one thing if you want to artificially limit that agent to a very strict set of available APIs that it must use in a specific way while transferring context between them through the LLM and you don’t want to incur the cost of the extra sandbox compute. But coding harnesses have demonstrated that letting the agent write a small shell or python script can let the agents solve problems that you haven’t even really anticipated in your toolcall approach or that tool calls make prohibitively expensive or not even possible.
But also the token cost tends to dwarf the sandbox compute cost, so why not pay the $0.05/hour to have a sandbox where the agent can run free when you are already paying orders of magnitude more for the tokens
I think that’s a future plenty of people see or want. But simpler and composable Linux commands are far more flexible than pre-defined Windows or Mac “Settings App”. The barrier to entry for the former was knowledge and familiarity, while the latter optimizes for simpler user experience. Agents don’t have to worry about knowledge or familiarity the way users do.
Ok, now you have customers_aggregate(‘topspenders’), but the prompt to the agent was “Get me the top spenders that are public companies and show me ones that increase their spend proportionally to their revenue increase and ones that don’t”. If the agent had access to the needed APIs (or CLIs) for your data and a finance API provider, it can generate a script that crunches down the top 10 or 10,000 for all that data. You could obviously come up with a toolcall that encapsulates that or rely on multiple toolcalls and on the LLM to fill in data correctly between them then do the math using inference.
Edit: even if you look at that customers_aggregate(‘topspenders’) tool, you wouldn’t have needed that if the agent could execute a SQL query. It can also express anything the data can do. You obviously trade the control and correctness guarantees you can give for a `customers_aggregate(‘topspenders’)` vs a potentially wrong SQL query generated by the LLM with the infinite flexibility of a SQL query to be able to express far more than you could in a customers_aggregate call.
An MCP tool call that returns the top N spenders puts the result in the agent’s context window.
A CLI tool call on the other hand… The agent can pipe their results into other completely unrelated CLI tools. It can write a loop that calls multiple tools.
These things are not possible with MCP but are trivial with CLIs.
Edit: I read it. Yep.
We have text interfaces refined by humans for decades and there's an endless sea of training data for them, but they imagine these amateur-hour homegrown solutions will ever outdo an agent with shell access?
But you can have both: rund the agent outside the vm/sandbox and orchestrate work on it, either directly via shell calls or kicking off an ephemeral subagent on the box.
This makes the agent and session that runs outside the vm more durable and opens new orchestration pattern.
I’m building the oss version of this here: https://github.com/smartcomputer-ai/lightspeed
This doesn't cover the case when you're talking to an LLM from web, or via Slack or Linear, etc. There, you will want MCP so the LLM can use services on your behalf as you. That's portability.
When you talk to an LLM on the web, the harnesses spin up a fresh environment (I would hope it’s a VM…) so that the LLM can do stuff like run arbitrary Python and Bash scripts to complete the task you asked it for.
There’s no reason why you shouldn’t be able to customize this environment to add whatever CLI tools and credentials you need for the agent to act on your behalf.
The UX would be exactly the same.
All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code.
Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses.
So why not augment their repertoire of CLI tools instead of a completely new protocol?
- CLI tools need to access your secrets in your .env. With MCP the model never sees the secrets and refresh tokens.
- CLI tools don't have auditing and telemetry. MCP provides all this for free.
- CLI tools imply full bash access, a nightmare in terms of security and very costly if you have to spin up a machine for every request for billions of users.
- etc
But let’s take my MCP clock for example if you ask ChatGPT what’s the time in Tokyo it’s not even gonna think of booting up the code interpreter. It’s gonna just do web search and give you the wrong time (I just tried it and there may be an OpenAI built in widget it pops up now—but again that’s a specific tool call with an iframe output not arbitrary code)
The point is that even web search should be a CLI tool, and all ChatGPT would know to do other than talk to you is how interact with a shell.
Then if you ask it what’s the time in Tokyo, it would likely reach for the POSIX date command, instead of web search, because both would be equally visible.
The difference is that we already have Bash :)
your messages causing your LLM (harness) to run CLIs on your computer? charming, thrilling, great fun.
other people’s messages causing your LLM to run CLIs on your (cloud) computer? terrifying, awful, sickening, no fun at all
This essentially makes MCP just another REST API endpoint, and lets you use the same infrastructure you already have set up for REST APIs (like load balancers, API gateways, progressive rollouts, etc).
1. a REST-like API
2. with a spec (OpenAPI, introspection, etc.)
3. with harness-level authz (the ability to allow / deny specific methods in the harness)
The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.
So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.
I maintain https://endara.ai and you can very quickly introduce a ton of capabilities for Claude/Cursor/ChatGPT by configuring all the stuff you use in a single place (and slicing them with profiles if needed).
Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the Gmail plugin".
This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.
This is easy to see when you think in terms of a developer. The natural way to adapt an existing REST API into an MCP server while keeping the two synchronized is to simply write a basic translation tool that takes your OpenAPI spec and turns it into an MCP manifest, mapping each HTTP endpoint to an MCP method, and copying over all the request / response type signatures and descriptions for everything. Then, all of the sudden, it hits you: there is no need for this translation layer.
There are multiple products that turn OpenAPI schemas into front-ends nowadays.
But there's a pretty large body of RFCs that define what makes a good REST API. For instance POST should create things, PUT should re-define them, PATCH should incrementally update them, GET must be side-effect-free, etc. And there's a ton of standard HTTP headers. Pair it with OpenAPI and the whole thing is self-documenting. You can achieve the same effect with gRPC + reflection, or GraphQL + reflection, and there's plenty of mature tooling and interoperability for each system.
By comparison, MCP actually has relatively few conventions. LLMs are very familiar with REST and OpenAPI already. Just use that.
I learnt this with Sun RPC and the whole "The network is the computer".
Somehow this keeps having to be relearnt.
It’s not true. It’s not totally untrue, but don’t hide your head in the sand.
disable-model-invocation: true
Most MCP servers still bloat up my context even when I am not using them at all. Why can't they be configured to allow me to keep them out unless I really need to use them?
Modern harnesses don't do that, MCP is also progressive disclosure now. MCP tool descriptions aren't included anymore, and have to be found via tool_search. I actually find that to be a regression. Sometimes the models will start coding a python script for something that is already available via a pre-compiled MCP tool call.
In Claude Code you can enable / disable MCP servers at will, just use the /mcp command. You can also lock down permissions in claude -p headless mode to individual tools within an MCP server (eg maybe you only want to allow the reading tools, and none of the write-enabled tools for your automated session).
I am guessing keeping them all in every request is cache efficient though.
Isn't MCP _an API_?
> code_execution tool - uses monty to run an interpreter that has all other tools available as async functions. Maki uses it to filter / summarize / transform / pipe data to other tools as input, without it ever reaching and polluting the context window. Sandbox limited by time & memory.
Failing that, you can just disable native MCP in your harness and have your agent use a CLI tool that calls MCP, like mcp-cli [1], and then the agent can use regular unix pipes to filter or transform the output. Here, rather than raw grep or sed (which are line oriented), the agent would probably use things like jq.
[0] https://github.com/tontinton/maki#context-efficiency
[1] https://github.com/philschmid/mcp-cli
Not sure whats the downside of this approach is but its serving us well so far.
I thought it was The Browser Company’s invention?
https://claude.com/blog/skills
> Introducing Agent Skills
> October 16, 2025
I can find articles and Reddit posts about Dia Browser’s Skills from July 2025.
What about mcp-inspector? It’s a nice tool, can be used interactively, can be used as a CLI.
https://github.com/modelcontextprotocol/inspector
Then for my list command:
With the inspector one you would do: Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.a few months ago I tried to implement an MCP server from scratch in python (instead of using the existing reference implementation) and I could not get it to work reliably across clients
Wrote about this back in March: https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
MCP is going to be a foundational piece of enterprise agent infra.
Nowadays, these agents are more capable and I think you can replace MCP (which is a pain on macOS), with simple CLI tools and expose them to agents via system prompt, skills, or other API documentation.
Like a tool where the AI can only call out to certain APIs based on a config file the agent cannot change.
That way you can leverage all the shell knowledge agents already have while still limiting what network calls they can make, and you wouldn't have to set up a server to use an agent.
As a result, everything compounds. The work I do doesn't need to be re-derived by the work you do. Typed models keep everything repeatable and deterministic. Huge reduction in token spend and huge increase in speed.
1: https://swamp-club.com
I love this question because of the diverse answers given and we learn from each other.
The idea could be that the agent runs as a unix user. That user has execute access to these scripts but not read or write access.
So the agent can only do what those scripts allow, the scripts present an API. You could let agents call the scripts with -h to get instructions, and just put some text into context saying like "to access helper scripts call ./showHelp".