11 ms·

Stateless MCP has recaptured my interest

386 points by tosh 3mo ago

brianjking 3mo ago
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-release-candidate/#tasks-graduates-to-an-extension https://blog.modelcontextprotocol.io/posts/2026-07-28-releas...) being officially adopted.
ameshkov 3mo ago
> 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 https://github.com/modelcontextprotocol/inspector
- simonw 3mo ago
  The documentation for the --cli mode is a bit lacking, but I got there in the end: npx @modelcontextprotocol/inspector --cli \ https://agentic-mermaid.dev/mcp \ --method tools/call \ --tool-name render_svg \ --tool-args-json '{"source":"graph TD; A-->B","options":{"padding":24}}' Equivalent with my mcp-explorer tool: uvx mcp-explorer call \ https://agentic-mermaid.dev/mcp render_svg \ -a source 'graph TD; A-->B' \ -a options '{"padding":24}' So yeah, they're pretty similar. Then for my list command: uvx mcp-explorer list https://agentic-mermaid.dev/mcp With the inspector one you would do: npx @modelcontextprotocol/inspector --cli \ https://agentic-mermaid.dev/mcp \ --method tools/list Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.
- hobofan 3mo ago
  I would generally agree, but a word of caution for anyone trying it out from this thread: Try the latest pre 2.x version. The 2.0.0 that was released last week is highly broken even for some of the most common connection scenarios.
- evalstate 3mo ago
  fast-agent is very good at this (disclosure: author) you can specify --url, --npx and include --auth $TOKEN on the command line. you can also interactively connect with /connect, and pixel peep transport details https://fast-agent.ai/mcp/mcp-inspect-transport/ https://fast-agent.ai/mcp/mcp-inspect-transport/
tosh 3mo ago
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
pianopatrick 3mo ago
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.
- parf02 3mo ago
  A proxy?
  - pianopatrick 3mo ago
    Maybe. I'm just spitballing but as I've been thinking about this, maybe just like a set of shell scripts. The idea could be that the agent runs as a unix user. That user has execute access to these scripts but not read or write access. So the agent can only do what those scripts allow, the scripts present an API. You could let agents call the scripts with -h to get instructions, and just put some text into context saying like "to access helper scripts call ./showHelp".
- Wuzzy 3mo ago
  I think this exists: https://github.com/imbue-ai/latchkey https://github.com/imbue-ai/latchkey (and there are other similar projects, too).
- nickstinemates 3mo ago
  This is basically what Swamp is[1]. You give an agent a typed interface to extend itself (or use other peoples extensions) into the systems you need to fulfill your request. Think of it like on-demand tool calls. Then it records everything that happens in the swamp. The swamp can be single machine, multi-machine, or centralized with your co-workers. As a result, everything compounds. The work I do doesn't need to be re-derived by the work you do. Typed models keep everything repeatable and deterministic. Huge reduction in token spend and huge increase in speed. 1: https://swamp-club.com https://swamp-club.com
- deleted 3mo ago
CharlieDigital 3mo ago
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/ https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ MCP is going to be a foundational piece of enterprise agent infra.
- hchja 3mo ago
  MCP was much more important when agents weren’t able to accurately make tool calls. Nowadays, these agents are more capable and I think you can replace MCP (which is a pain on macOS), with simple CLI tools and expose them to agents via system prompt, skills, or other API documentation.
  - spike021 3mo ago
    How well does that work in enterprise setups?
    - charcircuit 3mo ago
      Well assuming a browser is able to access whatever enterprise thing, the LLM can emulate being one using apps like curl.
  - rixed 3mo ago
    why is MCP a pain in Macos?
    - CharlieDigital 3mo ago
      It isn't. MCP over streamable HTTP is just JSON RPC payload over HTTP. The internal interface for the ChatGPT app and Coded are all MCP based (stdio on local). All enterprise AI rollout is eventually going to converge on MCP as a key piece of that infra because it can mask credentials behind one gateway that's easier to control and more secure.
  - 3mo ago
