Stateless MCP has recaptured my interest
91–100 of 246 posts
Re: Stateless MCP has recaptured my interest
#92But is it composable like cli? The main issue to be with MCP is the entire response ends up in the context window. Whereas a decent harness and agent is usually going to pipe together and filter many tools in one long command without spending all the extra tokens.
> code_execution tool - uses monty to run an interpreter that has all other tools available as async functions. Maki uses it to filter / summarize / transform / pipe data to other tools as input, without it ever reaching and polluting the context window. Sandbox limited by time & memory.
Failing that, you can just disable native MCP in your harness and have your agent use a CLI tool that calls MCP, like mcp-cli [1], and then the agent can use regular unix pipes to filter or transform the output. Here, rather than raw grep or sed (which are line oriented), the agent would probably use things like jq.
Re: Stateless MCP has recaptured my interest
#93Earlier quoted context omitted.
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…
The user experience for a rest api and for mcp can be the same. For MCP, you have to give the mcp server url. For REST, you could provide a url to the openapi spec. The open API spec has everything you'd need - oauth url + all the endpoints and params. Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the G…
Re: Stateless MCP has recaptured my interest
#94It 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.
Re: Stateless MCP has recaptured my interest
#95I think stateless-type MCP was already possible, eg my MCP Clock [ https://github.com/firasd/mcpclock ]: > curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/call","params":{"name":"clock_get","arguments":{}}}' | grep '^data:' | sed 's/^data: //'| jq {"result": {"content": [{"type":…
I think part of the “just use a CLI” crowd might also be building similar agents as ChatGPT and Claude.ai web interface. I know at least 4 teams doing that in one company. All those teams, including ChatGPT and Claude.ai, have figured out that you will eventually need to give your agent a small sandbox Linux environment to unlock the same level of “intelligence“ those coding harness exhibit. Stitching together the re…
Re: Stateless MCP has recaptured my interest
#96In 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?
Re: Stateless MCP has recaptured my interest
#97It 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 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.
Re: Stateless MCP has recaptured my interest
#98Earlier quoted context omitted.
The user experience for a rest api and for mcp can be the same. For MCP, you have to give the mcp server url. For REST, you could provide a url to the openapi spec. The open API spec has everything you'd need - oauth url + all the endpoints and params. Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the G…
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?
Re: Stateless MCP has recaptured my interest
#99It 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.
Re: Stateless MCP has recaptured my interest
#100Now that the models are getting better, you can trust them to book barber appointments, order groceries, manage your calendar, etc etc. It's significantly lazier to ask an agent to do something than manually doing it. Especially with voice to text.
I'm predicting that chat bots will auto-discover MCPs from trusted websites and make life much easier.