Live data from Hacker News

Stateless MCP has recaptured my interest

simonwillison.net

241–246 of 246 posts

Re: Stateless MCP has recaptured my interest

#241
post #237
post #227

Earlier quoted context omitted.

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?

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.

Re: Stateless MCP has recaptured my interest

#242

Earlier quoted context omitted.

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

Re: Stateless MCP has recaptured my interest

#243
post #192

Earlier quoted context omitted.

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.

Re: Stateless MCP has recaptured my interest

#244
post #166
post #94

Earlier quoted context omitted.

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?

Re: Stateless MCP has recaptured my interest

#245
post #52
post #12

Earlier quoted context omitted.

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.

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.

Re: Stateless MCP has recaptured my interest

#246
post #12

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.
Post reply on HN