Live data from Hacker News

Stateless MCP has recaptured my interest

simonwillison.net

231–240 of 247 posts

Re: Stateless MCP has recaptured my interest

#231
post #97

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 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.

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.

Re: Stateless MCP has recaptured my interest

#232
post #97

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 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.

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.

Re: Stateless MCP has recaptured my interest

#233

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.

Re: Stateless MCP has recaptured my interest

#234
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.

Re: Stateless MCP has recaptured my interest

#235
post #62

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.

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

Re: Stateless MCP has recaptured my interest

#236
post #138

Earlier quoted context omitted.

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 d…

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!

Re: Stateless MCP has recaptured my interest

#237
post #227
post #136

Earlier quoted context omitted.

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 t…

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 th…

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?

Re: Stateless MCP has recaptured my interest

#238
post #132

Earlier quoted context omitted.

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??

Re: Stateless MCP has recaptured my interest

#239
post #238

Earlier quoted context omitted.

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.

Re: Stateless MCP has recaptured my interest

#240
post #217

Earlier quoted context omitted.

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.

Post reply on HN