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.
> 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?
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.
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.
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.
0xbadcafebee · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
0xbadcafebee · · focus · HN ↗
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.