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

311–320 of 444 posts

Re: MCP is dead?

#311

Post by eddythompson80 »

wren6991 wrote: post #186
eddythompson80 wrote: post #93

Earlier quoted context omitted.

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

> 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.

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.

Re: MCP is dead?

#313

Post by sidewndr46 »

raincole wrote: post #202
CSMastermind wrote: post #18

Was this written by AI? MCP is essentially just JSON RPC with a few special fields that must be included. I have reservations about JSON RPC, but there needs to be some 'service discovery' layer for LLMs to interface with. It needs to be available in places like websites, desktop applications, backend services, etc. The CLI is only one place that these systems interface with. Whatever you replace MCP with will be in…

Every time I read articles about MCP I feel like the internet (or HN) is having a collective stroke. People are saying API are better than MCP. But MCP is just API with some instructions for the AI to discover how to use it. Nothing more nothing less. And some people are saying we should use 'CLI'... what does it even mean? LLMs are good with common CLI tools like ffmpeg because the knowledge is solidified inside the…

Paradoxically, I've seen new CLI tools take on usage patterns from existing ones because of the idea of user familiarity. Even if the existing pattern sucked. I could see the same thing happening now under the idea that "the LLM already knows how to use X, so we should make our tool work like X"

Re: MCP is dead?

#314

Post by 827a »

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

Earlier quoted context omitted.

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

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 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.

Re: MCP is dead?

#315

Post by est »

MCP is based on a lie: Machines are good at read/generate machine-parsable procotols.

Turns LLMs are shit with JSON. Especially those JSON str embeded inside another JSON key-value pairs.

Why do smart ppl design a schema like escape JSON into str embeded into another?

It's based on another lie: AIs favor static typed languages.

Re: MCP is dead?

#316

Post by bluegatty »

bostik wrote: post #161
bluegatty wrote: post #76

Earlier quoted context omitted.

"and the one they're using." no it's not. Agents are just making REST calls and that's it. The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use. 'MCP' is frankly a hurdle. Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe ga…

I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches: * Internal services that never had real APIs are getting them retrofitted via the MCP layer * MCP servers can run with dedicated service accounts that assume-role to a safe(r) subset of the calling user's permissions The first one is a business benefit. Enterprise…

So this is thoughtful - but - MCP isn't actually a very good solution for corporate automation either.

Corporate automations face the same problems human driven agents use:

+ The 'tool' section of the chat is not the right place, and it's too limiting + The very concept of MCP server introduces a brittle layer - for what purpose?

CLI for local calls, REST for remote.

That's it.

We build security around that the same way we would otherwise.

Now -> 'better / standard' json type calling for both of those!

Sure! 'Agent Calling API' or something. Yes.

'Agentic Identity Standard'? Yes to that as well.

But MCP was 'the right solution for a period in LLMs that has been superceded.

If MCP did not exist today - we would not invent it. That's the strongest argument I think.

Re: MCP is dead?

#317

Post by bluegatty »

didibus wrote: post #137
bluegatty wrote: post #23

Earlier quoted context omitted.

It's the way that it occupies the context relatively permanently, that it doesn't come along with nice install/uninstall or discovery etc. is the problem. 'Skills' should all be based on MCP, they should load on demand, be very easily manageable and discoverable by humans and by AI, and then it would work The scope was too narrow, given how it ended up being applied. If they layer something on top of it, it may yet b…

You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.

Yes, MCP taking the form of 'skill' because MCP serves no purpose.

The concept of 'mcp server' is a brittle abstraction that need not exist.

A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.

Re: MCP is dead?

#318

Post by olup »

Having implemented a skill to connect teams to our admin system, we ended up recording it as a Mcp. the Mcp exposes only doc grep and api calls so it's completely useless in itself, but the main reason to go this route was distribution. Non technical teams want a UI where to add a url then everything just works and oauth is guided. Mcp permits that in Claude or chatgpt.

Also the calling of the Mcp is nicer in the chat UI, clearer for users.

Re: MCP is dead?

#320

Post by dropofwill »

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.

Just use scopes in the API key the agent uses? If you’re exposing something publicly that should be a requirement anyways.

That’s how I use gh, aws, etc. No need to modify any of the code in the cli, they’re just wrappers.

Post reply on HN