firasd 3mo ago
I think stateless-type MCP was already possible, eg my MCP Clock [https://github.com/firasd/mcpclock 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...
- acchow 3mo ago
  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.
  - drdexebtjl 3mo ago
    Why can’t the LLM you’re talking to on the web have access to your CLI tools? When you talk to an LLM on the web, the harnesses spin up a fresh environment (I would hope it’s a VM…) so that the LLM can do stuff like run arbitrary Python and Bash scripts to complete the task you asked it for. There’s no reason why you shouldn’t be able to customize this environment to add whatever CLI tools and credentials you need for the agent to act on your behalf. The UX would be exactly the same.
    - 3mo ago
drdexebtjl 3mo ago
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).
- pjmlp 3mo ago
  Something that anyone doing distributed systems knows after a few scars, stateless servers are always better, and stateful only if there is no way around it. I learnt this with Sun RPC and the whole "The network is the computer". Somehow this keeps having to be relearnt.
  - shermantanktop 3mo ago
    I keep encountering mistakes by people who are convinced that agentic interactions are nothing new, that all the decades of hard-won lessons about service API design are 100% relevant and nothing more is needed, that agents can be relegated to the role of just-another-caller and left to the dismal domain of client developers. It’s not true. It’s not totally untrue, but don’t hide your head in the sand.
    - tibbe 3mo ago
      You didn't provide any arguments to support your claim. Calling people names isn't going to convince anyone.
      - shermantanktop 3mo ago
        Okay, here’s one I’m working through. When the workload consists of compound elements in multiple domains, agents work best when they see that as a flat surface of detailed resources. Traditional APIs work best when they hide the implementation details behind an ergonomic api. So service API developers want to abstract and hide, over and over, and this means agents have less and less context and do more guessing.
    - 3mo ago
deleted 3mo ago
[deleted]
cush 3mo ago
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.
- nextaccountic 3mo ago
  That's a harness concern, not a protocol concern. For example, maki [0] allows that automatically for all tools > 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. [0] https://github.com/tontinton/maki#context-efficiency https://github.com/tontinton/maki#context-efficiency [1] https://github.com/philschmid/mcp-cli https://github.com/philschmid/mcp-cli
- olmo23 3mo ago
  You can compose them if you allow the AI to evaluate code, and give it the proper APIs. Not much changes in this regard afaict.
luciana1u 3mo ago
[flagged]
Foobar8568 3mo ago
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.
- mmasu 3mo ago
  In enterprise MCP allows users to access resources that could either be unsafe or impractical to consume via API or CLI. It is a powerful pattern, supported by virtually all clients (Cursor, Claude Code, Codex, whatever) and easily implemented in custom harnesses. If you don’t need it you don’t, but it has many useful applications. Stateless will make it a lot more practical to expand applications.
  - cheeze 3mo ago
    What is an example of something that is unsafe to consume via API or CLI? Isn't MCP _an API_?
    - PetahNZ 3mo ago
      Its more targeted? Sure I can allow an LLM to access CLI, but then it will try to pipe to other command, write scripts etc. MCP is simply request/response. Its not really that technically different, but the way you and LLMs interact with it allows for easier control. IMHO.
    - progbits 3mo ago
      It is. MCP serves a single purpose: If you ask some company for API support for some stuff you can do via web UI but not API, they might say no for many reasons. But when you ask for MCP, suddenly you trigger AI FOMO and it will be available right away.
    - lexandstuff 3mo ago
      Yes, MCP is an API. Previously, it was an API with a weird stateful standard; now it is essentially a bog-standard stateless JSON-RPC API with conventions for tool discovery, long-running tasks and multi-round-trip requests If you wrote your own JSON-RPC API for an LLM, you would probably eventually end up with something that looks very much like the standard they're describing.
stpedgwdgfhgdd 3mo ago
Interesting that a date format is used for MCP-Protocol-Version.
cheema33 3mo ago
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?
- hahahaa 3mo ago
  Yes run a side agent to evaluate if they are needed. I am guessing keeping them all in every request is cache efficient though.
