Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I think a most interesting middle ground option is the advent of CLIs specifically with agents in mind.
For example, grafana has a newer CLI called gcx that replaced grafanactl https://grafana.com/docs/grafana/latest/as-code/observabilit...
I originally used the MCP server but after running into context bloat and limitations around MCP I looked and found this. Seems to be a fantastic interface for agents, they breeze through o11y tasks with this thing.
by wetpaste - I really don't care about the technical or cleanliness arguments against MCP (which are valid).
What I care about is that many companies didn't have APIs, and didn't see a reason to have them (niche, dev-focused use case, or might produce a competing frontend/app)...
but now, those companies have a reason (agentic but let customer agents access data!). And for me, that means more companies now allow me access to my own data on their platform. This has been a net win!
by jvanderbot - MCP is like anything else - it has its uses. Use it where it makes sense. Where it doesn't, don't. For my part, I probably rarely want my Agent to waste time writing its own adapter for a particular API that needs to be called, when I can just point it at an existing MCP server. And while context bloat can be a problem if you're using many many MCP tools, not every use case needs that many tools. Making that a non-issue in many cases.
For my part, I wrote an MCP server this weekend for Bugzilla, connected it to ChatGPT and now ChatGPT can help me manage my queue of bugs (and non-bugs - I use Bugzilla as sort of a generic work-item tracker, TBH). Simple, works and gives me a nice natural language interface to the tool. And if I want more than the generic API surface, I can add tools (or modify the existing ones) to add any additional business logic I want.
Can you "get there from here" other ways? Sure, absolutely. But this works quite well for my use case and I'm not anticipating "delete my MCP server" anytime soon. In fact, I plan to deploy one for interacting with my Mediawiki instance as well. I also even have plans to implement MCP for interfacing with all of my LXI/SCPI enabled test equipment!
If I get to the point where context bloat becomes an issue, I'll cross that bridge when I get to it.
MCP Apps[1] also look like a really cool addition to the stack. I've only built toy examples / demos to date but I'm pretty excited about what this brings to the table as well.
[1]: https://modelcontextprotocol.io/extensions/apps/overview
by mindcrime - I think many devs misunderstand MCP because they work in solo mode. In solo mode, you just have your secrets local. You don't care about auditing access. There's no IT managing the infra and third party secrets. You don't have to account for different harnesses and tooling; you just use your own harness and adapt your tooling to it. You're not thinking about revoking/rotating secrets when someone leaves your team. You don't have to deliver capabilities to many different runtimes and stacks.
Back in March, everyone was already pronouncing it dead[0] when in fact, it has only proliferated and become even more essential for both 3rd party systems as well as platform level capabilities[1] as agentic tooling has moved a bit more slowly into the enterprise. It was apparent even back then that enterprises will need MCP.
In a team context? Enterprise? Building web server backed or in-process agents? Not sure how you replicate the control, auditability, accessibility, composability, and security boundary that you get with MCP over HTTPS without a lot of bespoke, point solutions; in the end, protocols almost always win.
Could you do it with just REST APIs? I mean, MCP is just JSON-RPC over HTTP with standardized auth, schemas, and agent specific exchange flows (tools, prompts, resources, etc.). Could you do it with just CLIs? You lose a lot of the control mechanisms offered by MCP (auditing, security, centralized auth, etc.). The context savings are overblown except with CLIs that have good representation in training (curl, jq, cat, sed, etc.; your custom CLI is going to need to produce instructions and add to context all the same)
Heuristic is simple: don't use MCP for local, solo dev. As soon as you need MCP, you'll know it and you'll understand why it exists. Many of the harness level capabilities themselves are implemented as first party MCP (more apparent in the CLIs). MCP is basically REST for the agentic era.
[0] https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- The title feels clickbaity. Direct API, CLI and MCP all have their uses.
Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.
CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.
MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.
by cagz - MCPs are winning because within the ChatGPT and Claude apps, there are Plugin stores. These plugins are one-click installation MCP servers, with support for authentication. This is what business users are using.by whazor
- The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that.
Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree.
> Agents with terminal access can replace most MCP servers
What should all other agents that don't have terminal access do?
- This article entirely misses the value that MCP brings today.
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
by simonw