Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > 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.
by ameshkov - 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/
by evalstate - 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.by hobofan
- The documentation for the --cli mode is a bit lacking, but I got there in the end:
Equivalent with my mcp-explorer tool: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}}'
So yeah, they're pretty similar.uvx mcp-explorer call \ https://agentic-mermaid.dev/mcp render_svg \ -a source 'graph TD; A-->B' \ -a options '{"padding":24}'Then for my list command:
With the inspector one you would do:uvx mcp-explorer list https://agentic-mermaid.dev/mcp
Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.npx @modelcontextprotocol/inspector --cli \ https://agentic-mermaid.dev/mcp \ --method tools/listby simonw - 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.by brianjking
- 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.by Foobar8568
- I my mind it's mostly corporate socio-political. Your management have no idea what a (rest) API is, but they saw MCP in countless LinkedIn slop and therefore you are allowed to work on one / use an upstream solution to connect the agents to your 23 year old monolithic unmaintained homebrew CRM that only runs because overcompensated Frank is still willing to pet it manually.by kmarc
- Well for a non-coding (no CLI tooling) flow it means you don't need a sandbox and it provides a plugin architecture.by hahahaa
- The people who promote it don’t get it either but the inmates are running the prison now so we have to pretend like “stateless MCP” isn’t just rebranded REST APIsby an0malous
- MCP is most useful for extending agent loops with external tools. If you are building your own loops from scratch and don't intend to support external tools, MCP doesn't add anything.by bob1029
- It's mostly useful to allow sandboxed AI apps to access external functionality. If an LLM has any kind of access to a CLI then it stops making sense, because LLMs are very good at CLI and almost always they use less tokens doing that. Plus, you human can easily use a cli tool, while mcp is just for agents.by qalmakka
- 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.by mmasu
- 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
- 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.by olmo23
- 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.
- 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 - Yes run a side agent to evaluate if they are needed.
I am guessing keeping them all in every request is cache efficient though.
by hahahaa - > 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).
by SyneRyder - 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 - 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.by mailmrg
- can postgREST be helpful for this? Clickhouse also has an http endpoint to send queriesby bkaraaslan
- 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
- Boom. ROST’d.by gdhkgdhkvff
- 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 - I came here to ask why it was ever stateful?by zeafoamrun
- There's a nice feature in the new version that lets you copy tool _arguments_ in to the HTTP Headers for custom routing etc.by evalstate
- MCP is basically just:
1. a REST-like API
2. with a spec (OpenAPI, introspection, etc.)
3. with harness-level authz (the ability to allow / deny specific methods in the harness)
The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.
So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.
by bloppe - 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.
by pjmlp - 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 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
by firasd