- SyneRyder 3mo ago
  > Most MCP servers still bloat up my context... Modern harnesses don't do that, MCP is also progressive disclosure now. MCP tool descriptions aren't included anymore, and have to be found via tool_search. I actually find that to be a regression. Sometimes the models will start coding a python script for something that is already available via a pre-compiled MCP tool call. In Claude Code you can enable / disable MCP servers at will, just use the /mcp command. You can also lock down permissions in claude -p headless mode to individual tools within an MCP server (eg maybe you only want to allow the reading tools, and none of the write-enabled tools for your automated session).
  - cheema33 3mo ago
    > Modern harnesses don't do that, MCP is also progressive disclosure now. Last time I checked, and it may be different now, Claude Code used tool search only if context usage was greater than 10%. Also, even with tool search, MCP uses about 1000 to 3000 tokens. A skill frontmatter on the other hand can be around 50. And an mcp tool call result gets dumped into context in its entirety. A cli too can be filtered with grep/sed etc. Skills are just a lot more efficient for most use cases.
    - brabel 3mo ago
      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?
joshsyn 3mo ago
[dead]
ai_critic 3mo ago
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.
- hahahaa 3mo ago
  I had to double take and say "I coulda dun that!!"
- firasd 3mo ago
  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
  - desktopentree 3mo ago
    the deployment targets that got cheap over the last five years are all stateless and a protocol that fights that gets no serverless implementations
- fergie 3mo ago
  It does seem like a return to RPC/REST over HTTP (maybe I am missing some subtleties), which makes sense to me since I never really understood the advantage that MCP bestowed.
  - vidarh 3mo ago
    The core advantage MCP gave you was a standard that by virtue of being blessed by AI providers people had strong incentives to actually implement.
    - fergie 3mo ago
deleted 3mo ago
[deleted]
mailmrg 3mo ago
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.
- bkaraaslan 3mo ago
  can postgREST be helpful for this? Clickhouse also has an http endpoint to send queries
- deleted 3mo ago
  [deleted]
- mailmrg 3mo ago
  we havent done postgres as endppoint. we were worried abt performance but may be we will consider. this also avoid the problem of running curl in shell (no shell access is given) and validations are done before its being sent - like call parameters, check for injections with standard libraries etc., so we dont have to worry abt the quality of existing MCP servers.
CSDude 3mo ago
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.
garazy 3mo ago
Hi Simon and HN checkout https://rmcp.dev 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.
SoKamil 3mo ago
> and then became somewhat eclipsed by Skills (another Anthropic invention) I thought it was The Browser Company’s invention? https://claude.com/blog/skills 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.
rutierut 3mo ago
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.
- Eldodi 3mo ago
  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.
  - cheema33 3mo ago
    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?
    - Eldodi 3mo ago
      you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
      - cheema33 3mo ago
liesliy 3mo ago
[flagged]
nirbendavid 3mo ago
[flagged]
whazor 3mo ago
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.
- __alias 3mo ago
  I agree. The natural next step is to have an MCP for a global directory of MCPs that an agent can search to complete jobs.
  - whazor 3mo ago
    The web_search tool and MCP discovery is essentially a global directory. Now when I ask ChatGPT for a product, it does a web_search tool call and then gives me a link to a webshop product page. But next step would be automatically using the MCP of that webshop to embed checkout inside chat.
    - luigipederzani 3mo ago
      afaik Claude already has a "discovery" tool for official Claude connectors, that's why a lot of companies are rushing to get on the marketplaces. I know that bc I'm the founder of https://manufact.com https://manufact.com and we helped a ton of companies with that.
alexaholic 3mo ago
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 https://github.com/anthropics/claude-code/issues/19649. It's like an old dog that needs to be tricked to learn new tricks.
- 0xAstro 3mo ago
  or you can just wire everything up in the shell itself keeping it as simple as possible with one single tool
  - alexaholic 3mo ago
    > or you can just wire everything up in the shell itself keeping it as simple as possible with one single tool If I understand correctly, you’re not answering my question, and you’re not talking about MCP either. Have you considered that maybe you’re in the wrong thread?
- rglover 3mo ago
  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
nesarkvechnep 3mo ago
Oh, man. Again, people call MCP endpoints REST-ful when the format is JSON-RPC. That's why we can't have nice things.
- alansaber 3mo ago
  The P in MCP stands for REST
