Stateless MCP has recaptured my interest

Join the discussion

• Hacker News
• But 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.
  by cush
• 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?

  by cheema33
• In our startup, we build harness that allows people to call endpoints like the ones that MCP supports. we looked it as 2 class of problems. One is sources like databases where the protocol is not http/json/rpc. Here we support MCP based calling. then there are ones where the protocol is just http/json/rpc - say calling shopify or linear or others. Now the harness itself comes with a generic http execution engine. So if you know the endpoint, auth and operation - the harness converts this into a yaml structure for internal purpose and directly calls the endpoint. all info that LLM needs like how the endpoints are, what can be passed and how to check response etc., is all english defined and stored in yaml. Now the harness uses this info to expose these to LLM and when LLM wants to makes a tool call that needs to call the http endpoint the http engine in the harness executes it on behalf of it and gives response back to LLM. this way every server dont have to expose and maintain an MCP server to expose them to LLM. allow us to connect to any endpoint and teams dont have to maintain and scale one more info.

  Not sure whats the downside of this approach is but its serving us well so far.

  by mailmrg
• Next he’ll discover that it’s useful for MCP abilities to be organized by resource and a limited set of actions you could perform on those resources, like getting the resource, posting a new resource, patching an existing resource, or deleting the resource. We’ll call it: Resource Oriented Stateless Transformation MCP or ROST-MCP for short.
  by an0malous
• 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).

  by drdexebtjl
• 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.

  by ai_critic
• I 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": "text",
            "text": "[\n  {\n    \"timezone\": \"UTC\",\n    \"iso\": \"2026-08-05T04:44:41.707Z\",\n    \"unixtime\": 1785905081\n  },\n  {\n    \"timezone\": \"Alphadec\",\n    \"alphadec\": \"2026_P4A0_466322\"\n  }\n]"
          }]},"jsonrpc": "2.0", "id": 1}
  

  The "just use a CLI" crowd is implicitly assuming:

  1) You're a developer 2) On a laptop 3) With a shell open inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project

  That's maybe 2% of AI usage.

  The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...

  by firasd
• 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 and provide 32 MCP tools as a result of that. My agents do run into composability problems here all the time and fall back to the tool they included which allows you to run arbitrary GraphQL. This takes a couple tries usually. I don’t really know what the sensible alternative to this is.

  Cloudflare switched to “code mode” which basically provides 2 MCP tools: search and execute. Both take a TS arrow function, the first allows you to programmatically search a TS api spec, the second to compose and run the methods in that spec.

  I think this is a very interesting approach, and certainly better than providing the ~1000 actions as MCP tools but I feel the jury is still out on exactly how well this pans out.

  by rutierut