There's probably still value (if you want to call it that) in it as a proxy, both to bypass IP address rate limits and to add necessarily credentials.

There's also another aspect Quite a few API providers provide automatic renewal for MCP server registrations, but not for personal access tokens. This may be less relevant when models just drive the user's browser.

It seems like OP needs to provide a solution to hiding the credentials from the model in order to suggest CLI-mode only, and also a solution to the problem of agents without shell access.

For claude check these out:

https://www.anthropic.com/engineering/advanced-tool-use

https://platform.claude.com/docs/en/agents-and-tools/tool-us...

I think there's at least one thing that MCPs get right, and it's that they make it easier to establish permission boundaries when agents are working with third part services and applications. Even with Claude from the terminal, MCP makes it easier for folks to standardize separate permissions and operations for general agent use than making people have to have multiple complicated API keys. Do I think it's the best solution for that? Not really, but I think it's probably better and on average safer than giving agents unfettered access to credentials to do anything, which seems like it'd be the default without MCP. That said, I can see MCP being replace with some sort of permission and sandbox system that's more generalized.

Best idea in the article, and I'm going to try it out later today:

We should start to standardize how agents use HTTP APIs directly. For example, agent clients could attach headers to identify themselves as agents, and servers could automatically send them response data as Markdown or text instead of HTML or verbose JSON.

    Accept: text/markdown

MCP's monolithic design always felt like fighting a hydra; one fix created five new bugs elsewhere. Never understood why it gained traction.

The major advantage of CLI is IMHO that you can use a CLI yourself too. It's a universal tool.

One thing I hate is when people write an MCP server for something useful and just that. Like, why don't you tell the same Claude or Codex instance you wrote to also expose the same functionalities as a CLI? The problem is that it's full of technical people with zero CLI knowledge nowadays (or, rather, for the last 20 years or so), and it kinda sucks in general, because lots of stuff only comes in GUIs that are not composable, not scriptable and sure as heck full of stupid bugs and limitations due to how harder it is to get GUIs right compared to popping out a "dowhateverctl" kind of tool

I find it hard to agree that MCP merely wraps a simple API. Sometimes a filtered model-specific interface is needed. MCP is one of those interfaces. In our SaaS service, sensitive information can be viewed via REST, but since MCPs may be exposed to LLMs, they are blocked from going outside.

I have used Unity and Blender MCPs and I am not sure I am seeing why this is not a needed concept (or is a bad implementation).

If Unity updates the version (and the MCP server with it) - my agents immediately see the new surface. They weren't trained on the features of the new version of Unity, but they know about them as soon as they are added.

Context bloat is a thing - but you only turn on the MCP servers for what you are actually working with. If I am only in Blender, I don't need the Unity MCP. So it can be disabled.

These are just two example pieces of software but the concept applies to all of them with MCPs.

CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits.

MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases.

I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon).

Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too.

CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't.

For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev.

So my summary is:

CLI - Great for out of the box, things that are well known, where you want to verify the output

API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold.

MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate.

I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.