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

101–110 of 246 posts

Re: Stateless MCP has recaptured my interest

#101

Post by tumetab1 »

zeafoamrun wrote: post #83
drdexebtjl wrote: post #16

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

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.

Re: Stateless MCP has recaptured my interest

#102

Post by fauigerzigerk »

eddythompson80 wrote: post #80
firasd wrote: post #23

Earlier quoted context omitted.

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

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.

Re: Stateless MCP has recaptured my interest

#103

Post by cheema33 »

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.

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?

Re: Stateless MCP has recaptured my interest

#104

Post by msdz »

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.

Is it also a solved problem for smaller models, as the article mentioned?

Re: Stateless MCP has recaptured my interest

#105

Post by lexicality »

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.

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.

Re: Stateless MCP has recaptured my interest

#106

Post by nicc047 »

panghy wrote: post #68
bloppe wrote: post #32

Earlier quoted context omitted.

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

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…

I think by now even non-technical vibe coders have enough of an overview on REST APIs

Re: Stateless MCP has recaptured my interest

#107

Post by ai_critic »

pjmlp wrote: post #97
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.

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

Re: Stateless MCP has recaptured my interest

#108

Post by alexaholic »

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.

Re: Stateless MCP has recaptured my interest

#109

Post by [deleted] »

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.

[deleted]

Re: Stateless MCP has recaptured my interest

#110

Post by cheema33 »

SyneRyder wrote: post #76
cheema33 wrote: post #48

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

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

Post reply on HN