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

151–160 of 246 posts

Re: Stateless MCP has recaptured my interest

#151

Post by ATMLOTTOBEER »

firasd wrote: post #11

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":…

These days even chatting on iOS you’re getting some “vm-esque” ability for the model to run python etc

They’re essentially provisioning you a temporary vm, so it’s morally equivalent to running cc on ur laptop and remote-controlling from the app, except worse

So if the LLM behind the scene has its own compute environment anyway, why not just use a cli?

This is imo what the cli crowd is actually assuming

Re: Stateless MCP has recaptured my interest

#152

Post by TZubiri »

It seems like the core value add of MCP as described here is text only documentation for an API, as opposed to the human standard of HTML-like docs.

Is that roughly accurate? We are talking about a technology that would allow SaaS API vendors to publish a second set of documentation (or adapt the same one to both human and LLM targetted channels)?

I'm being a bit cynical, but here's my minimal naïve alternative solution, not proposing it be used, but just saying that this would be equivalent:

1- Publish a well known endpoint like /docs_url , which could return something like "docs.domain".

2- Support an alternative content-type header, where instead of 'text/html' the client could ask for 'text/plain', or 'text/markdown'

2b- Alternatively, changing the extension type could achieve the same result, where requesting docs.domain/endpoint.txt would return the docs in text instead of in html

So now I ask, how is MCP better than the solution I proposed? Did I grossly misunderstand something? Or am I on track to avoiding hundreds of engineering hours due to accidental complexity by recognizing and avoiding a privately funded protocol that serves to increase vendor lock instead of reducing complexity of our systems?

Re: Stateless MCP has recaptured my interest

#153

Post by rglover »

alexaholic wrote: post #108

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.

Same experience for me. I routinely have to say "no, use the tool" or "no, read your skills." More frustrating than anything but I've definitely noticed models [1] struggling to grab the right tool without me steering it.

[1] Recently: Opus 4.7/4.8 and Kimi K3

Re: Stateless MCP has recaptured my interest

#154

Post by TZubiri »

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.

Maybe that's why they are being paid several hundred thousands of dollars. They get the new wave of programmers to implement their proprietary vendor locked protocol instead of industry standard protocols of the commons.

Re: Stateless MCP has recaptured my interest

#155

Post by block_dagger »

cheema33 wrote: post #103
Eldodi wrote: post #87

Earlier quoted context omitted.

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?

Use an MCP proxy.

Re: Stateless MCP has recaptured my interest

#156

Post by moduspol »

Eldodi wrote: post #86
drdexebtjl wrote: post #22

Earlier quoted context omitted.

I don’t think the “just use a CLI” crowd really are assuming you’re a developer in a coding harness. All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code. Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses…

- CLI tools don't have standardized auth, nor do they have granular tool permissions. MCP does - CLI tools need to access your secrets in your .env. With MCP the model never sees the secrets and refresh tokens. - CLI tools don't have auditing and telemetry. MCP provides all this for free. - CLI tools imply full bash access, a nightmare in terms of security and very costly if you have to spin up a machine for every re…

I'm not especially a fan of MCP but it also offers:

- Standardized input and output schemas for each tool

- Standardized annotations that indicate how potentially dangerous each tool can be (e.g. read-only, idempotent, publishes data visible to third parties)

- Extensions for UI widgets

Re: Stateless MCP has recaptured my interest

#158

Post by __alias »

Eldodi wrote: post #86
drdexebtjl wrote: post #22

Earlier quoted context omitted.

I don’t think the “just use a CLI” crowd really are assuming you’re a developer in a coding harness. All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code. Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses…

- CLI tools don't have standardized auth, nor do they have granular tool permissions. MCP does - CLI tools need to access your secrets in your .env. With MCP the model never sees the secrets and refresh tokens. - CLI tools don't have auditing and telemetry. MCP provides all this for free. - CLI tools imply full bash access, a nightmare in terms of security and very costly if you have to spin up a machine for every re…

Can you elaborate on the auditing and telemetry. I'm wondering what you mean by that and how it comes for free any differently from an cli

Re: Stateless MCP has recaptured my interest

#160

Post by neomantra »

wolttam wrote: post #141
lexicality wrote: post #105

Earlier quoted context omitted.

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

MCP is invisible to the LLM, or should be, under normal use

By this statement, do you mean that LLMs really just know about "Tool Calling Tokens" or something else?
Post reply on HN