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.
Stateless MCP has recaptured my interest
231–240 of 247 posts
Re: Stateless MCP has recaptured my interest
#232It 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.
Re: Stateless MCP has recaptured my interest
#233wtf? 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.
> I find building CLI tools like this to be a really productive way to get familiar with a specification.
Re: Stateless MCP has recaptured my interest
#234Re: Stateless MCP has recaptured my interest
#235It 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.
I wonder if part of it was the bias of how the chat apps work with the streaming maybe they use SSE But I wouldn't discount how uphill it was to probably even argue for something like MCP cause the labs still very scientist-driven and focused on solving everything in token space. The idea that tool use could be super transformative probably wasn't obvious from inside before Claude Code
Re: Stateless MCP has recaptured my interest
#236Earlier quoted context omitted.
Skills and MCP can be treated by the harness in the exact same way. What do you think is unique to skills that does not apply to how MCP servers are managed?
> What do you think is unique to skills that does not apply to how MCP servers are managed? I have a skill that describes my database schema with hundreds of tables, stored procedures, triggers at a high level. It tells the LLM to use a specific CLI to connect to the developer database using an account with read-only permissions. This skill has auto invocation turned off and uses zero tokens when not used. MCP apps d…
> MCP apps do not have a manual invocation option. If you enable them, they are always on, eating away tokens
This is not true of recent harnesses. They will not consume any tokens until the LLM searches for tools. Similar to how they handle skills, and that’s my point: they can and do manage tools and skills similarly. They could easily let you invoke tools explicitly as well , it’s maybe their choice not to.
> Output of an MCP tool call goes straight into context. Output of a CLI tool call can be filtered by the LLM using another tool, before it enters context.
That’s a good point, but this is not about MCP , it’s about tools in general. Tools can provide structured output which should allow for even more advanced usages by the LLM than a text-based CLI approach. However I haven’t seen that done yet and it could be a nice feature to address!
Re: Stateless MCP has recaptured my interest
#237Earlier quoted context omitted.
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 th…
Re: Stateless MCP has recaptured my interest
#238Earlier quoted context omitted.
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
#239Re: Stateless MCP has recaptured my interest
#240Earlier quoted context omitted.
Pi does support MCP through an excellent pi-mcp-adapter plugin.
Yes, I meant the decision to not support MCP by default without plugins, like Skills, could be revisited if it’s now efficient
Or you may choose another plugin that works differently.
That's the whole point of extensible systems like Pi or Emacs, you don't need to pray that maintainers will have the same vision as you, you just pick one of the many alternatives instead. Or ask pi to write one for you.