Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stateless MCP has recaptured my interest

simonwillison.net

Post reply on HN
Print view View original

181–190 of 246 posts

Re: Stateless MCP has recaptured my interest

#181

Post by mi_lk »

Eldodi wrote: post #87
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…

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.

Interesting, then I wonder if Pi having Skills support but not MCP support by default still makes sense

Re: Stateless MCP has recaptured my interest

#184

Post by drdexebtjl »

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…

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.

Re: Stateless MCP has recaptured my interest

#186

Post by MP_1729 »

ai_critic wrote: post #50

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.

The Protocol is from the Linux Foundation

Re: Stateless MCP has recaptured my interest

#187

Post by drdexebtjl »

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?

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.

Re: Stateless MCP has recaptured my interest

#188

Post by lbourdages »

blitzar wrote: post #148
lbourdages wrote: post #147

Earlier quoted context omitted.

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.

Re: Stateless MCP has recaptured my interest

#189

Post by backscratches »

brabel wrote: post #132
acchow wrote: post #13

Earlier quoted context omitted.

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.

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?

Re: Stateless MCP has recaptured my interest

#190

Post by MomsAVoxell »

ai_critic wrote: post #50

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.

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

Post reply on HN