Top
Best
New

Posted by maharshi365 2 days ago

MCP was always a bad idea?(maharship.com)
329 points | 326 commentspage 9
OutOfHere 1 day ago|
With MCP or HTTP, how do you implicitly limit access of the agent to a particular user? In other words, how do you avoid giving the agent access to perform an operation for any injected user? This is a basic security question.

I can do this trivially when my tool functions are closures that have the user-id pre-bound, but with MCP and HTTP I naively assume that the callables are pre-set.

jay_kyburz 2 days ago||
You know you are getting old when Acronym's change on you.
dofm 2 days ago|
Vacate entry port, program! I said, move out!
kwar13 1 day ago||
MCP is a more controlled environment than yoloing an access token. Article missed the point entirely.
vetler 1 day ago||
Is this another "Dropbox is just rsync"-like post?
mwkaufma 1 day ago||
"The attack surface wasn't big _enough_"
tananaev 1 day ago||
The article completely misses the main MCP point - it's authentication handling. Sure you can login via CLI, but it's much more clunky to manage.
Kevcmk 1 day ago||
Terrible take. Access control.
rvz 2 days ago||
MCP for agents never made sense, especially when the tokens they consume a significant amount of tokens on a single request for a basic action, and sustained usage blows up you token costs.

The spec was poorly designed to begin with. Even saw some folks here thinking it was a good idea to enable MCP directly on a production database for what? Risking exfiltration of sensitive data for bad AI agents.

Given the increased security capabilities of these new models (Mythos, Astra, K3), it sounds like MCP would not be able to justify on making sense from a security perspective and would be a very bad idea to use anyway.

So no thanks and no deal.

mstank 2 days ago|
Well, think of the near-future when tokens are so cheap that they’re not worth to meter.
lirolero 1 day ago||
[dead]
0xbadcafebee 1 day ago||
Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.

MCP is an abstraction for remote tool calls with a standard interface. More specifically it's for when a local CLI will not do, and you want determinism and standardization. It also avoids all of the potential errors and guesswork involved with a model trying to "figure out" how to do something; you simply make one standard call, and the remote side "figures it out" for you, without failure.

If you can do what you need to do without MCP, then don't use MCP. When you eventually get sick of AIs playing guessing games with local tools/data, or spending lots of time to get functionality somebody already published as an MCP, or you need isolated control over the execution, maybe check it out again.

mahboi 1 day ago||
> Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.

Yeah that's me. Idk what MCP is really, just that there's always some auth issue with it and I've never actually needed it. Is it dead yet?

0xbadcafebee 1 day ago|||
Think of MCP as a universal CLI tool for anything you can imagine running on a server (remote!). Even if you wanted to use a local CLI tool to call some remote server command, local CLI tools have different input/output formats, different commands/options, and those tools change over time. MCP doesn't change, it always tells the AI exactly how to call it, the calls always use the same format, it includes a standard, quite secure method of authentication, and it's all done in an AI-friendly way. And because of all of this, it uses less tokens, and has a much higher likelihood of success (e.g. AI tools failing to call CLI tools properly and looping trying to figure out the right arguments/input/output).

Now, if you don't care about authentication, don't care about wasted tokens, don't care about the AI screwing up CLI tool calls or needing to be trained on every one, and if you don't need to call something on a server, then MCP is useless to you.

mahboi 1 day ago||
In that case, you can use a skill calling an HTTP+JSON endpoint. Or if you mean it's literally a remote CLI, so it needs bidi streaming, that's what websockets is for (or gRPC but ehh). Those are well-established. MCP sounds like one of those "we need yet another a new standard, this time to rule them all" things.
0xbadcafebee 1 day ago||
Yeah that still fails a ton. A skill will mess up the call, not know how to handle errors correctly, not flag an error as an error (false positive), hallucinate, require custom input/output formats, require custom code to validate, won't handle authentication the same way, you'll need a unique skill for each endpoint, you need to version the skill, and of course there needs to be an endpoint, as well as all of the tools needed on the client machine to process everything, hoping of course that they're the right version.

Compare that to MCP. One standard tool call. Works on every agent. Everything built in. Determinism. Reliability. Simplicity. It just works.

Skills are non-deterministic balls of mud. MCP are deterministic standard tool calls. MCP solves all the problems. A skill can't do what MCP does.

In terms of "using standards" to solve the problems, tell me 3 different APIs (from different companies) that have identical input format, identical output format, identical request URI format, identical headers, identical methods, identical auth. You won't find them, because everyone implements their API differently. You can use 50 different standards 50 different ways, and still not solve the problems mentioned above. MCP is one standard that works one way and actually solves all the problems.

And this is just addressing the client-side problems. There's a whole world of server side (logging, tracing, auth, execution, etc) that's not standard either, unless you use MCP.

lirolero 1 day ago|||
[dead]
woodpanel 16 hours ago||
> guessing games

that still doesn't answer why to choose MCPs over Skills.

More comments...