Comment by jimbokun

18 hours ago

You failed to describe what value the MCP protocol provides.

If all of these companies spent equivalent time writing a CLI for agents to consume as they spend on MCP servers, would they be any worse off in terms of agents being able to interact with their products?

44 comments

jimbokun

Reply
fnordpiglet  17 hours ago

One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is very hard to get to use an MCP if literally any Bash() approach is possible, including breaking glass to find creds, even when an MCP is clearly advertised in CLAUDE.md, skills, and explicit user instruction. I find it fascinating that Anthropic makes a product that seems to be really poor at following instructions and OpenAI seems to generally follow guard rails.

827a  16 hours ago

Yes, in the same way a programming language would be worse off if they focused all of their effort on building an implementation instead of a language specification.

You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is.

But the problem with a CLI is that it requires a shell environment, and not everywhere you may want to run an agent should or can have access to a shell. MCP enables the harness to tightly control that access. MCP allows the user to easily allowlist/denylist specific tools, or categorize tools into "ask me every time" versus "don't ask me just do it". Doing any of this with a CLI is really hard because CLIs are all very different; yes, AIs can easily learn how to use them, but that might be exactly what you don't want, hey AI don't issue that aws ec2 delete-instance command ah crap there it goes I wish I could have just denylisted its access to that tool.

  • _flux  11 hours ago

    Not having access to the shell is a big hindrance. I have my agent access Gitlab and Jira via CLI tools and in so many cases jq or python is used to manipulate or combine the data into a more useful format, making use of pipes and temporary files. You can of course limit what an agent can do, most easily by not giving it access to things it shouldn't do. I suppose there are no existing easy gateway methods to grant fine-grained OS-level permissions to add such things back, except perhaps `sudo` and similar tools.

    MCPs are impossible to combine this way: everything you feed or get from them goes though the model and consumes tokens.

    • 827a  3 hours ago

      You’re right that having a shell is the ultimate tool, and an agent with a shell seems to perform better than one without one. But, making shells safe is really damn hard; e.g. in the context of running an agent on behalf of a SaaS customer in your AWS environment. For now some companies are accepting the performance/security tradeoff of disabling the shell and focusing on specialized tools.

      Remember: jq can always be a tool (MCP or otherwise). In this way you can allowlist specific CLI programs and give them to the agent via tools. Making python a tool is more difficult; that would have all of the same RCE injection issues that the shell would have.

      There are isolation stacks that help make “running an agent with a shell on behalf of a customer in the cloud” possible. It’s just very risky. There’s a thousand attack vectors, and to a very real degree companies that are getting to this point are re-thinking their cloud infrastructure and architecture from first principals.

      1 reply →

    • ithkuil  9 hours ago

      Can an MCP provide prompts for your model to download and use CLIs (and ensure they have the right versions of those tools) in such a way that the data flows through the client side tools?

      The more I read this thread the more I'm convinced that the main value of MCP is to provide a server managed release process. This is the same advantage that SaaS has over client side apps.

      However MCPs couples with a client willing to run tools locally can provide the best of both worlds

      1 reply →

  • fmbb  11 hours ago

    You prevent the LLM from deleting your instances by not granting its AWS user that permission. Whatever tool you let it use to talk to AWS is irrelevant.

  • jimbokun  14 hours ago

    So the permissions model h is a the main advantage MCP has over CLIs?

    • usrusr  11 hours ago

      Is that so surprising? I thought that was a given. And as soon as remote resources are involved, the old "it's in a docker" peace of mind does not apply.

eddythompson80  14 hours ago

Not a fan of MCPs for my personal use, but I still think the value for companies is obvious. The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution. You only need to "trust" the MCP client implementation, not a thousand different CLIs. Also being a standard HTTP endpoint, a lot of logic can be offloaded to proxies and such.

The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.

  • wren6991  10 hours ago

    > The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution.

    Is this an advantage? Phrased differently, every MCP that could have been a CLI call is a new opportunity for sandbox escape.

    • eddythompson80  4 hours ago

      I don’t follow. It’s the other way around. Would you rather run an arbitrary binary blob (aka: a random cli) or `curl`?

      Edit: Maybe to clarify, I’m talking about remote MCP. Local MCP is obviously nonsensical. Remote MCP is very much thriving aggressively.

cle  18 hours ago

The security model and runtime requirements are completely different between making an HTTP request and executing arbitrary code.

They have different tradeoffs.

  • lostmsu  17 hours ago

    You nailed it! There are established tools that handle the security model. MCP is the 5th leg.

0x696C6961  5 hours ago

I have a couple MCP servers connected to my Claude web & mobile clients. How would your clis work there?

hobofan  12 hours ago

Yes they would be.

MCP servers on the side of the consuming organizations fit into the existing IT landscape, with centralized safeguard on who can access what a lot better and are easier to administer than letting their employees run arbitrary agents against arbitrary sources and destinations and cause chaos.

adastra22  16 hours ago

[flagged]

  • sandeepkd  16 hours ago

    At times I feel like these people are naive and may be do not have enough practical industry experience around software development, and then on second thought I realize that they are way smarter and counting on everyone else being naive here. This is a cycle of FOMO and a temporary phase.

    Something like MCP is not a one time investment, the API's need to be maintained and updated regularly to be useful. Maintenance work is already a cost factor and no one gets promoted by maintaining anything.

    Within organizations, smart carrier oriented folks are picking up this area of work for their personal growth and visibility which comes across as if every company is going for it.

  • Kaliboy  15 hours ago

    Did you consider that maybe he has different information than you do, and thus he holds a different opinion?

    I for one love MCP. It's way faster in my experience than skills / shell. And I like how (with Claude Code) I can setup the MCP in the web interface, use it in the chat and the CLI.

    Plus the flow to add an MCP via the browser is achievable to any user.

    And one thing I don't understand of skills is this. I have an MCP for my life organisation app that authorizes via OAuth. The flow is fully via the browser so I can use the app session and its stored somewhere in claude.ai. How does authentication work with skills?

varenc  14 hours ago

The value is that many companies like building MCP servers much more than CLIs. For whatever reason.

Here's some companies that offer MCP servers but don't seem to offer an equally featured CLI:

   - Asana
   - Square
   - Linear
   - Dropbox 
   - Canva
   - Slack (sorta)
   - Figma (sorta)

and many more that offer both, but support their MCP more.

Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much more interest. I'd rather encourage them to keep improving and supporting their MCP services than telling them to drop it for a CLI.

There's lots of things like this in technology where you end up stuck with the first thing because its popularity perpetuates itself. The QWERTY keyboard I'm typing this on is a prime example. x86 is another one.

  • didibus  12 hours ago

    A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.