back
225 comments
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.

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.

Skills definitely can pollute the context window. They can be verbose. You can have a very long list of advertised skills. You can try and hack around with skill execution inside of subagents etc but there is always a trade-off.
> Skills don’t pollute the context window and, skills are more flexible and composable.

they do but more importantly model does not give a flying fuck about what you put in there in any consistent way.

ppl have been mislead by ai companies that they've invented some sort of agi that you can 'explain' to using skills. So ppl have come up with also sorts of skills that dont do jack shit.

It's still not really an either or scenario. Skills will always serve a purpose as high level on demand contextual guidance. I think of MCPS as hard tools, api contracts etc. While the initial release gave them the ability to be contextual sources as well, I think that's now better served with skills, and mcps can focus on being repositories of functionality.
Skills and tools all need their contextual descriptions to be evolved using evals in order to be effective and efficient. Sounds like the Liner MCP could use with some of that.
For an MCP used to look up data in any kind of dataset, just having a single tool that accepts an OData Query string has worked well for me.
> Skills don’t pollute the context window

Of course they do. Do you really think that there's a magical bag of holding for the potentially infinite amount of skills?

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

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 results of a cli command through scripting or coding gives the agent a ton more flexibility in what it can do as it can utilize its text generation capability into executable logic. toolcalls mostly work for actions rather than complex and novel problem solving. You are making the agent represent a programming control flow through toolcalls while carrying the context between them in a lossy, nondeterministic, wasteful, slow and rigid way.

It’s one thing if you want to artificially limit that agent to a very strict set of available APIs that it must use in a specific way while transferring context between them through the LLM and you don’t want to incur the cost of the extra sandbox compute. But coding harnesses have demonstrated that letting the agent write a small shell or python script can let the agents solve problems that you haven’t even really anticipated in your toolcall approach or that tool calls make prohibitively expensive or not even possible.

But also the token cost tends to dwarf the sandbox compute cost, so why not pay the $0.05/hour to have a sandbox where the agent can run free when you are already paying orders of magnitude more for the tokens

The "CLI crowd" is also primarily using LLMs on their own computer. Where they have their CLI tools.

This doesn't cover the case when you're talking to an LLM from web, or via Slack or Linear, etc. There, you will want MCP so the LLM can use services on your behalf as you. That's portability.

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.

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

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

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?

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.
I still don't get MCP. Most likely because I didn't really check but the first feeling is creating a problem to solve a problem that doesn't exist in the first place.
Yeah, there's a ton of great improvements in 7-28. I'm personally excited about what you posted about, but also with [tasks](https://blog.modelcontextprotocol.io/posts/2026-07-28-releas...) being officially adopted.
> I couldn’t find a great CLI tool for interactively probing an MCP server

What about mcp-inspector? It’s a nice tool, can be used interactively, can be used as a CLI.

https://github.com/modelcontextprotocol/inspector

we invented a stateful protocol, discovered state is hard to scale, stripped it out, and arrived at "just send a POST request." the REST crowd has been smugly waiting for this moment for 20 years.
Hi Simon and HN checkout https://rmcp.dev - it's part of BuiltWith's MCP discovery and lets you sniff around all of the MCP servers (remote at least) that we've discovered - allowing you to connect to them etc. and see what they do. Thought it might be relevant vis your mcp-explorer.
Love using MCP, working on adding it as a first-class surface to products I’m developing. Agent experience is becoming as important or more than user importance for some products. Big fan of AgentCat and other tools for applying MCP observability - can't improve what you don't measure
It seems to me an alternative to MCP would be a shell implemented to only allow access to white listed commands.

I also feel like a lot of knowledge about how to lock down a multi-user system has been lost. Back when many people shared a single computer through terminals, admins had a lot of responsibility to create a permissions structure such that one user couldn't access another's data or hog too many resources that would impact other users on the system. We are running computers with the similar permission models (Mac and Linux are Unix, Windows has similar controls) but we can't manage to lock down shell access to trust an LLM with it as if it were a human user we don't fully trust.

> Giving an agent a shell environment with the ability to access the internet is fraught with risk

A good middle ground is to give it a shell environment with no access to the internet, but with standard tooling like python, perl, jq, and sed plus a custom CLI which can talk to a server which does have access to the internet.

This way it can still be flexible about preprocessing input and postprocessing output re: that CLI, and any secrets stay server-side and out of its reach.

Let it change the CLI and the server, but deploy the updated server by hand, that way you're in a position to review and if necessary prevent the agent from adding any capabilities that it shouldn't have.

I'm glad MCP is getting simpler

a few months ago I tried to implement an MCP server from scratch in python (instead of using the existing reference implementation) and I could not get it to work reliably across clients

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.

Stateless MCP was already possible before this and made sense for whole classes of use cases where it helps to have a remote fleet of servers.

Wrote about this back in March: https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/

MCP is going to be a foundational piece of enterprise agent infra.

Maybe someone could set up a CLI tool for agents such that you can give them a shell but they use this CLI tool instead of raw curl.

Like a tool where the AI can only call out to certain APIs based on a config file the agent cannot change.

That way you can leverage all the shell knowledge agents already have while still limiting what network calls they can make, and you wouldn't have to set up a server to use an agent.

I'm curious if LLM could easily be manipulated to actually process data in context and remove it from its context and replace it with the result or a hint.

Might break the caching, perhaps this can be solved with snapshot ids or cache ids like "Replacing context line 434-500 with hint; checking last request before that context even was added and running that cache before"

To everyone saying "this is just REST": no. It's just RPC (in case "jsonrpc" in the payload didn't give it away).

