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

391–400 of 444 posts

Re: MCP is dead?

#391

Post by whattheheckheck »

dropofwill wrote: post #320
mrgaro wrote: post #294

Earlier quoted context omitted.

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.

Server implementers have an information advantage than the client coders wiring clis together to do a job

Re: MCP is dead?

#392

Post by Groxx »

flaburgan wrote: post #377
PaulHoule wrote: post #265

Earlier quoted context omitted.

That was exactly my thought when I saw MCP: like we know so much about creating protocols but get a bunch of people together with no experience and that’s what you get. Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better. To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my…

You mean a swagger?

It even has a catchy name that certainly won't get confused for the LLM company: OpenAPI.

Re: MCP is dead?

#393

Post by mhss »

clarkdale wrote: post #293
raincole wrote: post #202

Earlier quoted context omitted.

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…

I can't pipe an MCP's output to jq, and I can't ask an AI to write a python script to call an MCP.

I ... literally did both of these things last week ¯\_(ツ)_/¯

Re: MCP is dead?

#394

Post by bluegatty »

ok_dad wrote: post #353
bluegatty wrote: post #317

Earlier quoted context omitted.

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.

You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.

A 'skill' is generic concept - as short set of right-sized instructions for a given cli or api call, it can be applied in any context.

If MCP did not exist today, we wold not invent it.

We'd probably hormonize in basic conventions around json calls, and not much more.

The rest would just be api use / instructions.

LLMS to day are exceedingly good at calling RESTful APIs, the MCP standard provides little advantage.

The advantage of 'skills' is that they are more generic - an Enterprise LLM can evoke 'capabilities' which may or may not involved rpc type calls, and if they do, there will be varying level of instructions provided.

There's almost not point to MCP.

Re: MCP is dead?

#395

Post by CBarkleyU »

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…

>If one wants the 'teaching' part comes from a server then MCP. If one wants it local and static then skills

Not being facetious, but why not:

"If one wants the 'teaching' part comes from a server then OpenAPI specs. If one wants it local and static then man page."

Re: MCP is dead?

#396

Post by Dylan16807 »

estetlinus wrote: post #388
Dylan16807 wrote: post #372

Earlier quoted context omitted.

But the parent who suggested MCP for security didn't say anything about vibe coding it. The person who talked about vibe coding an MCP was the one saying MCP isn't very useful.

Who in their right mind writes an MCP server by hand? Of course you vibe code them.

Those are not the only two options.

Re: MCP is dead?

#397

Post by oliculipolicula »

PaulHoule wrote: post #273
CharlieDigital wrote: post #236

Earlier quoted context omitted.

That's because you're not thinking about how teams and enterprises work. You're thinking about how individuals work. An enterprise has 20 services that each have a secret key (Datadog, Snowflake, etc). I want my team to have access to those services via coding agents. How do I guard those keys from both developer and agent? Put it behind MCP; neither dev nor agent ever sees the key. If developer leaves, revoke one OA…

You’re not talking about how teams and enterprises work, you’re talking about how teams and enterprises don’t work. Teams and enterprises had problems maintaining API keys long before there was MCP and they will have the same problems afterwards. The better teams and enterprises have had solutions for a long time.

I wish you would explain more of how you infered the handlers' KPIs here

From my point of view their purpose in life is 1) hacker news highlights or 2) to restrain some patients (me) from getting off the (Freudian) couch and mouthing off at "the folks in the waiting room"

Re: MCP is dead?

#398

Post by geysersam »

0x000xca0xfe wrote: post #211
geysersam wrote: post #196

Earlier quoted context omitted.

But what is the advantage of MCP compared to having the agents access the API directly?

Agents are just a stream of text, they cannot access anything. Some kind of interpreter is needed that recognizes special patterns and runs real code. Do you mean directly == raw shell access on your production server?

All agents have some basic tool capabilities, I meant using tools such as curl or python etc to access an api, the same way a human would.

Re: MCP is dead?

#399

Post by ok_dad »

bluegatty wrote: post #394
ok_dad wrote: post #353

Earlier quoted context omitted.

You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.

A 'skill' is generic concept - as short set of right-sized instructions for a given cli or api call, it can be applied in any context. If MCP did not exist today, we wold not invent it. We'd probably hormonize in basic conventions around json calls, and not much more. The rest would just be api use / instructions. LLMS to day are exceedingly good at calling RESTful APIs, the MCP standard provides little advantage. Th…

Yea so your answer is to build something that’s like MCP basically. You’d standardize conventions around json, great, now standardize auth. Oauth is nice right? That’s MCP. MCP is literally a restful API using JSON with OAuth.

You’re arguing against MCP but have nothing to offer that isn’t nearly the same thing.

Re: MCP is dead?

#400

Post by devil1432 »

From my experience, the biggest flaw of mcp is lack of control over your system prompt.

Prompts need to be tailored for specific model (duh). Tool definitions are de facto part of your system prompt. By injecting tool definition from MCP servers into your prompt, you are basically adding prompt that was (likely) not tailored for your specific model. That causes drop in quality of answers.

Other issue is that adding one new feature via MCP can introduce regression into your system and cause other MCP features to work incorrectly (and I am not talking about malicious prompt injection by MCP provider).

Real life example: tools from MCP server for ms outlook requires certain date format for filtering emails. That worked fine in our prod. Until we added another MCP server (built in-house in another department of our company) that required dates in different format. After adding these tools, now our agent started making mistakes: putting dates in outlook format in our internal mcp tool and vice versa - putting dates in our internal format into outlook tool. There is no obvious way to fix it other than separating these prompts. And that goes against standard MCP architecture and consumes way more tokens to cycle through multiple prompts and agents.

If that's already the issue with two MCP servers, then this architecture clearly does not scale.

Post reply on HN