Satoshi_Bro 3mo ago
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.
gjvc 3mo ago
who gives a shit about what this guy thinks?
senko 3mo ago
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.
schnebbau 3mo ago
MCP is a stupid term, it makes no obvious sense what it does or what its for. I propose AII - AI Interface. Lets make it happen!
MSAII 3mo ago
Interesting that a date format is used for MCP-Protocol-Version. reply
TZubiri 3mo ago
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?
byterivet 3mo ago
[dead]
thinkindie 3mo ago
Question is - when is Claude going to adopt this new version?
fosterfriends 3mo ago
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
est 3mo ago
> 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!
fenestella 3mo ago
[flagged]
rowanadeyemi 3mo ago
[flagged]
an0malous 3mo ago
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.
- gdhkgdhkvff 3mo ago
  Boom. ROST’d.
rohitghumare 3mo ago
I also wrote more about this: https://rohitghumare.com/blog/stateless-mcp/ https://rohitghumare.com/blog/stateless-mcp/
jake-coworker 3mo ago
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
heyitsmedotjayb 3mo ago
There's never existed a state of MCP - it has always been the land of Judea
Yopolo 3mo ago
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"
guluarte 3mo ago
cli tools > mcps
lukelabs 3mo ago
[flagged]
MP_1729 3mo ago
wtf? Why didn't Simon use MCP Inspector? https://modelcontextprotocol.io/docs/2026-07-28/tools/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.
- luigipederzani 3mo ago
  which is far from the best MCP inspector out there we hosted an online version of the mcp-use inspector which is pretty convenient: https://inspector.manufact.com/inspector https://inspector.manufact.com/inspector
- simonw 3mo ago
  As I said in my post: > I find building CLI tools like this to be a really productive way to get familiar with a specification.
mikeegg1 3mo ago
I still think of MCP as "Master Control Program".
jimbokun 3mo ago
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.
abratabia 3mo ago
[flagged]
winqing 3mo ago
[flagged]
jrochkind1 3mo ago
Why was MCP ever stateful in the first place?
__MatrixMan__ 3mo ago
> 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.
Roselol 3mo ago
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.

386 points by tosh 3mo ago

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-release-candidate/#tasks-graduates-to-an-extension https://blog.modelcontextprotocol.io/posts/2026-07-28-releas...) being officially adopted.

ameshkov 3mo ago

> 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 https://github.com/modelcontextprotocol/inspector

simonw 3mo ago
The documentation for the --cli mode is a bit lacking, but I got there in the end: npx @modelcontextprotocol/inspector --cli \ https://agentic-mermaid.dev/mcp \ --method tools/call \ --tool-name render_svg \ --tool-args-json '{"source":"graph TD; A-->B","options":{"padding":24}}' Equivalent with my mcp-explorer tool: uvx mcp-explorer call \ https://agentic-mermaid.dev/mcp render_svg \ -a source 'graph TD; A-->B' \ -a options '{"padding":24}' So yeah, they're pretty similar. Then for my list command: uvx mcp-explorer list https://agentic-mermaid.dev/mcp With the inspector one you would do: npx @modelcontextprotocol/inspector --cli \ https://agentic-mermaid.dev/mcp \ --method tools/list Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.
hobofan 3mo ago
I would generally agree, but a word of caution for anyone trying it out from this thread: Try the latest pre 2.x version. The 2.0.0 that was released last week is highly broken even for some of the most common connection scenarios.
evalstate 3mo ago
fast-agent is very good at this (disclosure: author) you can specify --url, --npx and include --auth $TOKEN on the command line. you can also interactively connect with /connect, and pixel peep transport details https://fast-agent.ai/mcp/mcp-inspect-transport/ https://fast-agent.ai/mcp/mcp-inspect-transport/

tosh 3mo ago

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

pianopatrick 3mo ago

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.