If we're talking protocols, it's useful to know the distinction.

There have been many flame wars around REST vs RPC and whether most "RESTful" implementations out there are actually RPC with a funny nose.

What MCP really needs is standardized auth. There's maybe 10 different common ways to authenticate against MCP servers, and the average non-engineer can't read the docs to figure out how to configure it.

Companies can implement Individual Oauth with DCR (which makes it as easy as "log in with Google"), but many don't

> and then became somewhat eclipsed by Skills (another Anthropic invention)

I thought it was The Browser Company’s invention?

https://claude.com/blog/skills

> Introducing Agent Skills

> October 16, 2025

I can find articles and Reddit posts about Dia Browser’s Skills from July 2025.

As more AI agents rely on MCP, stateless implementations seem like a natural fit for horizontal scaling. The remaining challenge is efficient context management, interested to see how different projects tackle that.
I createad an MCP server for my company I worked at for almost a year now with all Dynamic Client Registration (DCR). We just ignored the state as with most other MCPs wre doing it, just used it for logging.
MCPs are very exciting. They now support IFrames (MCP Apps) as well.

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

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?

Interesting that a date format is used for MCP-Protocol-Version. reply
Interesting that a date format is used for MCP-Protocol-Version.
Question is - when is Claude going to adopt this new version?
I also wrote more about this: https://rohitghumare.com/blog/stateless-mcp/
I've started building MCP servers for some of my own projects as well. For example, I built one for a VIN decoder website so AI assistants can look up vehicle information directly instead of requiring users to switch back and forth between a chat and a browser. For me, that's the biggest appeal of MCP. It's not just another API wrapper—it makes existing tools much easier to use from within an AI workflow. The less context switching users have to do, the better the experience feels. The move toward a more stateless design also makes a lot of sense. Simpler deployment, easier horizontal scaling, and fewer session-management headaches are all welcome improvements for anyone running these services in production.
Why was MCP ever stateful in the first place?
Oh, man. Again, people call MCP endpoints REST-ful when the format is JSON-RPC. That's why we can't have nice things.
I still think of MCP as "Master Control Program".
> older stateful MCP (I’m going to call it “legacy MCP”) required two HTTP requests

What? I never realized it was the case. I was calling my handcrafted MCP server without the header all the time!

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