Stateless MCP has recaptured my interest • Hacker News Board

Re: Stateless MCP has recaptured my interest

#221

Post by bloppe » Wed, Aug 05, 2026, 5:34 PM UTC

speedgoose wrote: post #171

bloppe wrote: post #88

Earlier quoted context omitted.

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

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?

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.

Re: Stateless MCP has recaptured my interest

#222

Post by [deleted] » Wed, Aug 05, 2026, 5:40 PM UTC

neomantra wrote: post #160

wolttam wrote: post #141

Earlier quoted context omitted.

MCP is invisible to the LLM, or should be, under normal use

By this statement, do you mean that LLMs really just know about "Tool Calling Tokens" or something else?

[deleted]

Re: Stateless MCP has recaptured my interest

#223

Post by smrtinsert » Wed, Aug 05, 2026, 5:52 PM UTC

rutierut wrote: post #78

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…

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.

Re: Stateless MCP has recaptured my interest

#224

Post by troupo » Wed, Aug 05, 2026, 6:17 PM UTC

majormajor wrote: post #218

troupo wrote: post #137

Earlier quoted context omitted.

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.

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.

Re: Stateless MCP has recaptured my interest

#225

Post by sumitkumar » Wed, Aug 05, 2026, 6:19 PM UTC

wongarsu wrote: post #84

shermantanktop wrote: post #35

Earlier quoted context omitted.

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.

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.

Re: Stateless MCP has recaptured my interest

#226

Post by __MatrixMan__ » Wed, Aug 05, 2026, 6:35 PM UTC

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

Re: Stateless MCP has recaptured my interest

#227

Post by bloppe » Wed, Aug 05, 2026, 6:57 PM UTC

brabel wrote: post #136

bloppe wrote: post #93

Earlier quoted context omitted.

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

Re: Stateless MCP has recaptured my interest

#228

Post by luigipederzani » Wed, Aug 05, 2026, 7:30 PM UTC

MP_1729 wrote: post #185

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.

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

Re: Stateless MCP has recaptured my interest

#229

Post by luigipederzani » Wed, Aug 05, 2026, 7:33 PM UTC

whazor wrote: post #176

__alias wrote: post #161

Earlier quoted context omitted.

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.

Re: Stateless MCP has recaptured my interest

#230

Post by shermantanktop » Wed, Aug 05, 2026, 8:01 PM UTC

tibbe wrote: post #38

shermantanktop wrote: post #35

Earlier quoted context omitted.

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.