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

MCP is dead?

quandri.io

Post reply on HN
Print view View original

341–350 of 444 posts

Re: MCP is dead?

#341

Post by Eridrus »

mxstbr wrote: post #22

I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP. The thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant. The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of…

You should probably consider that your perspective is also biased and you see all the companies that are in esting.

IME, MCP has often lagged APIs in terms of complete ess, so as a user, if there was an API, I would be better off using that because Codex is already so good at calling APIs.

Now, the API story sucks for non-coders, but I'm not really bullish on MCP for dev tools atm.

Re: MCP is dead?

#342

Post by MatthewPhillips »

mhalle wrote: post #323
MatthewPhillips wrote: post #285

Earlier quoted context omitted.

Walk me through how a user installs and then uses these CLIs from their mobile phone.

Create a skill that has the CLI in the scripts sub-directory. The implementation language depends on the LLM and the VM it uses. Claude includes shell, python, and a bunch of other interpreters in a Linux environment. A skill's instructions can direct the LLM to call the CLI. Claude skills can be installed into Claude web from a web browser. Those skills can then run on the Claude app on your phone.

Ok, I can see there's a new (to me) Customize section where you can install skills. You have been able to connect MCP servers for quite a while.

The UX here isn't great, but let's assume it can be improved. How would auth work with this alternative method? I want to connect to Puma store and that's done using a skill with a CLI. Can the CLI launch your web browser to do oauth from the skill (on a phone)? And then the credentials are saved where?

Not challenging you, I'm open to alternatives to MCP for sure. But MCP seems way more mature especially for non-programming use-cases.

Re: MCP is dead?

#344

Post by willio58 »

0xbadcafebee wrote: post #38
willio58 wrote: post #15

> Using existing CLI directly: No context wasted on tool definitions Can someone explain this to me? I've seen claude code try to run a not-well-known package and it basically shot in the dark a command, noticed that failed, then ran the help command for the cli tool to get a list of commands and what they do. How is that different than passing the tools with an MCP? Like how are we saving context?

The usual problem is companies write an MCP server with 50 different tools, and each one has a schema, description, etc. Say each tool is 150 tokens, that's 150 * 50, or 7500 tokens, dumped into the beginning of every session. Compared to a text file that gets loaded on demand with command-line tool examples, so you still get close to the same amount of context, but you can control what tool definitions you pull in.…

Thanks for the answer! I do see both sides

Re: MCP is dead?

#345

Post by CamperBob2 »

mrgaro wrote: post #294
zingar wrote: post #249

Earlier quoted context omitted.

Can you not just install/ restrict the available CLIs in the same way you do with MCPs? Or what else am I missing about why MCP is more secure than a CLI?

Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.

With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.

Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.

Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.

Re: MCP is dead?

#346

Post by monkpit »

dannypdx wrote: post #227
monkpit wrote: post #104

Earlier quoted context omitted.

You should disclose that you are behind g8e.

Do I need to add a disclaimer to every one of my posts that shits on the wrong way?

When you mention your own product in a positive light, it’s customary, yes.

Re: MCP is dead?

#347

Post by _flux »

827a wrote: post #314
_flux wrote: post #170

Earlier quoted context omitted.

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 f…

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 b…

jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data.

I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files. Maybe even Python if it can be made safe. If not, then there are a lot of languages can be.

Re: MCP is dead?

#349

Post by hackrmn »

mxstbr wrote: post #22

I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP. The thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant. The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of…

The point is that MCP solves a problem that doesn't _really_ exist. While consuming context, which is still at a premium. Claiming that services wouldn't be accessible to agents without MCP is at best misleading -- they certainly do [have access] through exactly what article sheds light on -- command-line tools, including but not limited to, input and output of said tool(s). Also, from a purely technical standpoint, MCP is "non-compositional" compared to command-line tools, and those who don't value composition are IMO doomed to discover so at their own peril, sooner or later.

And to be blunt, a) you're investment bias'ed and b) whether you're selling the product (MCP) to a gazillion companies doesn't exactly disprove a).

Just look at Microsoft -- they've buried more technology than most, and there's little correlation between usefulness and how deeply buried it is, and some would claim that the correlation is _inverse_. Organisational factors are what drive them, just as I suspect they are now driving OpenAI's insistence on MCP. I understand it's hard to see that from inside.

Re: MCP is dead?

#350

Post by shdh »

miki123211 wrote: post #266

Here's a crazy idea: instead of dealing with MCP servers and distributing all the CLIs for all the platforms, just expose your API... through SSH. SSH is the perfect protocol for LLMs. Coding agents can use it already, `ssh api@example.com list-users` is all it takes. There's a 90% chance that your users already have ssh installed. It's text-in, text-out (which is exactly what LLMs need). It handles authentication (t…

Scale this across your organization
Post reply on HN