parf02 3mo ago
A proxy?
- pianopatrick 3mo ago
  Maybe. I'm just spitballing but as I've been thinking about this, maybe just like a set of shell scripts. The idea could be that the agent runs as a unix user. That user has execute access to these scripts but not read or write access. So the agent can only do what those scripts allow, the scripts present an API. You could let agents call the scripts with -h to get instructions, and just put some text into context saying like "to access helper scripts call ./showHelp".
Wuzzy 3mo ago
I think this exists: https://github.com/imbue-ai/latchkey https://github.com/imbue-ai/latchkey (and there are other similar projects, too).
nickstinemates 3mo ago
This is basically what Swamp is[1]. You give an agent a typed interface to extend itself (or use other peoples extensions) into the systems you need to fulfill your request. Think of it like on-demand tool calls. Then it records everything that happens in the swamp. The swamp can be single machine, multi-machine, or centralized with your co-workers. As a result, everything compounds. The work I do doesn't need to be re-derived by the work you do. Typed models keep everything repeatable and deterministic. Huge reduction in token spend and huge increase in speed. 1: https://swamp-club.com https://swamp-club.com
deleted 3mo ago

CharlieDigital 3mo ago

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/ https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ MCP is going to be a foundational piece of enterprise agent infra.

hchja 3mo ago
MCP was much more important when agents weren’t able to accurately make tool calls. Nowadays, these agents are more capable and I think you can replace MCP (which is a pain on macOS), with simple CLI tools and expose them to agents via system prompt, skills, or other API documentation.
- spike021 3mo ago
  How well does that work in enterprise setups?
  - charcircuit 3mo ago
    Well assuming a browser is able to access whatever enterprise thing, the LLM can emulate being one using apps like curl.
- rixed 3mo ago
  why is MCP a pain in Macos?
  - CharlieDigital 3mo ago
    It isn't. MCP over streamable HTTP is just JSON RPC payload over HTTP. The internal interface for the ChatGPT app and Coded are all MCP based (stdio on local). All enterprise AI rollout is eventually going to converge on MCP as a key piece of that infra because it can mask credentials behind one gateway that's easier to control and more secure.
- 3mo ago

firasd 3mo ago

