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.
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.
I can turn off auto invocation of a skill. It uses zero tokens when in this mode. I can still invoke it by calling it by name. How can I do that with MCP servers?
What you're describing is a harness implementation detail not something specific to the MCP protocol or even how skills behave. Both of those are effectively providing the same level of information to the harness. Harnesses have traditionally (and still generally do) exposed enabled MCP servers and their actions ahead-of-time in the system prompt directly instead of doing progressive disclosure.
> you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
Even when it is disabled? The point is to have the skill or mcp app to not use ANY tokens until I call it by name. I can do that with a skill. Can I do that with an mcp app?
I don't see a reason to support MCPs by default. Pi is so extensive and has such a rich plugin ecosystem that MCP support is just one "pi install npm:pi-mcp-adapter" away.
Or you may choose another plugin that works differently.
That's the whole point of extensible systems like Pi or Emacs, you don't need to pray that maintainers will have the same vision as you, you just pick one of the many alternatives instead. Or ask pi to write one for you.
it's not a question of model size, it's a question of your model API engineering. The initial problem was that the all tools schemas needed to be loaded in the model's initial system prompt, and changing the tools list in the middle of a session was busting the cache.
Any model can now overcome that with a Tool Search tool implementation
Skills definitely can pollute the context window. They can be verbose. You can have a very long list of advertised skills. You can try and hack around with skill execution inside of subagents etc but there is always a trade-off.
> Skills don’t pollute the context window and, skills are more flexible and composable.
they do but more importantly model does not give a flying fuck about what you put in there in any consistent way.
ppl have been mislead by ai companies that they've invented some sort of agi that you can 'explain' to using skills. So ppl have come up with also sorts of skills that dont do jack shit.
It's still not really an either or scenario. Skills will always serve a purpose as high level on demand contextual guidance. I think of MCPS as hard tools, api contracts etc. While the initial release gave them the ability to be contextual sources as well, I think that's now better served with skills, and mcps can focus on being repositories of functionality.
Skills and tools all need their contextual descriptions to be evolved using evals in order to be effective and efficient. Sounds like the Liner MCP could use with some of that.
Yes, but I expect that the elided part is less important than people assume it is.
Token count is a less important factor in context pollution than idea count. The worst of the rot factors are when models latch onto irrelevant information, or over-index on some vague idea/suggestion as if it was a hard direction, and then go off course.
The names + one-line descriptions of 10 tools can do as much (or more!) to distract the focus and intentionality of an agent than a 30k token exhaustive API documentation of some tool.
I've seen implementations of a skill search, where instead of loading all descriptions into the initial prompt there's a tool the agent can call to search available skills and see if one might match their new task.
Search itself pollutes the context. With the need to maintain the tools, the search, the search results etc. in context. And wasting tokens while interpreting results.
Is it so unusual to just ... not ... load the file with a description of them all automatically, but have different files listing different ones for different situations, and manually point to them in prompts?
Depends on how the harness injects those files. All harnesses these days auto-discover "skills" and read them anyway, and inject their descriptions, at the very least. Which leads to this anyway: https://news.ycombinator.com/item?id=49183906
But yeah. You could have files with skills outside of the auto-discovered skill tree, and invoke them manually.
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.
They didn't reinvent it, it's literally using JSONRPC. The thing they "invented" was coming up with a loose standard for how to implement your RPC endpoints in a way that the AI was pre-trained to interact with.
The actual implementation may have been very janky but the idea itself is sound: If you want to interact with arbitrary services then providing one single protocol (ideally not JSONRPC but hey) with a standard api discovery method and standard starting method call means your super-intelligent machine god can connect to any MCP service with just a URL and figure everything out from there.
There's more to it than that. MCP adds the concept of the API endpoints describing themselves (giving agents context), standardizes how auth works, and so on. This could all be done by packaging existing standards, but MCP in many ways is packaging and organizing existing standards, minus the previous stateful-first design.
I do think a lot of the standard would have been easier if they'd been stateless first, and allowed for GET requests, but it evolved from a starting point that has since evolved.
Not sure I understand what you mean. MCP servers and methods available do have to be visible to the model in some way so that it can spit out tool calls instructions to be executed by the orchestration layer around it.
But you probably meant something else?
MCP is the protocol by which the harness can connect with additional tools. The harness does the work of discovering the tools, the model is then fed a description of what tools it has available, with zero awareness of whether those tools are MCP or built into the harness itself (except for by the mcp__ prefix in the tool’s name, which a harness could choose to strip off)
Right.
On a related note: "MCP is invisible to the LLM, or should be, under normal use".
I am not convinced there are any downsides for the harness to explicitly feed MCP keywords into the LLM. It seem explicitly doing it has many advantages. For example, it allows the user to ask to interact with a resource through "the configured MCP" rather than directly through some local cli or HTTP endpoints; which can steer the LLM towards the proper actions. Otherwise, the model could in-theory be "clueless" with such a request.
They also reinvented CORBA and DCOM, as MCP now supports gRPC as optional protocol.
The reason is that these "folks getting paid several hundred thousand dollars a year" are mostly youngsters without any care to learn about computing history, which is why IT is a fashion industry.
See HTMX as another example, that is basically ASP.NET Ajax or JSF Ajax.
I always have to smile that the whole microservices, isn't much different from "The network is the computer", Taligent, CORBA/DCOM, WebServices, SOA,.... with iPaaS products being another go at BPEL.
Maybe Microsoft should bring back Biztalk for agentic workflows.
As a veteran of JSF - it is similar, but done better, I think. It's only the frontend. Those technologies were more heavyweight, where each component had a lifecycle it went though on each render, and you needed the backend and frontend to support them. HTMX just takes whatever HTML your backend cares to generate, using whatever method it likes, and does the needful with it.
It was a vibe protocol and with the hindsight glasses on it is obvious.
Someone should have said to the llm coming up with it -- "that sounds like an API with extra steps ... how about we keep these things (tool descriptions) and get rid of all this irrelevant - this will look good in my promotion meeting - overengineering (everything else)"
You are absolutely right is what it would have replied with.
As is the entirety of using an LLM? If you want something deterministic and efficient you get the agent to write a script, verify it, then run it yourself.
Bring back FastCGI, enable the setting in Apache to list a directory, and point the agent to your cgi-bin directory full of all your tools. Calling the bin without any input provides the help text or the interface to the tool.
You can probably throw together a passible auth system on top of it that works with the htaccess format. Which is another cgi script but chowned so it can't be called from the outside. If not that, public key crypto - give your agents certificates that are part of the chain of trust. Mint those out of band and give them an insanely short TTL. Fail2ban or something like that to prevent abuse (agent getting handsy with the server gets blocked, credentials revoked).
The side benefit is that everybody starts writing perl and awk again. Who needs a JS runtime when you have CGI?
It does seem like a return to RPC/REST over HTTP (maybe I am missing some subtleties), which makes sense to me since I never really understood the advantage that MCP bestowed.
It's still too early stage for me. Anthropic needs to mature for a little longer before they're enlightened enough to understand my kafka-based event sourcing model for cross-agent orchestration. Kafka, protobuf, functional domain modelling using F# as a DSL...the whole kit and kaboodle.
Only when my AI and its subagents are modelled through a graph of producing agents, consuming agents, and agentic mailboxes, will Claude Code truly shine.
In fact this aspect of "re-inventing and then congratulating oneself for it" has been a factor in software since the dawn of the subject - it is now with AI/ML, becoming far more endemic across a far broader group of people, who ordinarily would not have done software development properly if it weren't for the immense power that comes from glib application of tooling, minus methodology.
I have long observed that tooling+methodology is a very distinct skillset in software developers - those who treat both subjects with appropriate governance, excel - those who ignore one for the other, tend to make a mess of it.
If you don't have the methods, you will re-invent tools to find those methods. If you don't have tools, you will develop methods sufficient to the creation of those tools. Too many times, folks who have no method of finding existing tools, will instead just build a duplicate tool .. which they will use until they learn the tool-discovery method.
It used to be partially because building tools is fun. Often more fun than building whatever the company actually needs. But now it’s not that fun.
LLMs need to say stuff like “your company sells sparkling water, you should not build and maintain another in-house product board and CRM”, and then stand their ground.
Coming up with solutions isn't so difficult, getting everyone behind one is the hard part. Obviously easier if you're one of the two biggest AI companies in the (Western) world.
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
Maybe that's why they are being paid several hundred thousands of dollars. They get the new wave of programmers to implement their proprietary vendor locked protocol instead of industry standard protocols of the commons.
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...
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
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
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.
I think MCP (or any kind of external API) serves a different purpose than ad-hoc code generation and scripting.
In my view, the MCP should be part of the specification. It should expresses intended actions and/or restrictions while the code generated and executed by the LLM is an implementation detail.
This distinction is completely obvious in some cases such as using an external payment gateway. But let's consider a more borderline case.
Say your database is multi-tenant and every query absolutely must include a tenant_id. Now that doesn't necessarily mean you have to use MCP. It could be some command line tool that requires a tenant_id parameter.
But what you can't do is ask the LLM politely to please include a where clause for the tenant_id in any and all SQL statements it decides to generate. You have to impose some things deterministically and MCP is one way to do that.
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.
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
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?
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.
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.
It can’t possibly be more expensive than doing equivalent work using context instead of RAM and inference instead of CPU.
Unless we’ve got the wrong balance of compute availability and inference availability right now, but I would expect the market to stabilize at some point.
Even on your own machine with CLI tools , you really think it’s a great idea to let the LLM use the CLI as if it were you, with all permissions you have without any way to differentiate between actions you have manually taken and those that the LLM did?
I hope the answer is no and you sandbox the agent with its own permissions and user, but if you do that perhaps MCP does not look so bad anymore!?
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?
- 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.
I'm not especially a fan of MCP but it also offers:
- Standardized input and output schemas for each tool
- Standardized annotations that indicate how potentially dangerous each tool can be (e.g. read-only, idempotent, publishes data visible to third parties)
> CLI tools need to access your secrets in your .env
They can access whichever secret store you want. There are dozens of projects offering valid solutions nowadays for the local tool call space, and they’re equally useful in this scenario.
> CLI tools don’t have auditing and telemetry
They’ve had it for much longer than MCP.
> A nightmare in terms of security
We know how to secure shells. Git over SSH is a hardened, public shell that works all the way up to GitHub scale. You just offer a limited toolset. No escape, unless there’s a vulnerability, which is just as likely with MCP.
> Very costly
It’s a rounding error in comparison to token costs.
None of this is true. The point of "just CLI" is that LLMs are infinitely more trained on working CLI tools. There doesn't need to be real CLI tools behind the harness, as long as the interface is CLI-like.
All of the main agent CLI's provides a demonstration that it is possible because they're all callable as a CLI. Several of them, like Codex, Kimi CLI, Pi, OpenCode are open source and so you could obviously strip out the MCP host and client from them and turn them into a CLI. Doing so in a way that keeps auth outside the agents sandbox is trickier and you might end up with a proxy which partly defeats the point but at least still keeps the composability of a CLI.
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)
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.
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 ..
It was already possible, but it requires 1) an MCP server that terminates connections, and/or 2) for both the client and the servers to gracefully handle terminations and reconnections without bothering users with it.
As for the "just use a CLI" crowd, stateless MCP servers should satisfy us too - it means providing an mcp CLI tool that provides all the benefits of a CLI with access to all the API's exposed over MCP has just become easier.
These days even chatting on iOS you’re getting some “vm-esque” ability for the model to run python etc
They’re essentially provisioning you a temporary vm, so it’s morally equivalent to running cc on ur laptop and remote-controlling from the app, except worse
So if the LLM behind the scene has its own compute environment anyway, why not just use a cli?
This is imo what the cli crowd is actually assuming
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).
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".
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.
Okay, here’s one I’m working through. When the workload consists of compound elements in multiple domains, agents work best when they see that as a flat surface of detailed resources. Traditional APIs work best when they hide the implementation details behind an ergonomic api.
So service API developers want to abstract and hide, over and over, and this means agents have less and less context and do more guessing.
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?
With human devs, errors become recovery instructions.
400 Bad Request is fine for a client developer who reads it once at design time and fixes the code forever. it's dead weight for an agent that must self-correct from the string alone. "Expected ISO-8601, got 03/04/2025" is now a functional part of the interface.
Not all agents are developers who can code their own interface.
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.
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).
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".
Yep. There's already a well-established system of `.well-known` URL paths to support things like API spec discover, auth discovery, etc. Why re-invent those wheels?
Because while an agent can indeed call a REST API directly using some other tool ( probably curl) what LLMs are good at is calling tools, and all MCP is doing is turning an API into a tool and standardizing authorization, which if you go the API route can be a nightmare as auth is not even mentioned in OpenAPI specs, usually, so the agent has to figure out how to do auth, and it will necessarily have access to your token and maybe even credentials, so it can easily leak it to attackers your agent happens to visit by just asking for it. I can’t believe anyone who has tried to give agents access to APIs in a sane manner hasn’t concluded that something on the lines of MCP is absolutely necessary.
I guarantee you any LLM will be perfectly capable of navigating HTTP auth [1] which has been around since 1999.
You could use `curl`, or you could bake an HTTP client tool into the agent harness which operates at a more abstract level. The agent would just have a tool that looks a lot like the Fetch API [2] and the harness could simply be configured to inject credentials using the various well-established patterns that have long existed, allow / deny certain methods, etc. The thing is, everything you can do with MCP could also simply be done with REST, so neither is inherently better than the other, I just don't like the proliferation of needless standards.
You can’t be seriously proposing HTTP auth (you probably mean basic auth??) as a solution!? Just hand your raw credentials to the LLM, what could go wrong?
Letting the harness inject the credentials implies not exposing them to the LLM.
Besides, the current state of MCP authentication almost always involves just hard coding secrets in .claude/settings.json so it's not like that's doing a great job keeping the creds away from the LLM anyway. All I'm saying is that MCP auth offers no advantage.
OpenAPI 3.0 has auth. You can turn OpenAPI specs into tool calls just as well, without giving your agents access to call curl and without leaking credentials.
The problem is often that OpenAPI schemas are often incomplete, since they used to be useful to humans even in an incomplete state.
MCP basically requires you to do the equivalent work of getting your OpenAPI schema complete. It’s just much easier to sell to your managers.
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.
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.
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.
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.
REST has issues if you limit yourself to think of the “resources” as your domain entities.
If you have a long running search, the resource is the search. Create a search. Fetch search results. Delete the search when you’re done.
Similarly, if you have a sufficiently complex command, the resource is the command itself. Maybe it requires async work, and you can later fetch the command results.
Anecdotally, this seems to be too big of a leap in mental model for beginners, mostly because all of the REST learning path does is teach you how to use it in CRUD domains.
The read-only QUERY method can send much bigger requests than GET.
For delayed answers, MCP offers no improvement, because remote MCP servers use an HTTP transport anyway, and local ones don't involve middleware you can't control. Besides, that's well-trodden ground. SSE, trailers, gRPC streaming, websockets, simple polling, etc. We don't need another protocol.
If you connect the dots of the earlier MCP Client/Server docs you understand that your desktop AI tool was also a MCP Server. This MCP Server provided the tools like "search files", "alter files", "open file".
It's was simpler to design/implement the AI tool if these interactions had state. When this was generalized to internet interactions this no longer made sense and was gradually cleaned up.
I think at the same time, the AI tool "protocol" to interact with the local system moved away from MCP model.
During the initialize step, the client tells the server about its capabilities. Then the server remembers them for the session, so the client doesn't need to keep saying what it can do, and the server won't expose tools the client can't use. It's more overhead for the server, but more efficient over the wire for the rest of the session (that's just my understanding at least -- not saying this couldn't all be stateless).
Next he’ll discover that it’s useful for MCP abilities to be organized by resource and a limited set of actions you could perform on those resources, like getting the resource, posting a new resource, patching an existing resource, or deleting the resource. We’ll call it: Resource Oriented Stateless Transformation MCP or ROST-MCP for short.
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.
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.
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?
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).
Skills and MCP can be treated by the harness in the exact same way. What do you think is unique to skills that does not apply to how MCP servers are managed?
> What do you think is unique to skills that does not apply to how MCP servers are managed?
I have a skill that describes my database schema with hundreds of tables, stored procedures, triggers at a high level. It tells the LLM to use a specific CLI to connect to the developer database using an account with read-only permissions. This skill has auto invocation turned off and uses zero tokens when not used.
MCP apps do not have a manual invocation option. If you enable them, they are always on, eating away tokens, even if you are not using them at all. And for my simple example above, would be a lot more work to setup. And once setup would eat way more tokens when compared to a small skill file that describes a CLI tool for querying the SQL database.
Output of an MCP tool call goes straight into context. Output of a CLI tool call can be filtered by the LLM using another tool, before it enters context.
These are meaningful differences and show that skills get the work done in an efficient manner, vast majority of the time.
MCP and skills complement each other, it’s not one vs the other.
> MCP apps do not have a manual invocation option. If you enable them, they are always on, eating away tokens
This is not true of recent harnesses. They will not consume any tokens until the LLM searches for tools. Similar to how they handle skills, and that’s my point: they can and do manage tools and skills similarly. They could easily let you invoke tools explicitly as well , it’s maybe their choice not to.
> Output of an MCP tool call goes straight into context. Output of a CLI tool call can be filtered by the LLM using another tool, before it enters context.
That’s a good point, but this is not about MCP , it’s about tools in general. Tools can provide structured output which should allow for even more advanced usages by the LLM than a text-based CLI approach. However I haven’t seen that done yet and it could be a nice feature to address!
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.
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.
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.
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.
MCP serves a single purpose: If you ask some company for API support for some stuff you can do via web UI but not API, they might say no for many reasons. But when you ask for MCP, suddenly you trigger AI FOMO and it will be available right away.
Previously, it was an API with a weird stateful standard; now it is essentially a bog-standard stateless JSON-RPC API with conventions for tool discovery, long-running tasks and multi-round-trip requests
If you wrote your own JSON-RPC API for an LLM, you would probably eventually end up with something that looks very much like the standard they're describing.
Its more targeted? Sure I can allow an LLM to access CLI, but then it will try to pipe to other command, write scripts etc. MCP is simply request/response. Its not really that technically different, but the way you and LLMs interact with it allows for easier control. IMHO.
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.
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.
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.
The people who promote it don’t get it either but the inmates are running the prison now so we have to pretend like “stateless MCP” isn’t just rebranded REST APIs
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.
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.
fast-agent is very good at this (disclosure: author)
you can specify --url, --npx and include --auth $TOKEN on the command line. you can also interactively connect with /connect, and pixel peep transport details https://fast-agent.ai/mcp/mcp-inspect-transport/
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.
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.
Love using MCP, working on adding it as a first-class surface to products I’m developing. Agent experience is becoming as important or more than user importance for some products. Big fan of AgentCat and other tools for applying MCP observability - can't improve what you don't measure
It seems to me an alternative to MCP would be a shell implemented to only allow access to white listed commands.
I also feel like a lot of knowledge about how to lock down a multi-user system has been lost. Back when many people shared a single computer through terminals, admins had a lot of responsibility to create a permissions structure such that one user couldn't access another's data or hog too many resources that would impact other users on the system. We are running computers with the similar permission models (Mac and Linux are Unix, Windows has similar controls) but we can't manage to lock down shell access to trust an LLM with it as if it were a human user we don't fully trust.
> Giving an agent a shell environment with the ability to access the internet is fraught with risk
A good middle ground is to give it a shell environment with no access to the internet, but with standard tooling like python, perl, jq, and sed plus a custom CLI which can talk to a server which does have access to the internet.
This way it can still be flexible about preprocessing input and postprocessing output re: that CLI, and any secrets stay server-side and out of its reach.
Let it change the CLI and the server, but deploy the updated server by hand, that way you're in a position to review and if necessary prevent the agent from adding any capabilities that it shouldn't have.
MCP is nice, but does your agent use it without you explicitly asking it to do so?
From my experience, instructions in `.md` files aren't enough. In fact, Claude seems to prefer the shell over even its own built-in tools (e.g. `read`, `edit` etc.) See: https://github.com/anthropics/claude-code/issues/19649. It's like an old dog that needs to be tricked to learn new tricks.
Same experience for me. I routinely have to say "no, use the tool" or "no, read your skills." More frustrating than anything but I've definitely noticed models [1] struggling to grab the right tool without me steering it.
> or you can just wire everything up in the shell itself keeping it as simple as possible with one single tool
If I understand correctly, you’re not answering my question, and you’re not talking about MCP either. Have you considered that maybe you’re in the wrong thread?
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
I'm curious if LLM could easily be manipulated to actually process data in context and remove it from its context and replace it with the result or a hint.
Might break the caching, perhaps this can be solved with snapshot ids or cache ids like "Replacing context line 434-500 with hint; checking last request before that context even was added and running that cache before"
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.
MCP over streamable HTTP is just JSON RPC payload over HTTP.
The internal interface for the ChatGPT app and Coded are all MCP based (stdio on local).
All enterprise AI rollout is eventually going to converge on MCP as a key piece of that infra because it can mask credentials behind one gateway that's easier to control and more secure.
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.
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".
What MCP really needs is standardized auth. There's maybe 10 different common ways to authenticate against MCP servers, and the average non-engineer can't read the docs to figure out how to configure it.
Companies can implement Individual Oauth with DCR (which makes it as easy as "log in with Google"), but many don't
As more AI agents rely on MCP, stateless implementations seem like a natural fit for horizontal scaling. The remaining challenge is efficient context management, interested to see how different projects tackle that.
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.
MCPs are very exciting. They now support IFrames (MCP Apps) as well.
Now that the models are getting better, you can trust them to book barber appointments, order groceries, manage your calendar, etc etc. It's significantly lazier to ask an agent to do something than manually doing it. Especially with voice to text.
I'm predicting that chat bots will auto-discover MCPs from trusted websites and make life much easier.
The web_search tool and MCP discovery is essentially a global directory.
Now when I ask ChatGPT for a product, it does a web_search tool call and then gives me a link to a webshop product page. But next step would be automatically using the MCP of that webshop to embed checkout inside chat.
afaik Claude already has a "discovery" tool for official Claude connectors, that's why a lot of companies are rushing to get on the marketplaces.
I know that bc I'm the founder of https://manufact.com and we helped a ton of companies with that.
It seems like the core value add of MCP as described here is text only documentation for an API, as opposed to the human standard of HTML-like docs.
Is that roughly accurate? We are talking about a technology that would allow SaaS API vendors to publish a second set of documentation (or adapt the same one to both human and LLM targetted channels)?
I'm being a bit cynical, but here's my minimal naïve alternative solution, not proposing it be used, but just saying that this would be equivalent:
1- Publish a well known endpoint like /docs_url , which could return something like "docs.domain".
2- Support an alternative content-type header, where instead of 'text/html' the client could ask for 'text/plain', or 'text/markdown'
2b- Alternatively, changing the extension type could achieve the same result, where requesting docs.domain/endpoint.txt would return the docs in text instead of in html
So now I ask, how is MCP better than the solution I proposed? Did I grossly misunderstand something? Or am I on track to avoiding hundreds of engineering hours due to accidental complexity by recognizing and avoiding a privately funded protocol that serves to increase vendor lock instead of reducing complexity of our systems?
I've started building MCP servers for some of my own projects as well. For example, I built one for a VIN decoder website so AI assistants can look up vehicle information directly instead of requiring users to switch back and forth between a chat and a browser.
For me, that's the biggest appeal of MCP. It's not just another API wrapper—it makes existing tools much easier to use from within an AI workflow. The less context switching users have to do, the better the experience feels.
The move toward a more stateless design also makes a lot of sense. Simpler deployment, easier horizontal scaling, and fewer session-management headaches are all welcome improvements for anyone running these services in production.
I feel like 5% of people who develop MCP Servers for a living and 10% of the people who develop MCP Clients for a living use the MCP Inspector and understand the Protocol.
which is far from the best MCP inspector out there we hosted an online version of the mcp-use inspector which is pretty convenient: https://inspector.manufact.com/inspector
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.
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.
I can turn off auto invocation of a skill. It uses zero tokens when in this mode. I can still invoke it by calling it by name. How can I do that with MCP servers?
What you're describing is a harness implementation detail not something specific to the MCP protocol or even how skills behave. Both of those are effectively providing the same level of information to the harness. Harnesses have traditionally (and still generally do) exposed enabled MCP servers and their actions ahead-of-time in the system prompt directly instead of doing progressive disclosure.
You can't do that with tools either. Skills are basically prompts - they're not analogous to tools or MCPs. I'm not sure what your point is
[dead]
you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
> you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
Even when it is disabled? The point is to have the skill or mcp app to not use ANY tokens until I call it by name. I can do that with a skill. Can I do that with an mcp app?
Use an MCP proxy.
Interesting, then I wonder if Pi having Skills support but not MCP support by default still makes sense
Pi does support MCP through an excellent pi-mcp-adapter plugin.
Yes, I meant the decision to not support MCP by default without plugins, like Skills, could be revisited if it’s now efficient
I don't see a reason to support MCPs by default. Pi is so extensive and has such a rich plugin ecosystem that MCP support is just one "pi install npm:pi-mcp-adapter" away.
Or you may choose another plugin that works differently.
That's the whole point of extensible systems like Pi or Emacs, you don't need to pray that maintainers will have the same vision as you, you just pick one of the many alternatives instead. Or ask pi to write one for you.
Is it also a solved problem for smaller models, as the article mentioned?
it's not a question of model size, it's a question of your model API engineering. The initial problem was that the all tools schemas needed to be loaded in the model's initial system prompt, and changing the tools list in the middle of a session was busting the cache. Any model can now overcome that with a Tool Search tool implementation
Skills definitely can pollute the context window. They can be verbose. You can have a very long list of advertised skills. You can try and hack around with skill execution inside of subagents etc but there is always a trade-off.
> Skills don’t pollute the context window and, skills are more flexible and composable.
they do but more importantly model does not give a flying fuck about what you put in there in any consistent way.
ppl have been mislead by ai companies that they've invented some sort of agi that you can 'explain' to using skills. So ppl have come up with also sorts of skills that dont do jack shit.
It's still not really an either or scenario. Skills will always serve a purpose as high level on demand contextual guidance. I think of MCPS as hard tools, api contracts etc. While the initial release gave them the ability to be contextual sources as well, I think that's now better served with skills, and mcps can focus on being repositories of functionality.
Skills and tools all need their contextual descriptions to be evolved using evals in order to be effective and efficient. Sounds like the Liner MCP could use with some of that.
For an MCP used to look up data in any kind of dataset, just having a single tool that accepts an OData Query string has worked well for me.
> 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?
Skills don’t need to be preloaded, can be invoked by name on demand; and when you list available skills, a one-line description for each is enough.
And all those "names and one-line descriptions" live in an .md file and of course pollute your context.
And then the model will randomly decide to load the .md file that is the "skill" randomly at any point. Again polluting the context.
There's no magic.
Most people seem to mean "Skills don't pollute the context window [with their entire contents]", they just elide the part in brackets.
There is no magic and people should be more precise when discussing skills.
Yes, but I expect that the elided part is less important than people assume it is.
Token count is a less important factor in context pollution than idea count. The worst of the rot factors are when models latch onto irrelevant information, or over-index on some vague idea/suggestion as if it was a hard direction, and then go off course.
The names + one-line descriptions of 10 tools can do as much (or more!) to distract the focus and intentionality of an agent than a 30k token exhaustive API documentation of some tool.
I've seen implementations of a skill search, where instead of loading all descriptions into the initial prompt there's a tool the agent can call to search available skills and see if one might match their new task.
Search itself pollutes the context. With the need to maintain the tools, the search, the search results etc. in context. And wasting tokens while interpreting results.
Is it so unusual to just ... not ... load the file with a description of them all automatically, but have different files listing different ones for different situations, and manually point to them in prompts?
Depends on how the harness injects those files. All harnesses these days auto-discover "skills" and read them anyway, and inject their descriptions, at the very least. Which leads to this anyway: https://news.ycombinator.com/item?id=49183906
But yeah. You could have files with skills outside of the auto-discovered skill tree, and invoke them manually.
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.
They didn't reinvent it, it's literally using JSONRPC. The thing they "invented" was coming up with a loose standard for how to implement your RPC endpoints in a way that the AI was pre-trained to interact with.
The actual implementation may have been very janky but the idea itself is sound: If you want to interact with arbitrary services then providing one single protocol (ideally not JSONRPC but hey) with a standard api discovery method and standard starting method call means your super-intelligent machine god can connect to any MCP service with just a URL and figure everything out from there.
> was coming up with a loose standard for how to implement your RPC endpoints in a way that the AI was pre-trained to interact with.
Why not just pre-train the model to interact with JSONRPC endpoints?
There's more to it than that. MCP adds the concept of the API endpoints describing themselves (giving agents context), standardizes how auth works, and so on. This could all be done by packaging existing standards, but MCP in many ways is packaging and organizing existing standards, minus the previous stateful-first design.
I do think a lot of the standard would have been easier if they'd been stateless first, and allowed for GET requests, but it evolved from a starting point that has since evolved.
MCP is invisible to the LLM, or should be, under normal use
Not sure I understand what you mean. MCP servers and methods available do have to be visible to the model in some way so that it can spit out tool calls instructions to be executed by the orchestration layer around it. But you probably meant something else?
MCP is the protocol by which the harness can connect with additional tools. The harness does the work of discovering the tools, the model is then fed a description of what tools it has available, with zero awareness of whether those tools are MCP or built into the harness itself (except for by the mcp__ prefix in the tool’s name, which a harness could choose to strip off)
Right. On a related note: "MCP is invisible to the LLM, or should be, under normal use". I am not convinced there are any downsides for the harness to explicitly feed MCP keywords into the LLM. It seem explicitly doing it has many advantages. For example, it allows the user to ask to interact with a resource through "the configured MCP" rather than directly through some local cli or HTTP endpoints; which can steer the LLM towards the proper actions. Otherwise, the model could in-theory be "clueless" with such a request.
By this statement, do you mean that LLMs really just know about "Tool Calling Tokens" or something else?
Essentially, MCP is the harness’ wheelhouse, not the model’s
They also reinvented CORBA and DCOM, as MCP now supports gRPC as optional protocol.
The reason is that these "folks getting paid several hundred thousand dollars a year" are mostly youngsters without any care to learn about computing history, which is why IT is a fashion industry.
See HTMX as another example, that is basically ASP.NET Ajax or JSF Ajax.
If only they could ask for history lessons from an LLM!
(To your point...having knocked out CORBA and DCOM, perhaps we may next look forward to SOAP.)
I always have to smile that the whole microservices, isn't much different from "The network is the computer", Taligent, CORBA/DCOM, WebServices, SOA,.... with iPaaS products being another go at BPEL.
Maybe Microsoft should bring back Biztalk for agentic workflows.
As a veteran of JSF - it is similar, but done better, I think. It's only the frontend. Those technologies were more heavyweight, where each component had a lifecycle it went though on each render, and you needed the backend and frontend to support them. HTMX just takes whatever HTML your backend cares to generate, using whatever method it likes, and does the needful with it.
Maybe Greenspun's Tenth Rule applies to anything "common".
oh no, all of those technologies die on their own merits a long time ago. they were basically over engineered and bloated and horrible to work with.
It was a vibe protocol and with the hindsight glasses on it is obvious.
Someone should have said to the llm coming up with it -- "that sounds like an API with extra steps ... how about we keep these things (tool descriptions) and get rid of all this irrelevant - this will look good in my promotion meeting - overengineering (everything else)"
You are absolutely right is what it would have replied with.
OpenAPI already exists, you can serve it on an endpoint for tool descriptions. Why did we need MCP again?
that would be tokens, vibes and guesses all the way down
As is the entirety of using an LLM? If you want something deterministic and efficient you get the agent to write a script, verify it, then run it yourself.
Bring back FastCGI, enable the setting in Apache to list a directory, and point the agent to your cgi-bin directory full of all your tools. Calling the bin without any input provides the help text or the interface to the tool.
You can probably throw together a passible auth system on top of it that works with the htaccess format. Which is another cgi script but chowned so it can't be called from the outside. If not that, public key crypto - give your agents certificates that are part of the chain of trust. Mint those out of band and give them an insanely short TTL. Fail2ban or something like that to prevent abuse (agent getting handsy with the server gets blocked, credentials revoked).
The side benefit is that everybody starts writing perl and awk again. Who needs a JS runtime when you have CGI?
What hindsight, this was obvious from day one.
It does seem like a return to RPC/REST over HTTP (maybe I am missing some subtleties), which makes sense to me since I never really understood the advantage that MCP bestowed.
The core advantage MCP gave you was a standard that by virtue of being blessed by AI providers people had strong incentives to actually implement.
But surely the openapi spec is more mature and widely adopted?
It's still too early stage for me. Anthropic needs to mature for a little longer before they're enlightened enough to understand my kafka-based event sourcing model for cross-agent orchestration. Kafka, protobuf, functional domain modelling using F# as a DSL...the whole kit and kaboodle.
Only when my AI and its subagents are modelled through a graph of producing agents, consuming agents, and agentic mailboxes, will Claude Code truly shine.
I can't tell if this is sarcasm or an advertisement for your start up.
In fact this aspect of "re-inventing and then congratulating oneself for it" has been a factor in software since the dawn of the subject - it is now with AI/ML, becoming far more endemic across a far broader group of people, who ordinarily would not have done software development properly if it weren't for the immense power that comes from glib application of tooling, minus methodology.
I have long observed that tooling+methodology is a very distinct skillset in software developers - those who treat both subjects with appropriate governance, excel - those who ignore one for the other, tend to make a mess of it.
If you don't have the methods, you will re-invent tools to find those methods. If you don't have tools, you will develop methods sufficient to the creation of those tools. Too many times, folks who have no method of finding existing tools, will instead just build a duplicate tool .. which they will use until they learn the tool-discovery method.
I think AI/ML is really turning the tooling+methodology equation into a maelstrom. Apropos proper engineering post-mortem, I would question the impact on AI/ML-derived riches on the drive to turn standard methods into Subscription Services© behind Yet Another Tool™ ..
It used to be partially because building tools is fun. Often more fun than building whatever the company actually needs. But now it’s not that fun.
LLMs need to say stuff like “your company sells sparkling water, you should not build and maintain another in-house product board and CRM”, and then stand their ground.
I'd rather LLM's just do what they are told and not diminish my agency whatsoever.
But yes, that is the crux of the problem indeed. Agency is nothing if you don't have methods to turn it into tool-use.
Coming up with solutions isn't so difficult, getting everyone behind one is the hard part. Obviously easier if you're one of the two biggest AI companies in the (Western) world.
The funny thing is that Anthropic and its boosters here framed MCP as a brilliant development.
It's a terrible protocol with zero value beyond bigtech sponsorship. We're all worse off for it.
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
the deployment targets that got cheap over the last five years are all stateless and a protocol that fights that gets no serverless implementations
Maybe that's why they are being paid several hundred thousands of dollars. They get the new wave of programmers to implement their proprietary vendor locked protocol instead of industry standard protocols of the commons.
I had to double take and say "I coulda dun that!!"
The Protocol is from the Linux Foundation
I think stateless-type MCP was already possible, eg my MCP Clock [https://github.com/firasd/mcpclock]:
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...
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
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
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.
I think MCP (or any kind of external API) serves a different purpose than ad-hoc code generation and scripting.
In my view, the MCP should be part of the specification. It should expresses intended actions and/or restrictions while the code generated and executed by the LLM is an implementation detail.
This distinction is completely obvious in some cases such as using an external payment gateway. But let's consider a more borderline case.
Say your database is multi-tenant and every query absolutely must include a tenant_id. Now that doesn't necessarily mean you have to use MCP. It could be some command line tool that requires a tenant_id parameter.
But what you can't do is ask the LLM politely to please include a where clause for the tenant_id in any and all SQL statements it decides to generate. You have to impose some things deterministically and MCP is one way to do that.
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.
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
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.
Anthropic proposed a way to programmatically chain MCPs together a while back, I'm not sure if it's been implemented much yet: https://www.anthropic.com/engineering/code-execution-with-mc...
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?
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.
I’m building the oss version of this here: https://github.com/smartcomputer-ai/lightspeed
We have those sandboxes already, it is called serverless, and those microservices are now extended with MCP endpoints metadata.
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.
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.
Could be more expensive to provide a computing environment.
It can’t possibly be more expensive than doing equivalent work using context instead of RAM and inference instead of CPU.
Unless we’ve got the wrong balance of compute availability and inference availability right now, but I would expect the market to stabilize at some point.
Skills can provide CLI tools for LLMs running on the web. It works great (I use Claude).
Even on your own machine with CLI tools , you really think it’s a great idea to let the LLM use the CLI as if it were you, with all permissions you have without any way to differentiate between actions you have manually taken and those that the LLM did? I hope the answer is no and you sandbox the agent with its own permissions and user, but if you do that perhaps MCP does not look so bad anymore!?
Why would you let the llm use the CLI as you?
Because that is convenient and everyone does it??
Just give it a different user with different permissions if yoirewon Linux. This is half century old tech.
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?
- 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
I'm not especially a fan of MCP but it also offers:
- Standardized input and output schemas for each tool
- Standardized annotations that indicate how potentially dangerous each tool can be (e.g. read-only, idempotent, publishes data visible to third parties)
- Extensions for UI widgets
> CLI tools don’t have standardized auth
EPERM, POSIX ACLs and execute bits.
> CLI tools need to access your secrets in your .env
They can access whichever secret store you want. There are dozens of projects offering valid solutions nowadays for the local tool call space, and they’re equally useful in this scenario.
> CLI tools don’t have auditing and telemetry
They’ve had it for much longer than MCP.
> A nightmare in terms of security
We know how to secure shells. Git over SSH is a hardened, public shell that works all the way up to GitHub scale. You just offer a limited toolset. No escape, unless there’s a vulnerability, which is just as likely with MCP.
> Very costly
It’s a rounding error in comparison to token costs.
None of this is true. The point of "just CLI" is that LLMs are infinitely more trained on working CLI tools. There doesn't need to be real CLI tools behind the harness, as long as the interface is CLI-like.
Show me then how to convert my MCP, including auth, behind a CLI like interface. I don’t think that’s even possible.
"claude -p"
All of the main agent CLI's provides a demonstration that it is possible because they're all callable as a CLI. Several of them, like Codex, Kimi CLI, Pi, OpenCode are open source and so you could obviously strip out the MCP host and client from them and turn them into a CLI. Doing so in a way that keeps auth outside the agents sandbox is trickier and you might end up with a proxy which partly defeats the point but at least still keeps the composability of a CLI.
Can you link it?
Can you elaborate on the auditing and telemetry. I'm wondering what you mean by that and how it comes for free any differently from an cli
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)
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.
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 ..
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 :)
It was already possible, but it requires 1) an MCP server that terminates connections, and/or 2) for both the client and the servers to gracefully handle terminations and reconnections without bothering users with it.
As for the "just use a CLI" crowd, stateless MCP servers should satisfy us too - it means providing an mcp CLI tool that provides all the benefits of a CLI with access to all the API's exposed over MCP has just become easier.
These days even chatting on iOS you’re getting some “vm-esque” ability for the model to run python etc
They’re essentially provisioning you a temporary vm, so it’s morally equivalent to running cc on ur laptop and remote-controlling from the app, except worse
So if the LLM behind the scene has its own compute environment anyway, why not just use a cli?
This is imo what the cli crowd is actually assuming
I am not sure that coding doesn't lead token usage.
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
The LLM can't tell the difference between your messages and theirs, however many times you say "No mistakes"
Perhaps it is time to implement the lessons learned from Perl's taint checking[1], but this time for AI agent harnesses instead[2].
[1] https://en.wikipedia.org/wiki/Taint_checking
[2] https://arxiv.org/html/2607.03423v1
[dead]
[flagged]
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).
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.
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.
You didn't provide any arguments to support your claim. Calling people names isn't going to convince anyone.
Okay, here’s one I’m working through. When the workload consists of compound elements in multiple domains, agents work best when they see that as a flat surface of detailed resources. Traditional APIs work best when they hide the implementation details behind an ergonomic api.
So service API developers want to abstract and hide, over and over, and this means agents have less and less context and do more guessing.
And agentic enthusiasts apparently believe agents can do anything except REST.
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?
With human devs, errors become recovery instructions.
400 Bad Request is fine for a client developer who reads it once at design time and fixes the code forever. it's dead weight for an agent that must self-correct from the string alone. "Expected ISO-8601, got 03/04/2025" is now a functional part of the interface.
Not all agents are developers who can code their own interface.
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.
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).
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".
Yep. There's already a well-established system of `.well-known` URL paths to support things like API spec discover, auth discovery, etc. Why re-invent those wheels?
Like many things in this fashion industry, how else do you get new conference subjects, consulting gigs, books,...?
Because while an agent can indeed call a REST API directly using some other tool ( probably curl) what LLMs are good at is calling tools, and all MCP is doing is turning an API into a tool and standardizing authorization, which if you go the API route can be a nightmare as auth is not even mentioned in OpenAPI specs, usually, so the agent has to figure out how to do auth, and it will necessarily have access to your token and maybe even credentials, so it can easily leak it to attackers your agent happens to visit by just asking for it. I can’t believe anyone who has tried to give agents access to APIs in a sane manner hasn’t concluded that something on the lines of MCP is absolutely necessary.
I guarantee you any LLM will be perfectly capable of navigating HTTP auth [1] which has been around since 1999.
You could use `curl`, or you could bake an HTTP client tool into the agent harness which operates at a more abstract level. The agent would just have a tool that looks a lot like the Fetch API [2] and the harness could simply be configured to inject credentials using the various well-established patterns that have long existed, allow / deny certain methods, etc. The thing is, everything you can do with MCP could also simply be done with REST, so neither is inherently better than the other, I just don't like the proliferation of needless standards.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Aut...
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
You can’t be seriously proposing HTTP auth (you probably mean basic auth??) as a solution!? Just hand your raw credentials to the LLM, what could go wrong?
Letting the harness inject the credentials implies not exposing them to the LLM.
Besides, the current state of MCP authentication almost always involves just hard coding secrets in .claude/settings.json so it's not like that's doing a great job keeping the creds away from the LLM anyway. All I'm saying is that MCP auth offers no advantage.
OpenAPI 3.0 has auth. You can turn OpenAPI specs into tool calls just as well, without giving your agents access to call curl and without leaking credentials.
The problem is often that OpenAPI schemas are often incomplete, since they used to be useful to humans even in an incomplete state.
MCP basically requires you to do the equivalent work of getting your OpenAPI schema complete. It’s just much easier to sell to your managers.
I think by now even non-technical vibe coders have enough of an overview on REST APIs
The spec is more than just an OpenAPI scheme; it’s a strict wire format with shared semantics for a huge range of features.
Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?
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.
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.
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.
Isn’t that the case? Aren’t REST people still debating about what makes a true beautiful REST API?
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.
REST has issues tough.
How do you send a big read only query? A POST? A GET hoping nothings logs it or swallows half of it?
How do you deal with delayed answers? Things that most HTTP middleware will timeout long before the result is achieved?
REST has issues if you limit yourself to think of the “resources” as your domain entities.
If you have a long running search, the resource is the search. Create a search. Fetch search results. Delete the search when you’re done.
Similarly, if you have a sufficiently complex command, the resource is the command itself. Maybe it requires async work, and you can later fetch the command results.
Anecdotally, this seems to be too big of a leap in mental model for beginners, mostly because all of the REST learning path does is teach you how to use it in CRUD domains.
I think you provide good and accurate information. However, what you described sounds like a workaround to me.
The read-only QUERY method can send much bigger requests than GET.
For delayed answers, MCP offers no improvement, because remote MCP servers use an HTTP transport anyway, and local ones don't involve middleware you can't control. Besides, that's well-trodden ground. SSE, trailers, gRPC streaming, websockets, simple polling, etc. We don't need another protocol.
The wire format certainly isn’t strict
There's a nice feature in the new version that lets you copy tool _arguments_ in to the HTTP Headers for custom routing etc.
I came here to ask why it was ever stateful?
If you connect the dots of the earlier MCP Client/Server docs you understand that your desktop AI tool was also a MCP Server. This MCP Server provided the tools like "search files", "alter files", "open file".
It's was simpler to design/implement the AI tool if these interactions had state. When this was generalized to internet interactions this no longer made sense and was gradually cleaned up.
I think at the same time, the AI tool "protocol" to interact with the local system moved away from MCP model.
During the initialize step, the client tells the server about its capabilities. Then the server remembers them for the session, so the client doesn't need to keep saying what it can do, and the server won't expose tools the client can't use. It's more overhead for the server, but more efficient over the wire for the rest of the session (that's just my understanding at least -- not saying this couldn't all be stateless).
Next he’ll discover that it’s useful for MCP abilities to be organized by resource and a limited set of actions you could perform on those resources, like getting the resource, posting a new resource, patching an existing resource, or deleting the resource. We’ll call it: Resource Oriented Stateless Transformation MCP or ROST-MCP for short.
Boom. ROST’d.
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.
can postgREST be helpful for this? Clickhouse also has an http endpoint to send queries
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.
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?
> 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).
> Modern harnesses don't do that, MCP is also progressive disclosure now.
Last time I checked, and it may be different now, Claude Code used tool search only if context usage was greater than 10%.
Also, even with tool search, MCP uses about 1000 to 3000 tokens. A skill frontmatter on the other hand can be around 50.
And an mcp tool call result gets dumped into context in its entirety. A cli too can be filtered with grep/sed etc.
Skills are just a lot more efficient for most use cases.
Skills and MCP can be treated by the harness in the exact same way. What do you think is unique to skills that does not apply to how MCP servers are managed?
> What do you think is unique to skills that does not apply to how MCP servers are managed?
I have a skill that describes my database schema with hundreds of tables, stored procedures, triggers at a high level. It tells the LLM to use a specific CLI to connect to the developer database using an account with read-only permissions. This skill has auto invocation turned off and uses zero tokens when not used.
MCP apps do not have a manual invocation option. If you enable them, they are always on, eating away tokens, even if you are not using them at all. And for my simple example above, would be a lot more work to setup. And once setup would eat way more tokens when compared to a small skill file that describes a CLI tool for querying the SQL database.
Output of an MCP tool call goes straight into context. Output of a CLI tool call can be filtered by the LLM using another tool, before it enters context.
These are meaningful differences and show that skills get the work done in an efficient manner, vast majority of the time.
MCP and skills complement each other, it’s not one vs the other.
> MCP apps do not have a manual invocation option. If you enable them, they are always on, eating away tokens
This is not true of recent harnesses. They will not consume any tokens until the LLM searches for tools. Similar to how they handle skills, and that’s my point: they can and do manage tools and skills similarly. They could easily let you invoke tools explicitly as well , it’s maybe their choice not to.
> Output of an MCP tool call goes straight into context. Output of a CLI tool call can be filtered by the LLM using another tool, before it enters context.
That’s a good point, but this is not about MCP , it’s about tools in general. Tools can provide structured output which should allow for even more advanced usages by the LLM than a text-based CLI approach. However I haven’t seen that done yet and it could be a nice feature to address!
Yes run a side agent to evaluate if they are needed.
I am guessing keeping them all in every request is cache efficient though.
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.
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.
[0] https://github.com/tontinton/maki#context-efficiency
[1] https://github.com/philschmid/mcp-cli
You can compose them if you allow the AI to evaluate code, and give it the proper APIs. Not much changes in this regard afaict.
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.
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.
What is an example of something that is unsafe to consume via API or CLI?
Isn't MCP _an API_?
It is.
MCP serves a single purpose: If you ask some company for API support for some stuff you can do via web UI but not API, they might say no for many reasons. But when you ask for MCP, suddenly you trigger AI FOMO and it will be available right away.
Yes, MCP is an API.
Previously, it was an API with a weird stateful standard; now it is essentially a bog-standard stateless JSON-RPC API with conventions for tool discovery, long-running tasks and multi-round-trip requests
If you wrote your own JSON-RPC API for an LLM, you would probably eventually end up with something that looks very much like the standard they're describing.
Ahh so it's the 2025 name for CORBA? just kidding, I meant SOA /s
But your answer is the first one that seems to be relevant, so thank you.
Its more targeted? Sure I can allow an LLM to access CLI, but then it will try to pipe to other command, write scripts etc. MCP is simply request/response. Its not really that technically different, but the way you and LLMs interact with it allows for easier control. IMHO.
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.
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.
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.
The people who promote it don’t get it either but the inmates are running the prison now so we have to pretend like “stateless MCP” isn’t just rebranded REST APIs
Well for a non-coding (no CLI tooling) flow it means you don't need a sandbox and it provides a plugin architecture.
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.
Yeah, there's a ton of great improvements in 7-28. I'm personally excited about what you posted about, but also with [tasks](https://blog.modelcontextprotocol.io/posts/2026-07-28-releas...) being officially adopted.
> 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.
https://github.com/modelcontextprotocol/inspector
The documentation for the --cli mode is a bit lacking, but I got there in the end:
Equivalent with my mcp-explorer tool: So yeah, they're pretty similar.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.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.
fast-agent is very good at this (disclosure: author)
you can specify --url, --npx and include --auth $TOKEN on the command line. you can also interactively connect with /connect, and pixel peep transport details https://fast-agent.ai/mcp/mcp-inspect-transport/
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.
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.
Love using MCP, working on adding it as a first-class surface to products I’m developing. Agent experience is becoming as important or more than user importance for some products. Big fan of AgentCat and other tools for applying MCP observability - can't improve what you don't measure
It seems to me an alternative to MCP would be a shell implemented to only allow access to white listed commands.
I also feel like a lot of knowledge about how to lock down a multi-user system has been lost. Back when many people shared a single computer through terminals, admins had a lot of responsibility to create a permissions structure such that one user couldn't access another's data or hog too many resources that would impact other users on the system. We are running computers with the similar permission models (Mac and Linux are Unix, Windows has similar controls) but we can't manage to lock down shell access to trust an LLM with it as if it were a human user we don't fully trust.
> Giving an agent a shell environment with the ability to access the internet is fraught with risk
A good middle ground is to give it a shell environment with no access to the internet, but with standard tooling like python, perl, jq, and sed plus a custom CLI which can talk to a server which does have access to the internet.
This way it can still be flexible about preprocessing input and postprocessing output re: that CLI, and any secrets stay server-side and out of its reach.
Let it change the CLI and the server, but deploy the updated server by hand, that way you're in a position to review and if necessary prevent the agent from adding any capabilities that it shouldn't have.
MCP is nice, but does your agent use it without you explicitly asking it to do so?
From my experience, instructions in `.md` files aren't enough. In fact, Claude seems to prefer the shell over even its own built-in tools (e.g. `read`, `edit` etc.) See: https://github.com/anthropics/claude-code/issues/19649. It's like an old dog that needs to be tricked to learn new tricks.
Same experience for me. I routinely have to say "no, use the tool" or "no, read your skills." More frustrating than anything but I've definitely noticed models [1] struggling to grab the right tool without me steering it.
[1] Recently: Opus 4.7/4.8 and Kimi K3
or you can just wire everything up in the shell itself keeping it as simple as possible with one single tool
> or you can just wire everything up in the shell itself keeping it as simple as possible with one single tool
If I understand correctly, you’re not answering my question, and you’re not talking about MCP either. Have you considered that maybe you’re in the wrong thread?
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
I'm curious if LLM could easily be manipulated to actually process data in context and remove it from its context and replace it with the result or a hint.
Might break the caching, perhaps this can be solved with snapshot ids or cache ids like "Replacing context line 434-500 with hint; checking last request before that context even was added and running that cache before"
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.
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.
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.
MCP is even more important now in enterprise and thus the shift towards the streamable, stateless HTTP server implementation.
How well does that work in enterprise setups?
Well assuming a browser is able to access whatever enterprise thing, the LLM can emulate being one using apps like curl.
why is MCP a pain in Macos?
It isn't.
MCP over streamable HTTP is just JSON RPC payload over HTTP.
The internal interface for the ChatGPT app and Coded are all MCP based (stdio on local).
All enterprise AI rollout is eventually going to converge on MCP as a key piece of that infra because it can mask credentials behind one gateway that's easier to control and more secure.
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.
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.
1: https://swamp-club.com
I think this exists: https://github.com/imbue-ai/latchkey (and there are other similar projects, too).
NVidia Openshell maybe?
I love this question because of the diverse answers given and we learn from each other.
A proxy?
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".
What MCP really needs is standardized auth. There's maybe 10 different common ways to authenticate against MCP servers, and the average non-engineer can't read the docs to figure out how to configure it.
Companies can implement Individual Oauth with DCR (which makes it as easy as "log in with Google"), but many don't
To everyone saying "this is just REST": no. It's just RPC (in case "jsonrpc" in the payload didn't give it away).
If we're talking protocols, it's useful to know the distinction.
There have been many flame wars around REST vs RPC and whether most "RESTful" implementations out there are actually RPC with a funny nose.
> and then became somewhat eclipsed by Skills (another Anthropic invention)
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.
As more AI agents rely on MCP, stateless implementations seem like a natural fit for horizontal scaling. The remaining challenge is efficient context management, interested to see how different projects tackle that.
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.
MCPs are very exciting. They now support IFrames (MCP Apps) as well.
Now that the models are getting better, you can trust them to book barber appointments, order groceries, manage your calendar, etc etc. It's significantly lazier to ask an agent to do something than manually doing it. Especially with voice to text.
I'm predicting that chat bots will auto-discover MCPs from trusted websites and make life much easier.
I agree. The natural next step is to have an MCP for a global directory of MCPs that an agent can search to complete jobs.
The web_search tool and MCP discovery is essentially a global directory.
Now when I ask ChatGPT for a product, it does a web_search tool call and then gives me a link to a webshop product page. But next step would be automatically using the MCP of that webshop to embed checkout inside chat.
afaik Claude already has a "discovery" tool for official Claude connectors, that's why a lot of companies are rushing to get on the marketplaces. I know that bc I'm the founder of https://manufact.com and we helped a ton of companies with that.
It seems like the core value add of MCP as described here is text only documentation for an API, as opposed to the human standard of HTML-like docs.
Is that roughly accurate? We are talking about a technology that would allow SaaS API vendors to publish a second set of documentation (or adapt the same one to both human and LLM targetted channels)?
I'm being a bit cynical, but here's my minimal naïve alternative solution, not proposing it be used, but just saying that this would be equivalent:
1- Publish a well known endpoint like /docs_url , which could return something like "docs.domain".
2- Support an alternative content-type header, where instead of 'text/html' the client could ask for 'text/plain', or 'text/markdown'
2b- Alternatively, changing the extension type could achieve the same result, where requesting docs.domain/endpoint.txt would return the docs in text instead of in html
So now I ask, how is MCP better than the solution I proposed? Did I grossly misunderstand something? Or am I on track to avoiding hundreds of engineering hours due to accidental complexity by recognizing and avoiding a privately funded protocol that serves to increase vendor lock instead of reducing complexity of our systems?
Interesting that a date format is used for MCP-Protocol-Version. reply
I've started building MCP servers for some of my own projects as well. For example, I built one for a VIN decoder website so AI assistants can look up vehicle information directly instead of requiring users to switch back and forth between a chat and a browser. For me, that's the biggest appeal of MCP. It's not just another API wrapper—it makes existing tools much easier to use from within an AI workflow. The less context switching users have to do, the better the experience feels. The move toward a more stateless design also makes a lot of sense. Simpler deployment, easier horizontal scaling, and fewer session-management headaches are all welcome improvements for anyone running these services in production.
Question is - when is Claude going to adopt this new version?
Interesting that a date format is used for MCP-Protocol-Version.
I also wrote more about this: https://rohitghumare.com/blog/stateless-mcp/
Why was MCP ever stateful in the first place?
Oh, man. Again, people call MCP endpoints REST-ful when the format is JSON-RPC. That's why we can't have nice things.
The P in MCP stands for REST
I still think of MCP as "Master Control Program".
> older stateful MCP (I’m going to call it “legacy MCP”) required two HTTP requests
What? I never realized it was the case. I was calling my handcrafted MCP server without the header all the time!
wtf? Why didn't Simon use MCP Inspector? https://modelcontextprotocol.io/docs/2026-07-28/tools/inspec...
I feel like 5% of people who develop MCP Servers for a living and 10% of the people who develop MCP Clients for a living use the MCP Inspector and understand the Protocol.
As I said in my post:
> I find building CLI tools like this to be a really productive way to get familiar with a specification.
which is far from the best MCP inspector out there we hosted an online version of the mcp-use inspector which is pretty convenient: https://inspector.manufact.com/inspector
cli tools > mcps
who gives a shit about what this guy thinks?
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
There's never existed a state of MCP - it has always been the land of Judea
MCP is a stupid term, it makes no obvious sense what it does or what its for.
I propose AII - AI Interface. Lets make it happen!