Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP is dead; long live MCP

chrlschn.dev

Post reply on HN
Print view View original

101–110 of 231 posts

Re: MCP is dead; long live MCP

#101

Post by tptacek »

oneseventwonine wrote: post #100
tptacek wrote: post #75

Earlier quoted context omitted.

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

For the Agent to use CLI, don't we have to install CLI in the run-time environment first? Instead for the MCP over streamable HTTP we don't have to install anything and just specify the tool call in the context in't it?

This rolls up to my original point. I get that if you stipulate the agent can't run code, you need some kind of systems solution to the problem of "let the agent talk to an API". I just don't get why that's a network protocol coupling the agent to the API and attempting to capture the shape of every possible API. That seems... dumb.

Re: MCP is dead; long live MCP

#102

Post by ekropotin »

0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

I mean, CLI tool is also “reusable communication abstraction”, innit?

Re: MCP is dead; long live MCP

#103

Post by twoodfin »

The only value—and it’s significant—that a fixed-tools protocol like MCP can provide is to serve as the capability base for an embedded agent security model.

The agent can only perform the operations it has been expressly given tools to perform, and its invocation of those tools can be audited and otherwise governed.

Whether MCP evolves to fulfill this role effectively, time will tell.

Re: MCP is dead; long live MCP

#105

Post by jswny »

simianwords wrote: post #31
jswny wrote: post #16

MCP is fine, particular remote MCP which is the lowest friction way to get access to some hosted service with auth handled for you. However, MCP is context bloat and not very good compared to CLIs + skills mechanically. With a CLI you get the ability to filter/pipe (regular Unix bash) without having to expand the entire tool call every single time in context. CLIs also let you use heredoc for complex inputs that are…

but you need to _install_ a CLI. with MCP, you just configure!

Plenty of MCPs require you to install and run them locally, like I said remote MCP has a real advantage over CLI tho

Re: MCP is dead; long live MCP

#106

Post by jswny »

thunkle wrote: post #97

So if I release a new cli. How do I get the LLM to know about it? Do i tell it every time to run the command? Do I build a skill. Should I release a skill with the cli? Do I just create docs on GitHub and hope the next crawl gets into the training set?

Package a skill with your CLI itself and give users instructions on how to install the skill properly. That allows the agent to read the instructions in a context efficient way when it wants to use the CLI

Re: MCP is dead; long live MCP

#107

Post by jabber86 »

tptacek wrote: post #75
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

I am creator of HasMCP (my response could have a little bias). Not everyone has home/work computer by preference mostly. I know a lot of people just use iPad or Android tablet in addition to their phone. They still use applications to work on the things. This number is not a small amount of people. They need to access openworld data or service specific data. This is where MCP is still the one of the best ways.

It tries to standardize the auth, messaging, feedback loop where API can't do alone. A CLI app can do for sure but we are talking about a standard maybe the way is something like mcpcli that you can install your phone but still would you really prefer installing bunch of application to your personal device?

Some points that MCP is still not good as of today:

- It does not have a standard to manage context in a good way. You have to find your hack. The mostly accepted one search, add/rm tool. Another one is cataloging the tools.

- lack of client tooling to support elicitation on many clients (it really hurts productivity but this is not solved with cli too)

- lack of mcp-ui adoption (mcp-ui vs openai mcp app)

I would suggest keep building to help you and your users. I am not sponsor of MCP, just sharing my personal opinion. I am also creator HasCLI but kindly biased for MCP then CLI in terms of coverage and standardization.

Re: MCP is dead; long live MCP

#108

Post by phpnode »

tptacek wrote: post #75
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

no, it's all about auth. MCP lets less-technical people plug their existing tools into agents. They can click through the auth flow in about 10 seconds and everything just works. They cannot run CLIs because they're not running anything locally, they're just using some web app. The creator of the app just needed to support MCP and they got connectivity with just about everything else that supports MCP.

Re: MCP is dead; long live MCP

#109

Post by 0xbadcafebee »

tptacek wrote: post #75
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

A lot of the reasons to use MCP are contained in the architecture document (https://modelcontextprotocol.io/specification/2025-11-25/arc...) and others. Among them, chief is security, but then there's standardization of AI-specific features, and all the features you need in a distributed system with asynchronous tasks and parallel operation. There is a lot of stuff that has nothing to do with calling tools.

For any sufficiently complex set of AI tasks, you will eventually need to invent MCP. The article posted here talks about those cases and reasons. However, there are cases when you should not use MCP, and the article points those out too.

Re: MCP is dead; long live MCP

#110

Post by tptacek »

phpnode wrote: post #108
tptacek wrote: post #75

Earlier quoted context omitted.

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is…

no, it's all about auth. MCP lets less-technical people plug their existing tools into agents. They can click through the auth flow in about 10 seconds and everything just works. They cannot run CLIs because they're not running anything locally, they're just using some web app. The creator of the app just needed to support MCP and they got connectivity with just about everything else that supports MCP.

Write better CLIs for the agents of the less-technical people. The MCPs you're talking about don't exist yet either. This doesn't seem complicated; MCP seems like a real dead end.
Post reply on HN