I think stateless-type MCP was already possible, eg my MCP Clock [https://github.com/firasd/mcpclock 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...

acchow 3mo ago
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.
- drdexebtjl 3mo ago
  Why can’t the LLM you’re talking to on the web have access to your CLI tools? When you talk to an LLM on the web, the harnesses spin up a fresh environment (I would hope it’s a VM…) so that the LLM can do stuff like run arbitrary Python and Bash scripts to complete the task you asked it for. There’s no reason why you shouldn’t be able to customize this environment to add whatever CLI tools and credentials you need for the agent to act on your behalf. The UX would be exactly the same.
  - 3mo ago

drdexebtjl 3mo ago

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

pjmlp 3mo ago
Something that anyone doing distributed systems knows after a few scars, stateless servers are always better, and stateful only if there is no way around it. I learnt this with Sun RPC and the whole "The network is the computer". Somehow this keeps having to be relearnt.
- shermantanktop 3mo ago
  I keep encountering mistakes by people who are convinced that agentic interactions are nothing new, that all the decades of hard-won lessons about service API design are 100% relevant and nothing more is needed, that agents can be relegated to the role of just-another-caller and left to the dismal domain of client developers. It’s not true. It’s not totally untrue, but don’t hide your head in the sand.
  - tibbe 3mo ago
    You didn't provide any arguments to support your claim. Calling people names isn't going to convince anyone.
    - shermantanktop 3mo ago
      Okay, here’s one I’m working through. When the workload consists of compound elements in multiple domains, agents work best when they see that as a flat surface of detailed resources. Traditional APIs work best when they hide the implementation details behind an ergonomic api. So service API developers want to abstract and hide, over and over, and this means agents have less and less context and do more guessing.
  - 3mo ago

deleted 3mo ago

[deleted]

cush 3mo ago

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.

nextaccountic 3mo ago
That's a harness concern, not a protocol concern. For example, maki [0] allows that automatically for all tools > 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. [0] https://github.com/tontinton/maki#context-efficiency https://github.com/tontinton/maki#context-efficiency [1] https://github.com/philschmid/mcp-cli https://github.com/philschmid/mcp-cli
olmo23 3mo ago
You can compose them if you allow the AI to evaluate code, and give it the proper APIs. Not much changes in this regard afaict.

luciana1u 3mo ago

[flagged]

Foobar8568 3mo ago

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.

mmasu 3mo ago
In enterprise MCP allows users to access resources that could either be unsafe or impractical to consume via API or CLI. It is a powerful pattern, supported by virtually all clients (Cursor, Claude Code, Codex, whatever) and easily implemented in custom harnesses. If you don’t need it you don’t, but it has many useful applications. Stateless will make it a lot more practical to expand applications.
- cheeze 3mo ago
  What is an example of something that is unsafe to consume via API or CLI? Isn't MCP _an API_?
  - PetahNZ 3mo ago
    Its more targeted? Sure I can allow an LLM to access CLI, but then it will try to pipe to other command, write scripts etc. MCP is simply request/response. Its not really that technically different, but the way you and LLMs interact with it allows for easier control. IMHO.
  - progbits 3mo ago
    It is. MCP serves a single purpose: If you ask some company for API support for some stuff you can do via web UI but not API, they might say no for many reasons. But when you ask for MCP, suddenly you trigger AI FOMO and it will be available right away.
  - lexandstuff 3mo ago
    Yes, MCP is an API. Previously, it was an API with a weird stateful standard; now it is essentially a bog-standard stateless JSON-RPC API with conventions for tool discovery, long-running tasks and multi-round-trip requests If you wrote your own JSON-RPC API for an LLM, you would probably eventually end up with something that looks very much like the standard they're describing.

stpedgwdgfhgdd 3mo ago

Interesting that a date format is used for MCP-Protocol-Version.

cheema33 3mo ago

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?

hahahaa 3mo ago
Yes run a side agent to evaluate if they are needed. I am guessing keeping them all in every request is cache efficient though.
SyneRyder 3mo ago
> Most MCP servers still bloat up my context... Modern harnesses don't do that, MCP is also progressive disclosure now. MCP tool descriptions aren't included anymore, and have to be found via tool_search. I actually find that to be a regression. Sometimes the models will start coding a python script for something that is already available via a pre-compiled MCP tool call. In Claude Code you can enable / disable MCP servers at will, just use the /mcp command. You can also lock down permissions in claude -p headless mode to individual tools within an MCP server (eg maybe you only want to allow the reading tools, and none of the write-enabled tools for your automated session).
- cheema33 3mo ago
  > Modern harnesses don't do that, MCP is also progressive disclosure now. Last time I checked, and it may be different now, Claude Code used tool search only if context usage was greater than 10%. Also, even with tool search, MCP uses about 1000 to 3000 tokens. A skill frontmatter on the other hand can be around 50. And an mcp tool call result gets dumped into context in its entirety. A cli too can be filtered with grep/sed etc. Skills are just a lot more efficient for most use cases.
  - brabel 3mo ago
    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?

joshsyn 3mo ago

[dead]

ai_critic 3mo ago

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.

hahahaa 3mo ago
I had to double take and say "I coulda dun that!!"
firasd 3mo ago
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
- desktopentree 3mo ago
  the deployment targets that got cheap over the last five years are all stateless and a protocol that fights that gets no serverless implementations
fergie 3mo ago
It does seem like a return to RPC/REST over HTTP (maybe I am missing some subtleties), which makes sense to me since I never really understood the advantage that MCP bestowed.
- vidarh 3mo ago
  The core advantage MCP gave you was a standard that by virtue of being blessed by AI providers people had strong incentives to actually implement.
  - fergie 3mo ago

deleted 3mo ago

[deleted]

mailmrg 3mo ago

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.

bkaraaslan 3mo ago
can postgREST be helpful for this? Clickhouse also has an http endpoint to send queries
deleted 3mo ago
[deleted]
mailmrg 3mo ago
we havent done postgres as endppoint. we were worried abt performance but may be we will consider. this also avoid the problem of running curl in shell (no shell access is given) and validations are done before its being sent - like call parameters, check for injections with standard libraries etc., so we dont have to worry abt the quality of existing MCP servers.

CSDude 3mo ago

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.

garazy 3mo ago

Hi Simon and HN checkout https://rmcp.dev 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.

SoKamil 3mo ago

> and then became somewhat eclipsed by Skills (another Anthropic invention) I thought it was The Browser Company’s invention? https://claude.com/blog/skills 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.

rutierut 3mo ago

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.

Eldodi 3mo ago
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.
- cheema33 3mo ago
  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?
  - Eldodi 3mo ago
    you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
    - cheema33 3mo ago

liesliy 3mo ago

[flagged]

nirbendavid 3mo ago

[flagged]

whazor 3mo ago

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.

__alias 3mo ago
I agree. The natural next step is to have an MCP for a global directory of MCPs that an agent can search to complete jobs.
- whazor 3mo ago
  The web_search tool and MCP discovery is essentially a global directory. Now when I ask ChatGPT for a product, it does a web_search tool call and then gives me a link to a webshop product page. But next step would be automatically using the MCP of that webshop to embed checkout inside chat.
  - luigipederzani 3mo ago
    afaik Claude already has a "discovery" tool for official Claude connectors, that's why a lot of companies are rushing to get on the marketplaces. I know that bc I'm the founder of https://manufact.com https://manufact.com and we helped a ton of companies with that.

alexaholic 3mo ago

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 https://github.com/anthropics/claude-code/issues/19649. It's like an old dog that needs to be tricked to learn new tricks.

0xAstro 3mo ago
or you can just wire everything up in the shell itself keeping it as simple as possible with one single tool
- alexaholic 3mo ago
  > or you can just wire everything up in the shell itself keeping it as simple as possible with one single tool If I understand correctly, you’re not answering my question, and you’re not talking about MCP either. Have you considered that maybe you’re in the wrong thread?
rglover 3mo ago
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

nesarkvechnep 3mo ago

Oh, man. Again, people call MCP endpoints REST-ful when the format is JSON-RPC. That's why we can't have nice things.

alansaber 3mo ago
The P in MCP stands for REST

Satoshi_Bro 3mo ago

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.

gjvc 3mo ago

who gives a shit about what this guy thinks?

senko 3mo ago

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.

schnebbau 3mo ago

MCP is a stupid term, it makes no obvious sense what it does or what its for. I propose AII - AI Interface. Lets make it happen!

MSAII 3mo ago

Interesting that a date format is used for MCP-Protocol-Version. reply

TZubiri 3mo ago

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?

byterivet 3mo ago

[dead]

thinkindie 3mo ago

Question is - when is Claude going to adopt this new version?

fosterfriends 3mo ago

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

est 3mo ago

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

fenestella 3mo ago

[flagged]

rowanadeyemi 3mo ago

[flagged]

an0malous 3mo ago

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.

gdhkgdhkvff 3mo ago
Boom. ROST’d.

rohitghumare 3mo ago

I also wrote more about this: https://rohitghumare.com/blog/stateless-mcp/ https://rohitghumare.com/blog/stateless-mcp/

jake-coworker 3mo ago

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

heyitsmedotjayb 3mo ago

There's never existed a state of MCP - it has always been the land of Judea

Yopolo 3mo ago

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"

guluarte 3mo ago

cli tools > mcps

lukelabs 3mo ago

[flagged]

MP_1729 3mo ago

wtf? Why didn't Simon use MCP Inspector? https://modelcontextprotocol.io/docs/2026-07-28/tools/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.

luigipederzani 3mo ago
which is far from the best MCP inspector out there we hosted an online version of the mcp-use inspector which is pretty convenient: https://inspector.manufact.com/inspector https://inspector.manufact.com/inspector
simonw 3mo ago
As I said in my post: > I find building CLI tools like this to be a really productive way to get familiar with a specification.

mikeegg1 3mo ago

I still think of MCP as "Master Control Program".

jimbokun 3mo ago

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.

abratabia 3mo ago

[flagged]

winqing 3mo ago

[flagged]

jrochkind1 3mo ago

Why was MCP ever stateful in the first place?

__MatrixMan__ 3mo ago

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

Roselol 3mo ago

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.