alt Hacker NewsI feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions:
- If you need to interact with a local app in a one-off session, then use CLI.
- If you need to interact with an online service in a one-off session, then use their API.
- If you need to interact with a local app in a persistent manner, and if that app provides an MCP server, use it.
- If you need to interact with an online service in a persistent manner, and if that app provides an MCP server, use it.
Whether the MCP server is implemented well is a whole other question. A properly configured MCP explains to the agent how to use it without too much context bloat. Not using a proper MCP for persistent access, and instead trying to describe the interaction yourself with skill files, just doesn't make any sense. The MCP owner should be optimizing the prompts to help the agent use it effectively.
MCP is the absolute best and most effective way to integrate external tools into your agent sessions. I don't understand what the arguments are against that statement?
Replies
MCP is less discoverable than a CLI. You can have detailed, progressive disclosure for a CLI via --help and subcommands.
MCPs needs to be wrapped to be composed.
MCPs needs to implement stateful behavior, shell + cli gives it to you for free.
MCP isn't great, the main value of it is that it's got uptake, it's structured and it's "for agents." You can wrap/introspect MCP to do lots of neat things.
I think a lot of the MCP arguments conflate MCP the protocol versus how we currently discover and use MCP tool servers. I think there’s a lot of overhead and friction right now with how MCP servers are called and discovered by agents, but there’s no reason why it has to be that way.
Honestly, an agent shouldn’t really care how it’s getting an answer, only that it’s getting an answer to the question it needs answered. If that’s a skill, API call, or MCP tool call, it shouldn’t really matter all that much to the agent. The rest is just how it’s configured for the users.
There was a great presentation at the MCP Dev Summit last week explaining MCP vs CLI vs Skills vs Code Mode: https://www.figma.com/deck/H6k0YExi7rEmI8E6j6R0th/MCP-Dev-Su...
The way I see it is more like this:
- Skills help the LLM answer the "how" to interact with API/CLIs from your original prompt
- API is what actually sends/receives the interaction/request
- CLI is the actual doing / instruct set of the interaction/request
- MCP helps the LLM understand what is available from the CLI and API
They are all complementary.
Meanwhile, I'm using MCP for the LLM to lookup up-to-date documentation, and not hallucinate APIs.
It's like saying it is very safe and nice to drive a F150 with half ton of water on the truck bed.
How about driving the same truck without that half ton of water?
Hard disagree. Apis and clis have been THOROUGHLY documented for human consumption for years and guess what, the models have that context already. Not only of the docs but actual in the wild use. If you can hook up auth for an agent, using any random external service is generally accomplished by just saying “hit the api”.
I wrap all my apis in small bash wrappers that is just curl with automatic session handling so the AI only needs to focus on querying. The only thing in the -h for these scripts is a note that it is a wrapper around curl. I havent had a single issue with AI spinning its wheels trying to understand how to hit the downstream system. No context bloat needed and no reinventing the wheel with MCP when the api already exists
> MCP is the absolute best and most effective way to integrate external tools into your agent sessions
Nope.
The best way to interact with an external service is an api.
It was the best way before, and its the best way now.
MCP doesn't scale and it has a bloated unnecessarily complicated spec.
Some MCP servers are good; but in general a new bad way of interacting with external services, is not the best way of doing it, and the assertion that it is in general, best, is what I refer to as “works for me” coolaid.
…because it probably does work well for you.
…because you are using a few, good, MCP servers.
However, that doesn't scale, for all the reasons listed by the many detractors of MCP.
Its not that it cant be used effectively, it is that in general it is a solution that has been incompetently slapped on by many providers who dont appreciate how to do it well and even then, it scales badly.
It is a bad solution for a solved problem.
Agents have made the problem MCP was solving obsolete.
[dead]
My main complaint with mcp is that it doesn't compose well with other tools or code. Like if I want to pull 1000 jira tickets and do some custom analysis I can do that with cli or api just fine, but not mcp.