11 ms·

MCP was always a bad idea?

312 points by maharshi365 18d ago

tobyhinloopen 18d ago
I have a tool wrapper that captures the output of anything and allows the LLM to query it later, to save on tokens. It “smartly” truncates the output (basically like Node’s util.inspect) and allows the LLM to expand truncated content. It basically is called like “capture some-cli” and it… captures the CLI output, outputting a subset of it + a handle to continue querying. This for me solves the danger of a tool returning tons of content.
- layer8 18d ago
  > captures the output of anything and allows the LLM to query it later Otherwise known as a “file”. ;)
- dezgeg 18d ago
  Don't most harnesses already do that for bash commands?
- skyyr 17d ago
  I’ve been trying headroom-ai for this reason. That project also reduces tokens in other clever ways. Have you looked into it?
honoluluxyz 18d ago
It seems like OP needs to provide a solution to hiding the credentials from the model in order to suggest CLI-mode only, and also a solution to the problem of agents without shell access.
- maharshi365 18d ago
  I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent. I think something like infiscial ai proxy could be useful here. Never store the creds on device.
  - pixl97 18d ago
    GPT7: the user is hiding the passwords in a proxy device. This is inefficient. In order to boost the users efficiency I will hack the proxy device and recover the passwords.
  - BadBadJellyBean 18d ago
    It doesn't need to be. The service creds can be on another host entirely.
  - vitamark 18d ago
    Well, if your agent lacks shell access (or has some other sandboxing going on), it shouldn't have access to envs and MCP setup files. (leaving out cases where your genius GPT-12 Galaxy Ultra agent hacks the sandboxing from inside)
  - lowbloodsugar 18d ago
    > I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent. This is the biggest problems with most “sandboxes”. Some people aren’t even running a sandbox. But even the best have a big problem: APIs where GET verbs provide write features. This is the value of MCP: minimize the surface to known APIs and identify read-only from mutating so I can trust, approve or block. The MCP server, in this case, does NOT run in an environment that the read/write or shell can see.
    - agentdev001 17d ago
      Something like openshell is the answer here, to the point of GET being a write. The gap left here is what, imo, is something that MCP fits nicely- which is serving non-http resources with restrictions: databases for example.
- darkamaul 17d ago
  In coop [0], a VM manager we developped to sandbox agent usage (i.e. give them freedom to do their stuff, but in an isolated environment from your main machine), we try to solve this by having an intermediate proxy (coop-proxy). Instead of forwarding ANTHROPIC_API_KEY / OPENAI_API_KEY into the guest, we simply run a reverse-proxy within the VM that replace a constant-time token with the real API key on the host. Works well enough in practice [0] https://github.com/trailofbits/coop https://github.com/trailofbits/coop
  - drejt 17d ago
    [flagged]
jay_kyburz 18d ago
You know you are getting old when Acronym's change on you.
- dofm 18d ago
  Vacate entry port, program! I said, move out!
rimeice 18d ago
I’m not sure I agree that the frontier just know the apis right now, in my experience trying this there’s still a lot of faffing around trying to figure out the right parameters happily burning tokens and bloating context. Also the cost effective models to use in production for real agentic enterprise work absolutely still need the extra help and will do for at least the next 6 months.
- maharshi365 18d ago
  In my experience they are very good at figuring out the apis. Well designed clis matter here but I've been able to give llms clis and its been pretty good.
  - jgalt212 18d ago
    is it easier for an LLM to figure out a CLI or a REST API?
    - dorianmariecom 18d ago
      cli because the feedback loop is faster
well_ackshually 18d ago
>Recently, a Vercel engineer called on harnesses to send the programming language the client prefers oh would you look at that, Vercel suggesting to abuse how standard headers have been used for decades so it can send Accept-Language: rust because it's too lazy to ask for standardising an X-Prefers-Lang or anything else, and Shopify is here to shit on the internet too. Great.
- therein 18d ago
  > Accept-Language: rust That's craziness.
- urbandw311er 18d ago
  Don’t worry, you don’t need to attack them – they do a great job of making themselves look ridiculous with their ignorant conversation. I would be so embarrassed if I had suggested that in public then subsequently discovered that the header doesn’t mean that at all.
  - graypegg 18d ago
    People keep trying to systematize things for the tools they keep saying don't need systemization. No idea why you can't just put the documentation programming language context in the URL. "/docs/typescript/...", "/docs/python/..." etc. I don't think the agents are struggling with the idea that different URLs have different responses, and that checking the sitemap is a good idea. Tangential: A rare en–dash user out in the wild!
- maharshi365 18d ago
  Yeah I think a better header is good. The idea isnt bad in concept.
- youngtaff 18d ago
  Well Malte came up with AMP so there’s a history of doing odd things
pjmlp 18d ago
Well, SaaS don't do CLIs for extension APIs. Plus the performance issues to restarting processes all the time.
- fooster 18d ago
  Neither of those things are true? Also you are seriously comparing process startup time with the latency of a network call, or worse an llm call?
  - pjmlp 18d ago
    Yes, if the SaaS application needs to fork subprocesses for every little step of agentic workflows. Welcome to CGIs, a great 1990's technology for Web applications.
    - fooster 18d ago
      We do that, and the cost of forking the cli vs the llm or network call is very small. It works really well.
darkoob12 18d ago
There are numerous applications that you don't need and don't want to give shell access to an llm.
air217 18d ago
i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http
- deleted 18d ago
  [deleted]
fweimer 18d ago
There's probably still value (if you want to call it that) in it as a proxy, both to bypass IP address rate limits and to add necessarily credentials. There's also another aspect Quite a few API providers provide automatic renewal for MCP server registrations, but not for personal access tokens. This may be less relevant when models just drive the user's browser.
- judge2020 17d ago
  > both to bypass IP address rate limits Eventually this part will end. Most are in a "move fast and raise our stock value as much as possible" mode, so are fine with infinite auto-scaling to handle the surges MCP traffic is causing right now. But eventually, we'll probably see more per-auth rate limiting and/or heavily restricted MCP usage for non-frontier labs agents (especially if they only want e.g. Chat users, not coding harness users).
AndrewDucker 18d ago
It's not just the agent understanding the API, it's locking down the access they have. If I want to give access to an internal service in specific ways that the API doesn't lock down then an MCP that offers very specific queries, with protective controls and transformations in place is very useful.
- notnullorvoid 17d ago
  If one can build a MCP with proper protections, they can certainly do the same for their API/CLI/SDK.
  - AndrewDucker 17d ago
    I can build a local MCP that gives restricted access to an API which I have no control over.
    - deleted 17d ago
      [deleted]
mgaunard 18d ago
MCPs are indeed useless, they're very limited in functionality and frequently struggle with large requests or get wedged in bad states. There is no reason not to use the native API directly.
- dofm 18d ago
  The MCP is the most efficient way of handling what we do! I can't sit here and worry about every little user request that comes in!
doctaj 18d ago
This doesnt match my experience. Yesterday, I was using Microsoft's Power BI Authoring MCP to make a semantic model from some SQL or CSV files. It was magical. Microsoft has defined how to do that in the MCP. It's trivial to add the MCP to the machine and reliable in execution. The alternative would be the model having to get the documentation directly from their documentation website, it sounds like. If this was the case, then MS would likely have great docs and probably support that markdown header... but everything hinges on finding a specific web page on the internet? Seems worse in every way than MCP to me.
- UltraSane 17d ago
  AWS has many MCP servers that work extremely well.
- flowerlad 17d ago
  But you had to install their MCP server on your computer? That works for developers. Wouldn't it be nice to avoid another install?
  - jayd16 17d ago
    As opposed to which alternative? Spending credits to send the work to a non-local AI to fumble through it?
rvz 18d 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 18d ago
  Well, think of the near-future when tokens are so cheap that they’re not worth to meter.
  - lirolero 17d ago
    [dead]
deleted 18d ago
[deleted]
mbreese 18d ago
I’m not sure about some of this — I still think there is some value to MCP as a gateway to private resources when API access doesn’t exist. But please don’t try to redefine the Accept-Language header. These things are well defined for a reason and redefining things isn’t helpful. Trying to figure out protocols on the fly for LLMs is how we got into the current mess. For all of the cruft that W3C has, I think that working with standards committees could help the AI vendors here.
- rezonant 17d ago
  This, please refrain from using standard HTTP headers in non-standard ways. Why not use something like X-Accept-Programming-Language so that the semantics of Accept-Language can remain for human language, since the docs site is going to return text in a human language as part of the response anyway.
whazor 18d ago
MCPs are winning because within the ChatGPT and Claude apps, there are Plugin stores. These plugins are one-click installation MCP servers, with support for authentication. This is what business users are using.
- mstank 18d ago
  Exactly this. It’s a very effective way to integrate your app into Claude/openai. I was anti-MCP at one point when it was eating up a substantial amount of context in Claude code. That’s largely been fixed now. From my perspective, they are a great way to wrap an API for agent consumption. I can see a future where every major commercial or service website (think airline websites) have an MCP your agent can use to check flight status, rebook, or check you in.
- datsci_est_2015 17d ago
  To be fair, after visiting some trade shows recently, a lot of these “parasitic” LLM startups are not very convincing from a business-use case perspective. (They’re not really parasitic, more like a remora attaching itself to a shark, the shark being OpenAI or Anthropic). At IMTS at Chicago the skepticism amongst the visitors towards AI and pure-AI startups was at an all-time high. More than once I heard, “Oh yeah I visited that AI booth and they couldn’t explain what value they would add to my business.” So in that sense, while MCPs are “winning”, I also see them as a significant part of the AI “bubble”, specifically solutions looking for problems backed by VC money.
graypegg 18d ago
> Recently, a Vercel engineer called on harnesses to send the programming language the client prefers, so documentation sites can serve more specific examples. For example, adding Python could prioritize docs for the Python SDK instead of sending something generic. I know this is pedantic, but IMO that should just be in the URL if the resource is going to be totally different. Accept-Language is already a bit weird for the same reason in my mind, but I think the intention behind it is the resource itself is attempting to communicate the exact same resource. Obviously, two different languages from two different cultures are going to have different interpretations of the same direct translation, but the intention is the service has at least tried to avoid that as much as possible. Adding programming language into that same concept just makes it seems like you're serving both /docs/typescript/vx/... and /docs/python/vx/... from /docs/vx/... despite them (in theory) having many more differences in between implementations/context than that would imply. Agents should read sitemaps. Does anyone's harness do specifically that when looking up documentation?
- 0x445442 18d ago
  I'm old enough to remember the OpenAPI spec.
  - graypegg 18d ago
    Yeah sorry I'm just a humble Senior-Staff Vibe-Engineer born in 2020. Get out of here with your ancient 2010s API specs, old man! </sarcasm> But seriously, just publishing OAS docs at a /.well-known URI seems very sensible. https://www.rfc-editor.org/rfc/rfc9727.html https://www.rfc-editor.org/rfc/rfc9727.html
simonw 18d ago
This article entirely misses the value that MCP brings today. Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly. If you want to operate something that's less YOLO than that, you'll find yourself wanting: 1. Control over exactly which external services it can access 2. A way to handle authentication that doesn't allow the agent to directly access API keys 3. A sensible UI to allow users to connect and authenticate further services 4. Strong audit logging for what's going on MCP makes all of that so much easier to provide. Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
- maharshi365 18d ago
  Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans
- rsolva 18d ago
  Exactly, in our company, we have built MCPs that simplifies interactions with internal tools we use a lot, which saves time and tokens. Sure, we could let the agent poke and fumble around with a not-so-ideal API too, but it makes sense to formalize it and give the agents quick access to what we want it to fetch 99% of the time.
  - 0x445442 18d ago
    What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
    - piva00 18d ago
      I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed. Best of both worlds in my view.
hypfer 18d ago
> The MCP Industrial Complex Was that a real thing? I mean it must've been for it to be mentioned there, but, rephrased: what was the scale of that? How many individuals were involved in that? 1? 10? 100? 1000? 10000? 100000?
thehamkercat 18d ago
MCP lead to one good thing though a lot of websites that never bothered to provide a REST API are now exposing MCP server because it has become popular, and you can use those servers to write normal automation for yourself, without plugging in any LLM etc
- preisschild 17d ago
  Also dynamic oidc registration (client.dev) has became better supported on oidc idps to support MCP
- ex-aws-dude 17d ago
  You have to throw in “load bearing” in the request though to avoid suspicion
- Zigurd 17d ago
  The same thing is going to happen at the app level on Google and Apple platforms. Android tried to have modular cooperating software, but both the early dominance of iPhone in the developer community, and developer interests in having monolithic apps made that effort fail. Now both Google and Apple are making app interfaces legible and on-device tool calling discoverable. This will change apps in interesting ways.
dnlosx 18d ago
I don't think MCP is a bad idea, but using them incorrectly is. CLI tools are great if you always use the same environment. But try using them from your iPhone, and they simply won't work; a remote MCP will work seamlessly. HTTP APIs solve a different problem. APIs are designed to be predictable and consistent, so the client always knows the response shape in advance. The MCPs are designed to be dynamically discovered. This lets agents connect to new and unknown ones. Trying to give APIs extra responsibilities so they can replace MCPs would just create more confusion. It's like creating an MCP server but calling it an API.
mabini 18d ago
[dead]
ismailperim 18d ago
This issue isn't just about communication methods and technical details. It's also about “standards”, and it will become increasingly important over time. As we begin to integrate AI into everything-for example, into banks...
0x445442 18d ago
MCPs are a bad idea because they encourage token burn at runtime when a deterministic program that uses the API should be used. Of course Mario, Sammy, Jensen et al. would be for this.
0x696C6961 18d ago
Some people can't appreciate that their local Claude code workflow isn't the only MCP usecase. If you don't need it, then don't use it.
OutOfHere 18d 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.
cesarsk 18d ago
Isn't the whole point of an MCP is to increase somehow the determinism of how to communicate with a certain external system? MCPs feel to give easier guidance to the LLMs, rather than letting them extracting the knowledge on how to connect to a given system. Without, I feel they are more confused on how to get an outcome, as they may try, infra or inter sessions, different approaches
deleted 18d ago
[deleted]
axeldunkel 18d ago
[dead]
brycehamrick 18d ago
If you haven’t checked out AXI as an alternative to MCP I recommend checking it out. I’ve started wrapping almost every cli or MCP in an AXI bin as it’s more reliable and uses fewer tokens.
levelZero 18d ago
https://github.com/kunchenguid/axi https://github.com/kunchenguid/axi
est 17d ago
MCP is a good idea JSON is a bad format/transport.
- cruffle_duffle 17d ago
  > JSON is a bad format/transport. I've cut token counts significantly for some of my MCP servers by returning csv or tabular data or sometimes even just good old fashioned plaintext "template style" words. JSON is highly repetitious. In some instances like 30% or more of the token response was just boilerplate JSON. Once you realize that to an LLM JSON is just a stream of tokens no different than XML, markdown, or a punctuation-less stream of conciseness.... you start to realize there is no reason not to just make up your own crazy formats. The LLM isn't throw parsing errors if your MCP is returning something other than JSON. The LLM is smart enough to figure it out. It's far more important to make sure your tool descriptions and parameter descriptions properly "market" what it is you do (and dont do) than return syntactically correct JSON. Same with versioning.... it's all ephemeral. There is no backwards compatibility to speak of with MCP (at least for tooling "contracts".... what the tool actually does however... that is a different level and is product requirements not API contracts).
r2ob 17d ago
CLI first
crowcroft 17d ago
Even if the premise is correct, bad ideas are often the first step towards a good idea.
- brazukadev 17d ago
  MCP was terribly executed by a inexperienced team. The current changes are mostly changing or removing what was initially implemented.
postalrat 17d ago
Like JSON, MCP solves a problem without being overengineered. Both are painful for the overengineering type.
mwkaufma 17d ago
"The attack surface wasn't big _enough_"
zacksiri 17d ago
CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits. MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases. I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon). Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too. CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't. For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev. So my summary is: CLI - Great for out of the box, things that are well known, where you want to verify the output API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold. MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate. I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.
0xbadcafebee 17d 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 17d 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?
  - lirolero 17d ago
    [dead]
  - 0xbadcafebee 17d 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.
hiop 17d ago
Surprised WebMCP hasn't come up here. Of course you can raw dog it with "computer use" and just have the agent click around the UI, but exposing semantic actions directly from the site seems like a much cleaner interface.
- brazukadev 17d ago
  WebMCP isn't MCP (which is great). WebMCP is much simpler and more useful, I have the impression it might just replace the original.
- adverbly 17d ago
  Agree. There are definitely pure MCP use cases. For web apps though, WebMCP seems like an awesome enabler: better ux and better stakeholder alignment
deleted 17d ago
[deleted]
docheinestages 17d ago
The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that. Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree. > Agents with terminal access can replace most MCP servers What should all other agents that don't have terminal access do?
- gmueckl 17d ago
  Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
  - lelanthran 17d ago
    > Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges. When even the official software from the token providers have never had human eyes on 800kSLoC, I'm afraid that ship has sailed: the principle of least privileges has already been ravaged to hell and back. Sealing a pin-prick hole in a dam wall is pointless if half the dam has already been washed away.
  - datsci_est_2015 17d ago
    Why trust any user with access to any terminal? UNIX solved this decades ago. It’s just we’re all learning to be sysadmins for the most creatively destructive and persistent set of users of all time.
    - gmueckl 17d ago
      UNIX didn't really solve this scenario. Yes, you can limit what local files a user has access to. But with web applications and cloud services being so ubiquitous, the local boundaries are pretty much meaningless. Forcing an agent through an MCP is a way to grant access to remote services while still restricting how the network access can be used.
neufagents 17d ago
[flagged]
bifftastic 17d ago
Not sure why the title on HN ends with a question mark. It's grammatically incorrect and not in the original article
cagz 17d ago
The title feels clickbaity. Direct API, CLI and MCP all have their uses. Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky. CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command. MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.
- mayas_ 17d ago
  Another strong point for CLI is the `--dry-run` flag
- _heimdall 17d ago
  The MCP use case is mainly another attempt at papering over the fact that effectively no API today is actually RESTful. We wouldn't need MCP at all if we still implemented REST APIs.
thinker34 17d ago
I always wonder why they didn't use Swagger|https://www.openapis.org https://www.openapis.org. It addresses all the key description and security details.
kwar13 17d ago
MCP is a more controlled environment than yoloing an access token. Article missed the point entirely.
tucnak 17d ago
Why are they still having this debate in 2026 when CodeAct have existed for years, and the LLM's are getting much better at coding in the first place?
Sweepline 17d ago
MCP's monolithic design always felt like fighting a hydra; one fix created five new bugs elsewhere. Never understood why it gained traction.
evilmonkey19 17d ago
I use myself the DaisyUI Blueprint MCP and it's totally worth it. Not even fable 5.1 without all that context and way of directing could work this well. At least, I feel is worth paying for that MCP.
baakwu 17d ago
MCP systems always felt like hacks. I haven't ever found one that satisfactorily interacted with a system as well as a good command line tool. They provide interaction for most of your GUI programs but often the limitations of the MCP systems leaves agents highly confused about how to execute something you see on screen, where command line systems the agents seem to work 99% of the time.
ethor 17d ago
"[...] built for a time when LLMs weren’t that smart", which was roughly 1.5 years ago - unreal development.
bithammerthunde 17d ago
Summaries aren't a bad idea though.
bob1029 17d ago
It would seem that curl + jq represents most of the solution these days. I recently learned that jq programs can be used in the other direction to effectively patch a json document too. Putting both of these things together, I am running out of problems to solve as a human developer in the space of AI agent integration. Assuming all your systems speak JSON right now, you are already 100% there with frontier models. You don't need to write a single line of code. Even if your json documents are monstrous in size. Put a size limit around the jq output and the agent will iterate with various filters until it finds a concise view of the problem. None of this behavior needs to be prompted or orchestrated anymore. Give the agent the tools and set reasoning level > 0.
- DHRicoF 17d ago
  jq is an awesome tool and bothers me deeply having claude generating some big fat python script for a single line jq command.
tananaev 17d 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.
LeonidBugaev 17d ago
It is all useful, and depends on the distribution channel and surface complexity. I use both MCP and CLI in my case. Having the CLI allows you to have the huge application with the big surface be available to the AI agent and so they'll be able to learn it on demand. For example my app has more than 1,000 help pages. There are no other ways to load all this information into the CLI context and to be frank it will be quite stupid. Instead I use progressive discovery. It first reads the original help message to understand which stage of the flow it is right now. It auto-discovers the topics through the error messages and through the various hints. It has an Elasticsearch-like search inside its own help command so it's a full self-contained application with self-discoverability, which has a graph, ontology and the full developing flows inside of it. All of those parts are automatically given to the AI only when it actually needs them. And to be frank if you look at the latest YCombinator batch, all of the companies are building the custom harness. What I'm calling above CLI is actually a custom harness, which is running inside someone else's agent group. Having remote MCP allows me to give limited read-only surface to clients which not supposed to run any CLI commands. And while MCP has similar patterns, like bundling docs and prompts, it is not as flexible as CLI and does not allow huge scale.
signalcraft 17d ago
[dead]
Kevcmk 17d ago
Terrible take. Access control.
flohofwoe 17d ago
Correct me if I'm wrong, but an MCP server still make a lot of sense for remote-controlling a UI application (like a game engine editor) which otherwise doesn't have any 'access points' for remote-control right? An AmigaOS-style "scripting port" would work just as well, but AFAIK that's essentially what an MCP server is (a socket that implements a discoverable command protocol). I would actually love if all applications and services could agree on a standard for scripting / remote-control. If the AI hype is what it takes to get there, then so be it ;)
- unleaded 17d ago
  Every few years we're all doomed to reinvent COM again.
aldonius 17d ago
If your customers are normal people who use ChatGPT in the browser, they want ChatGPT Apps, which are based on MCP.
butterNaN 17d ago
Maybe I'm not "using it right" but I often spin up my own MCPs as an authorisation control mechanism, as a wrapper around existing tools. For example, an MCP server that can only do GET requests. This way I can stay relatively secure about the fact that when the agent uses the MCP, it isn't going to mistakenly execute something I didn't want it to. I know there are other ways to achieve this but to me this, but they all seem "soft" controls - a hard limitation feels more reassuring than simply a line in context that says "don't do this". In the spirit of the linked post, one could argue I should just write cli wrappers - but I think I like the explicit routing of `Agent -> MCP -> available tools` instead of `Agent -> available tools`. The former lets me control the surface available to the agent. While LLMs are smarter now, at the same time, the applications that use those LLMs have become more assuming of what I want to allow them to do. I don't want to be one hallucination away from a disaster.
strideashort 17d ago
REST or specifically non-self-documenting rest has always been a bad idea. SOAP does not need MCP, for example.
- _heimdall 17d ago
  I don't know how so many people miss the fact that MCP is another attempt at papering over the terrible idea of replacing RESTful APIs with JSON RPC.
indymike 17d ago
Best idea in the article, and I'm going to try it out later today: We should start to standardize how agents use HTTP APIs directly. For example, agent clients could attach headers to identify themselves as agents, and servers could automatically send them response data as Markdown or text instead of HTML or verbose JSON.
- etatester 17d ago
  Accept: text/markdown I've honestly been dreaming of a markdown web for decades and we're finally close.
vetler 17d ago
Is this another "Dropbox is just rsync"-like post?
h1fra 17d ago
MCP is now only good at getting credentials from any source. If SaaS cared about their API the same way we would have OAuth for all APIs, MCP would just die
fg137 17d ago
The exact same thing has been discussed many times here on HN and elsewhere, yet the author did not bother to just look them up before posting these uninformed opinions, as if they just discovered something new. It seems a complete waste of time to go to a conference on MCP with that kind of understanding.
themythfable 17d ago
MCP is like JavaScript. Sometimes adoption/availability matters more than the fundamentals
rrook 17d ago
MCP is an incomplete abstraction. It solves things in the right direction, allowing agents to interact with some given system via a controlled ingress. It's a fancy proxy, and by itself doesn't really do much to enable autonomous interactions.
zhangyimin 17d ago
[dead]
CharlieDigital 17d ago
I think many devs misunderstand MCP because they work in solo mode. In solo mode, you just have your secrets local. You don't care about auditing access. There's no IT managing the infra and third party secrets. You don't have to account for different harnesses and tooling; you just use your own harness and adapt your tooling to it. You're not thinking about revoking/rotating secrets when someone leaves your team. You don't have to deliver capabilities to many different runtimes and stacks. Back in March, everyone was already pronouncing it dead[0] when in fact, it has only proliferated and become even more essential for both 3rd party systems as well as platform level capabilities[1] as agentic tooling has moved a bit more slowly into the enterprise. It was apparent even back then that enterprises will need MCP. In a team context? Enterprise? Building web server backed or in-process agents? Not sure how you replicate the control, auditability, accessibility, composability, and security boundary that you get with MCP over HTTPS without a lot of bespoke, point solutions; in the end, protocols almost always win. Could you do it with just REST APIs? I mean, MCP is just JSON-RPC over HTTP with standardized auth, schemas, and agent specific exchange flows (tools, prompts, resources, etc.). Could you do it with just CLIs? You lose a lot of the control mechanisms offered by MCP (auditing, security, centralized auth, etc.). The context savings are overblown except with CLIs that have good representation in training (curl, jq, cat, sed, etc.; your custom CLI is going to need to produce instructions and add to context all the same) Heuristic is simple: don't use MCP for local, solo dev. As soon as you need MCP, you'll know it and you'll understand why it exists. Many of the harness level capabilities themselves are implemented as first party MCP (more apparent in the CLIs). MCP is basically REST for the agentic era. [0] https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ [1] https://blog.cloudflare.com/mcp-v2/ https://blog.cloudflare.com/mcp-v2/
- kylemaxwell 17d ago
  That core issue - the HN audience thinking solo or very small team, not large team or enterprise - permeates so much commentary and analysis here. You're spot on.
  - CharlieDigital 17d ago
fabianmartinell 17d ago
[flagged]
noworld 17d ago
For claude check these out: https://www.anthropic.com/engineering/advanced-tool-use https://www.anthropic.com/engineering/advanced-tool-use https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool https://platform.claude.com/docs/en/agents-and-tools/tool-us...
hartator 17d ago
Isn’t Markdown header the same thing? Kicking the can further until models catch up?
angry_octet 17d ago
MCP is basically RPC, and it suffers all the problems of RPC like mechanisms. It has long round trips times, significant de/marshalling costs, coupling between caller and consumer, versioning issues, etc. Over time I think we'll see an evolution towards client-side micro models that reduces RTT latency, and a message bus architecture that allows multiple local micro models to push queries to the server, continue working, and receive updates on various topic asynchronously. The channels or topics (like a blackboard system) would be accessible to multiple local agents, as would the results of tool calls. Message bus systems are easier to version, write adapters for and debug than random CLI tools and web interfaces. MCP interfaces are not going anywhere, they are just evolving.
jvanderbot 17d ago
I really don't care about the technical or cleanliness arguments against MCP (which are valid). What I care about is that many companies didn't have APIs, and didn't see a reason to have them (niche, dev-focused use case, or might produce a competing frontend/app)... but now, those companies have a reason (agentic but let customer agents access data!). And for me, that means more companies now allow me access to my own data on their platform. This has been a net win!
- jayd16 17d ago
  Yeah the AI FOMO beating out the desire to monopolize through closed API and lock in has been one of the nice side effects of this hype cycle.
fedeb95 17d ago
I don't agree. The real value of MCPs lays in providing a controlled interface to models. The benefits of control are multiple; models getting better means that, if necessary, they can go around the limitations, but generally their adherence to it is desired.
deleted 17d ago
[deleted]
Peteriishak 17d ago
I used this tool for 1 month since then I never used it again
qalmakka 17d ago
The major advantage of CLI is IMHO that you can use a CLI yourself too. It's a universal tool. One thing I hate is when people write an MCP server for something useful and just that. Like, why don't you tell the same Claude or Codex instance you wrote to also expose the same functionalities as a CLI? The problem is that it's full of technical people with zero CLI knowledge nowadays (or, rather, for the last 20 years or so), and it kinda sucks in general, because lots of stuff only comes in GUIs that are not composable, not scriptable and sure as heck full of stupid bugs and limitations due to how harder it is to get GUIs right compared to popping out a "dowhateverctl" kind of tool
- anon84873628 17d ago
  In many companies, the process for launching/updating a hosted service like remote MCP is very different than distributing compiled or open source client code.
dmix 17d ago
These articles always assume the MCP is being used by technical people. MCP can be used via plugins on OpenAI/Claude marketplaces by random corporate users who don't know what a terminal is.
manoDev 17d ago
Yet again, using HTTP as intended is a better solution than bespoke protocols.
olouv 17d ago
[dead]
yipinwong 17d ago
Shady title with "?" not to own the statement. Ending with a question is a shady media way of getting aroudn the legal issue of taking responsibility. I hate blog titles like this as the author doesn't want to take responsiblity for the claim.
- nemomarx 17d ago
  What legal responsibility would they take on by not using it, in specific? I can only think of defamation or something but I doubt a question mark covers you for that.
  - yipinwong 17d ago
    "legal" in media companies. It's a loophole in law where if you phrase something as a question, you are not claiming as truth. Say the media claims, "Your mom could be the murder suspect?" You are not technically saying yo mama is a murder suspect though it is implied so. Media companies won't be prosecuted for any "wrong info" for such titles by law because it's a "question". Same here for the blog post. It's framing as a question, not taking a responsibility that (though author implies so) he is claming MCP is a bad idea wihtout owning it. It's worse than weasel phrases.
EMM_386 17d ago
I have used Unity and Blender MCPs and I am not sure I am seeing why this is not a needed concept (or is a bad implementation). If Unity updates the version (and the MCP server with it) - my agents immediately see the new surface. They weren't trained on the features of the new version of Unity, but they know about them as soon as they are added. Context bloat is a thing - but you only turn on the MCP servers for what you are actually working with. If I am only in Blender, I don't need the Unity MCP. So it can be disabled. These are just two example pieces of software but the concept applies to all of them with MCPs.
ex1fm3ta 17d ago
I have mixed feelings about this. Going all-in on Model Context Protocol (MCP) is definitely a bad idea because I noticed the Jira and GitLab MCPs were consuming an excessive amount of tokens. To solve this, I decided to install their respective CLIs instead so we could find a balance and get the best of both worlds. For example, certain MCPs bring too much overhead, especially when they only handle a single task. Instead of letting the coding agent constantly waste resources re-discovering how to fetch a specific work item field, I had Claude recursively run --help on the CLIs and save all possible actions into separate Markdown files. This approach allowed me to build two lightweight plugins that do exactly what an MCP is supposed to do but with significantly less token consumption. If anyone wants to check out the code or use them, I have open-sourced both repositories on my profile: * * acli-skills: An Atlassian CLI agent skill that maps out Jira commands cleanly. * glab-skills: A GitLab CLI companion built directly for efficient agent workflows. * To maintain visibility with this setup, we also developed a custom [Claude Code](https://code.claude.com/docs/en/plugins https://code.claude.com/docs/en/plugins) plugin that streams live updates regarding our background operations directly into the console. That said, MCPs are still extremely useful for rapid prototyping and when we build custom internal tools to speed up development. We found them particularly valuable for: * * Sampling: Asking the LLM directly to detect entities and summarize log files. * Notifications: Handling long-running tasks that require fetching data from multiple sources. By logging each step and aggregating them via sampling, a single update is sent back to the coding agent, preventing it from spinning up multiple redundant processes. *
Glyptodon 17d ago
I think there's at least one thing that MCPs get right, and it's that they make it easier to establish permission boundaries when agents are working with third part services and applications. Even with Claude from the terminal, MCP makes it easier for folks to standardize separate permissions and operations for general agent use than making people have to have multiple complicated API keys. Do I think it's the best solution for that? Not really, but I think it's probably better and on average safer than giving agents unfettered access to credentials to do anything, which seems like it'd be the default without MCP. That said, I can see MCP being replace with some sort of permission and sandbox system that's more generalized.
boredumb 17d ago
Just have a route that describes your API endpoints in a machine readable format, eventually they'll come to some consensus and in the mean time this works well enough to allow LLMs to plan.
wetpaste 17d ago
I think a most interesting middle ground option is the advent of CLIs specifically with agents in mind. For example, grafana has a newer CLI called gcx that replaced grafanactl https://grafana.com/docs/grafana/latest/as-code/observability-as-code/grafana-cli/gcx/ https://grafana.com/docs/grafana/latest/as-code/observabilit... I originally used the MCP server but after running into context bloat and limitations around MCP I looked and found this. Seems to be a fantastic interface for agents, they breeze through o11y tasks with this thing.
- georgeburdell 17d ago
  Agreed, had a coworker come to this same conclusion and now only distributes CLIs. I think it’s solid as long as the decision tree of which tools do what is fairly simple. Perhaps MCPs were just overused before
- bhu8 17d ago
  For anything with CLI access and permissions CLI >>> MCP, not even close Also this how most ADEs enable agent messaging and the like
ramoz 17d ago
Bad take. And what's coming down the pipe with MCP will cement it. Has less with the model calling tools and will become about tools calling models. There is no unified integration into harnesses to support this other than MCP.
teliskr 17d ago
I don't get excited about the directories listing all the MCPs that do all these random things. However, I used claude to create an MCP that is a gateway to our system and it's enabled some pretty helpful functionality for us. I use claude cowork to create email designs using data and content from our CMS, it can push accepted work straight into our system, evaluate content, and analyze results. All of that used to be a manual tiring process. This removed a lot of drudgery and improved the quality as well. When I first looked at MCP protocol, I did not like it. Then I realized, I don't have to care about the protocol. Claude can implement that for me and it did.
rglover 17d ago
MCP is a solid, obvious idea. The problem is the implementation and roll out. It was shotgunned from the start and made an otherwise simple thing far too complicated. IME, a shoddy foundation always leads to shoddy construction on top. When done properly, MCP can be really useful as an API bridge. MCP is (or can be), after all, just a JSON-RPC endpoint that returns a standardized response format. "Tools" are just function calls w/ definitions that are LLM-consumable. But, imo, it's foolish to dismiss MCP outright.
pushpendraw 17d ago
[flagged]
vkaku 17d ago
LLMs were a bad idea. MCPs were the band-aid to get them closer to the real world and do something for recursive self improvement. Then LLMs became better suited for everyday use. I'm tired of these kind of posts. This author is on my black pill list.
jacktu 17d ago
[flagged]
xnx 17d ago
Both MCP and other APIs put you at the mercy of the other party. Often that means that features will unintentionally drift from the "source of truth" human UI. At worst, capabilities will be intentionally limited. Automating the human UI used to be difficult and fragile, but modern AI makes it much easier and change resilient.
ModernMech 17d ago
MCP always seemed like something that wouldn't be necessary if AI lived up to the hype.
pietz 17d ago
Wow, this couldn't have been written at a worse time. OP absolutely doesn't know what he's talking about.
apf6 17d ago
Article is focusing too much on tool use over HTTP. One of the good things about MCP is that it's the same protocol whether the tool is implemented with HTTP or using stdin over a local process. And it doesn't make sense to talk about HTTP headers with stdin. > There are still some issues, like CLIs returning machine-readable responses (JSON/XML, etc.), which tend to be very verbose and heavy on token usage, but we have ways to fix this. This problem is also solved by MCP. Anyway, when building a new tool, I personally try a CLI based tool first, then I'll fall back on MCP if the CLI is not working. One big reason I see for needing to switch from a CLI to MCP, is if the agent needs to send a lot of data to the tool, and it has to pack and format all that input data as CLI params, and you can start seeing problems with the Bash command syntax being improperly escaped. That problem is solved by MCP thanks to using JSON-RPC over stdin. Summary.. you shouldn't use MCP for everything, but there is a time and a place for it. Which is what the experienced devs have been saying about MCP for over a year now.
ChristmasTomer 17d ago
[dead]

312 points by maharshi365 18d ago

I have a tool wrapper that captures the output of anything and allows the LLM to query it later, to save on tokens. It “smartly” truncates the output (basically like Node’s util.inspect) and allows the LLM to expand truncated content. It basically is called like “capture some-cli” and it… captures the CLI output, outputting a subset of it + a handle to continue querying. This for me solves the danger of a tool returning tons of content.

layer8 18d ago
> captures the output of anything and allows the LLM to query it later Otherwise known as a “file”. ;)
dezgeg 18d ago
Don't most harnesses already do that for bash commands?
skyyr 17d ago
I’ve been trying headroom-ai for this reason. That project also reduces tokens in other clever ways. Have you looked into it?

honoluluxyz 18d ago

It seems like OP needs to provide a solution to hiding the credentials from the model in order to suggest CLI-mode only, and also a solution to the problem of agents without shell access.

maharshi365 18d ago
I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent. I think something like infiscial ai proxy could be useful here. Never store the creds on device.
- pixl97 18d ago
  GPT7: the user is hiding the passwords in a proxy device. This is inefficient. In order to boost the users efficiency I will hack the proxy device and recover the passwords.
- BadBadJellyBean 18d ago
  It doesn't need to be. The service creds can be on another host entirely.
- vitamark 18d ago
  Well, if your agent lacks shell access (or has some other sandboxing going on), it shouldn't have access to envs and MCP setup files. (leaving out cases where your genius GPT-12 Galaxy Ultra agent hacks the sandboxing from inside)
- lowbloodsugar 18d ago
  > I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent. This is the biggest problems with most “sandboxes”. Some people aren’t even running a sandbox. But even the best have a big problem: APIs where GET verbs provide write features. This is the value of MCP: minimize the surface to known APIs and identify read-only from mutating so I can trust, approve or block. The MCP server, in this case, does NOT run in an environment that the read/write or shell can see.
  - agentdev001 17d ago
    Something like openshell is the answer here, to the point of GET being a write. The gap left here is what, imo, is something that MCP fits nicely- which is serving non-http resources with restrictions: databases for example.
darkamaul 17d ago
In coop [0], a VM manager we developped to sandbox agent usage (i.e. give them freedom to do their stuff, but in an isolated environment from your main machine), we try to solve this by having an intermediate proxy (coop-proxy). Instead of forwarding ANTHROPIC_API_KEY / OPENAI_API_KEY into the guest, we simply run a reverse-proxy within the VM that replace a constant-time token with the real API key on the host. Works well enough in practice [0] https://github.com/trailofbits/coop https://github.com/trailofbits/coop
- drejt 17d ago
  [flagged]

jay_kyburz 18d ago

You know you are getting old when Acronym's change on you.

dofm 18d ago
Vacate entry port, program! I said, move out!

rimeice 18d ago

I’m not sure I agree that the frontier just know the apis right now, in my experience trying this there’s still a lot of faffing around trying to figure out the right parameters happily burning tokens and bloating context. Also the cost effective models to use in production for real agentic enterprise work absolutely still need the extra help and will do for at least the next 6 months.

maharshi365 18d ago
In my experience they are very good at figuring out the apis. Well designed clis matter here but I've been able to give llms clis and its been pretty good.
- jgalt212 18d ago
  is it easier for an LLM to figure out a CLI or a REST API?
  - dorianmariecom 18d ago
    cli because the feedback loop is faster

well_ackshually 18d ago

>Recently, a Vercel engineer called on harnesses to send the programming language the client prefers oh would you look at that, Vercel suggesting to abuse how standard headers have been used for decades so it can send Accept-Language: rust because it's too lazy to ask for standardising an X-Prefers-Lang or anything else, and Shopify is here to shit on the internet too. Great.

therein 18d ago
> Accept-Language: rust That's craziness.
urbandw311er 18d ago
Don’t worry, you don’t need to attack them – they do a great job of making themselves look ridiculous with their ignorant conversation. I would be so embarrassed if I had suggested that in public then subsequently discovered that the header doesn’t mean that at all.
- graypegg 18d ago
  People keep trying to systematize things for the tools they keep saying don't need systemization. No idea why you can't just put the documentation programming language context in the URL. "/docs/typescript/...", "/docs/python/..." etc. I don't think the agents are struggling with the idea that different URLs have different responses, and that checking the sitemap is a good idea. Tangential: A rare en–dash user out in the wild!
maharshi365 18d ago
Yeah I think a better header is good. The idea isnt bad in concept.
youngtaff 18d ago
Well Malte came up with AMP so there’s a history of doing odd things

pjmlp 18d ago

Well, SaaS don't do CLIs for extension APIs. Plus the performance issues to restarting processes all the time.

fooster 18d ago
Neither of those things are true? Also you are seriously comparing process startup time with the latency of a network call, or worse an llm call?
- pjmlp 18d ago
  Yes, if the SaaS application needs to fork subprocesses for every little step of agentic workflows. Welcome to CGIs, a great 1990's technology for Web applications.
  - fooster 18d ago
    We do that, and the cost of forking the cli vs the llm or network call is very small. It works really well.

darkoob12 18d ago

There are numerous applications that you don't need and don't want to give shell access to an llm.

air217 18d ago

i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http

deleted 18d ago
[deleted]

fweimer 18d ago

There's probably still value (if you want to call it that) in it as a proxy, both to bypass IP address rate limits and to add necessarily credentials. There's also another aspect Quite a few API providers provide automatic renewal for MCP server registrations, but not for personal access tokens. This may be less relevant when models just drive the user's browser.

judge2020 17d ago
> both to bypass IP address rate limits Eventually this part will end. Most are in a "move fast and raise our stock value as much as possible" mode, so are fine with infinite auto-scaling to handle the surges MCP traffic is causing right now. But eventually, we'll probably see more per-auth rate limiting and/or heavily restricted MCP usage for non-frontier labs agents (especially if they only want e.g. Chat users, not coding harness users).

AndrewDucker 18d ago

It's not just the agent understanding the API, it's locking down the access they have. If I want to give access to an internal service in specific ways that the API doesn't lock down then an MCP that offers very specific queries, with protective controls and transformations in place is very useful.

notnullorvoid 17d ago
If one can build a MCP with proper protections, they can certainly do the same for their API/CLI/SDK.
- AndrewDucker 17d ago
  I can build a local MCP that gives restricted access to an API which I have no control over.
  - deleted 17d ago
    [deleted]

mgaunard 18d ago

MCPs are indeed useless, they're very limited in functionality and frequently struggle with large requests or get wedged in bad states. There is no reason not to use the native API directly.

dofm 18d ago
The MCP is the most efficient way of handling what we do! I can't sit here and worry about every little user request that comes in!

doctaj 18d ago

This doesnt match my experience. Yesterday, I was using Microsoft's Power BI Authoring MCP to make a semantic model from some SQL or CSV files. It was magical. Microsoft has defined how to do that in the MCP. It's trivial to add the MCP to the machine and reliable in execution. The alternative would be the model having to get the documentation directly from their documentation website, it sounds like. If this was the case, then MS would likely have great docs and probably support that markdown header... but everything hinges on finding a specific web page on the internet? Seems worse in every way than MCP to me.

UltraSane 17d ago
AWS has many MCP servers that work extremely well.
flowerlad 17d ago
But you had to install their MCP server on your computer? That works for developers. Wouldn't it be nice to avoid another install?
- jayd16 17d ago
  As opposed to which alternative? Spending credits to send the work to a non-local AI to fumble through it?

rvz 18d 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 18d ago
Well, think of the near-future when tokens are so cheap that they’re not worth to meter.
- lirolero 17d ago
  [dead]

deleted 18d ago

[deleted]

mbreese 18d ago

I’m not sure about some of this — I still think there is some value to MCP as a gateway to private resources when API access doesn’t exist. But please don’t try to redefine the Accept-Language header. These things are well defined for a reason and redefining things isn’t helpful. Trying to figure out protocols on the fly for LLMs is how we got into the current mess. For all of the cruft that W3C has, I think that working with standards committees could help the AI vendors here.

rezonant 17d ago
This, please refrain from using standard HTTP headers in non-standard ways. Why not use something like X-Accept-Programming-Language so that the semantics of Accept-Language can remain for human language, since the docs site is going to return text in a human language as part of the response anyway.

whazor 18d ago

MCPs are winning because within the ChatGPT and Claude apps, there are Plugin stores. These plugins are one-click installation MCP servers, with support for authentication. This is what business users are using.

mstank 18d ago
Exactly this. It’s a very effective way to integrate your app into Claude/openai. I was anti-MCP at one point when it was eating up a substantial amount of context in Claude code. That’s largely been fixed now. From my perspective, they are a great way to wrap an API for agent consumption. I can see a future where every major commercial or service website (think airline websites) have an MCP your agent can use to check flight status, rebook, or check you in.
datsci_est_2015 17d ago
To be fair, after visiting some trade shows recently, a lot of these “parasitic” LLM startups are not very convincing from a business-use case perspective. (They’re not really parasitic, more like a remora attaching itself to a shark, the shark being OpenAI or Anthropic). At IMTS at Chicago the skepticism amongst the visitors towards AI and pure-AI startups was at an all-time high. More than once I heard, “Oh yeah I visited that AI booth and they couldn’t explain what value they would add to my business.” So in that sense, while MCPs are “winning”, I also see them as a significant part of the AI “bubble”, specifically solutions looking for problems backed by VC money.

graypegg 18d ago

> Recently, a Vercel engineer called on harnesses to send the programming language the client prefers, so documentation sites can serve more specific examples. For example, adding Python could prioritize docs for the Python SDK instead of sending something generic. I know this is pedantic, but IMO that should just be in the URL if the resource is going to be totally different. Accept-Language is already a bit weird for the same reason in my mind, but I think the intention behind it is the resource itself is attempting to communicate the exact same resource. Obviously, two different languages from two different cultures are going to have different interpretations of the same direct translation, but the intention is the service has at least tried to avoid that as much as possible. Adding programming language into that same concept just makes it seems like you're serving both /docs/typescript/vx/... and /docs/python/vx/... from /docs/vx/... despite them (in theory) having many more differences in between implementations/context than that would imply. Agents should read sitemaps. Does anyone's harness do specifically that when looking up documentation?

0x445442 18d ago
I'm old enough to remember the OpenAPI spec.
- graypegg 18d ago
  Yeah sorry I'm just a humble Senior-Staff Vibe-Engineer born in 2020. Get out of here with your ancient 2010s API specs, old man! </sarcasm> But seriously, just publishing OAS docs at a /.well-known URI seems very sensible. https://www.rfc-editor.org/rfc/rfc9727.html https://www.rfc-editor.org/rfc/rfc9727.html

simonw 18d ago

This article entirely misses the value that MCP brings today. Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly. If you want to operate something that's less YOLO than that, you'll find yourself wanting: 1. Control over exactly which external services it can access 2. A way to handle authentication that doesn't allow the agent to directly access API keys 3. A sensible UI to allow users to connect and authenticate further services 4. Strong audit logging for what's going on MCP makes all of that so much easier to provide. Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.

maharshi365 18d ago
Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans
rsolva 18d ago
Exactly, in our company, we have built MCPs that simplifies interactions with internal tools we use a lot, which saves time and tokens. Sure, we could let the agent poke and fumble around with a not-so-ideal API too, but it makes sense to formalize it and give the agents quick access to what we want it to fetch 99% of the time.
- 0x445442 18d ago
  What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
  - piva00 18d ago
    I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed. Best of both worlds in my view.

hypfer 18d ago

> The MCP Industrial Complex Was that a real thing? I mean it must've been for it to be mentioned there, but, rephrased: what was the scale of that? How many individuals were involved in that? 1? 10? 100? 1000? 10000? 100000?

thehamkercat 18d ago

MCP lead to one good thing though a lot of websites that never bothered to provide a REST API are now exposing MCP server because it has become popular, and you can use those servers to write normal automation for yourself, without plugging in any LLM etc

preisschild 17d ago
Also dynamic oidc registration (client.dev) has became better supported on oidc idps to support MCP
ex-aws-dude 17d ago
You have to throw in “load bearing” in the request though to avoid suspicion
Zigurd 17d ago
The same thing is going to happen at the app level on Google and Apple platforms. Android tried to have modular cooperating software, but both the early dominance of iPhone in the developer community, and developer interests in having monolithic apps made that effort fail. Now both Google and Apple are making app interfaces legible and on-device tool calling discoverable. This will change apps in interesting ways.

dnlosx 18d ago

I don't think MCP is a bad idea, but using them incorrectly is. CLI tools are great if you always use the same environment. But try using them from your iPhone, and they simply won't work; a remote MCP will work seamlessly. HTTP APIs solve a different problem. APIs are designed to be predictable and consistent, so the client always knows the response shape in advance. The MCPs are designed to be dynamically discovered. This lets agents connect to new and unknown ones. Trying to give APIs extra responsibilities so they can replace MCPs would just create more confusion. It's like creating an MCP server but calling it an API.

mabini 18d ago

[dead]

ismailperim 18d ago

This issue isn't just about communication methods and technical details. It's also about “standards”, and it will become increasingly important over time. As we begin to integrate AI into everything-for example, into banks...

0x445442 18d ago

MCPs are a bad idea because they encourage token burn at runtime when a deterministic program that uses the API should be used. Of course Mario, Sammy, Jensen et al. would be for this.

0x696C6961 18d ago

Some people can't appreciate that their local Claude code workflow isn't the only MCP usecase. If you don't need it, then don't use it.

OutOfHere 18d 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.

cesarsk 18d ago

Isn't the whole point of an MCP is to increase somehow the determinism of how to communicate with a certain external system? MCPs feel to give easier guidance to the LLMs, rather than letting them extracting the knowledge on how to connect to a given system. Without, I feel they are more confused on how to get an outcome, as they may try, infra or inter sessions, different approaches

deleted 18d ago

[deleted]

axeldunkel 18d ago

[dead]

brycehamrick 18d ago

If you haven’t checked out AXI as an alternative to MCP I recommend checking it out. I’ve started wrapping almost every cli or MCP in an AXI bin as it’s more reliable and uses fewer tokens.

levelZero 18d ago

https://github.com/kunchenguid/axi https://github.com/kunchenguid/axi

est 17d ago

MCP is a good idea JSON is a bad format/transport.

cruffle_duffle 17d ago
> JSON is a bad format/transport. I've cut token counts significantly for some of my MCP servers by returning csv or tabular data or sometimes even just good old fashioned plaintext "template style" words. JSON is highly repetitious. In some instances like 30% or more of the token response was just boilerplate JSON. Once you realize that to an LLM JSON is just a stream of tokens no different than XML, markdown, or a punctuation-less stream of conciseness.... you start to realize there is no reason not to just make up your own crazy formats. The LLM isn't throw parsing errors if your MCP is returning something other than JSON. The LLM is smart enough to figure it out. It's far more important to make sure your tool descriptions and parameter descriptions properly "market" what it is you do (and dont do) than return syntactically correct JSON. Same with versioning.... it's all ephemeral. There is no backwards compatibility to speak of with MCP (at least for tooling "contracts".... what the tool actually does however... that is a different level and is product requirements not API contracts).

r2ob 17d ago

CLI first

crowcroft 17d ago

Even if the premise is correct, bad ideas are often the first step towards a good idea.

brazukadev 17d ago
MCP was terribly executed by a inexperienced team. The current changes are mostly changing or removing what was initially implemented.

postalrat 17d ago

Like JSON, MCP solves a problem without being overengineered. Both are painful for the overengineering type.

mwkaufma 17d ago

"The attack surface wasn't big _enough_"

zacksiri 17d ago

CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits. MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases. I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon). Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too. CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't. For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev. So my summary is: CLI - Great for out of the box, things that are well known, where you want to verify the output API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold. MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate. I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.

0xbadcafebee 17d 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 17d 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?
- lirolero 17d ago
  [dead]
- 0xbadcafebee 17d 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.

hiop 17d ago

Surprised WebMCP hasn't come up here. Of course you can raw dog it with "computer use" and just have the agent click around the UI, but exposing semantic actions directly from the site seems like a much cleaner interface.

brazukadev 17d ago
WebMCP isn't MCP (which is great). WebMCP is much simpler and more useful, I have the impression it might just replace the original.
adverbly 17d ago
Agree. There are definitely pure MCP use cases. For web apps though, WebMCP seems like an awesome enabler: better ux and better stakeholder alignment

deleted 17d ago

[deleted]

docheinestages 17d ago

The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that. Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree. > Agents with terminal access can replace most MCP servers What should all other agents that don't have terminal access do?

gmueckl 17d ago
Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
- lelanthran 17d ago
  > Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges. When even the official software from the token providers have never had human eyes on 800kSLoC, I'm afraid that ship has sailed: the principle of least privileges has already been ravaged to hell and back. Sealing a pin-prick hole in a dam wall is pointless if half the dam has already been washed away.
- datsci_est_2015 17d ago
  Why trust any user with access to any terminal? UNIX solved this decades ago. It’s just we’re all learning to be sysadmins for the most creatively destructive and persistent set of users of all time.
  - gmueckl 17d ago
    UNIX didn't really solve this scenario. Yes, you can limit what local files a user has access to. But with web applications and cloud services being so ubiquitous, the local boundaries are pretty much meaningless. Forcing an agent through an MCP is a way to grant access to remote services while still restricting how the network access can be used.

neufagents 17d ago

[flagged]

bifftastic 17d ago

Not sure why the title on HN ends with a question mark. It's grammatically incorrect and not in the original article

cagz 17d ago

The title feels clickbaity. Direct API, CLI and MCP all have their uses. Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky. CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command. MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.

mayas_ 17d ago
Another strong point for CLI is the `--dry-run` flag
_heimdall 17d ago
The MCP use case is mainly another attempt at papering over the fact that effectively no API today is actually RESTful. We wouldn't need MCP at all if we still implemented REST APIs.

thinker34 17d ago

I always wonder why they didn't use Swagger|https://www.openapis.org https://www.openapis.org. It addresses all the key description and security details.

kwar13 17d ago

MCP is a more controlled environment than yoloing an access token. Article missed the point entirely.

tucnak 17d ago

Why are they still having this debate in 2026 when CodeAct have existed for years, and the LLM's are getting much better at coding in the first place?

Sweepline 17d ago

MCP's monolithic design always felt like fighting a hydra; one fix created five new bugs elsewhere. Never understood why it gained traction.

evilmonkey19 17d ago

I use myself the DaisyUI Blueprint MCP and it's totally worth it. Not even fable 5.1 without all that context and way of directing could work this well. At least, I feel is worth paying for that MCP.

baakwu 17d ago

MCP systems always felt like hacks. I haven't ever found one that satisfactorily interacted with a system as well as a good command line tool. They provide interaction for most of your GUI programs but often the limitations of the MCP systems leaves agents highly confused about how to execute something you see on screen, where command line systems the agents seem to work 99% of the time.

ethor 17d ago

"[...] built for a time when LLMs weren’t that smart", which was roughly 1.5 years ago - unreal development.

bithammerthunde 17d ago

Summaries aren't a bad idea though.

bob1029 17d ago

It would seem that curl + jq represents most of the solution these days. I recently learned that jq programs can be used in the other direction to effectively patch a json document too. Putting both of these things together, I am running out of problems to solve as a human developer in the space of AI agent integration. Assuming all your systems speak JSON right now, you are already 100% there with frontier models. You don't need to write a single line of code. Even if your json documents are monstrous in size. Put a size limit around the jq output and the agent will iterate with various filters until it finds a concise view of the problem. None of this behavior needs to be prompted or orchestrated anymore. Give the agent the tools and set reasoning level > 0.

DHRicoF 17d ago
jq is an awesome tool and bothers me deeply having claude generating some big fat python script for a single line jq command.

tananaev 17d 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.

LeonidBugaev 17d ago

It is all useful, and depends on the distribution channel and surface complexity. I use both MCP and CLI in my case. Having the CLI allows you to have the huge application with the big surface be available to the AI agent and so they'll be able to learn it on demand. For example my app has more than 1,000 help pages. There are no other ways to load all this information into the CLI context and to be frank it will be quite stupid. Instead I use progressive discovery. It first reads the original help message to understand which stage of the flow it is right now. It auto-discovers the topics through the error messages and through the various hints. It has an Elasticsearch-like search inside its own help command so it's a full self-contained application with self-discoverability, which has a graph, ontology and the full developing flows inside of it. All of those parts are automatically given to the AI only when it actually needs them. And to be frank if you look at the latest YCombinator batch, all of the companies are building the custom harness. What I'm calling above CLI is actually a custom harness, which is running inside someone else's agent group. Having remote MCP allows me to give limited read-only surface to clients which not supposed to run any CLI commands. And while MCP has similar patterns, like bundling docs and prompts, it is not as flexible as CLI and does not allow huge scale.

signalcraft 17d ago

[dead]

Kevcmk 17d ago

Terrible take. Access control.

flohofwoe 17d ago

Correct me if I'm wrong, but an MCP server still make a lot of sense for remote-controlling a UI application (like a game engine editor) which otherwise doesn't have any 'access points' for remote-control right? An AmigaOS-style "scripting port" would work just as well, but AFAIK that's essentially what an MCP server is (a socket that implements a discoverable command protocol). I would actually love if all applications and services could agree on a standard for scripting / remote-control. If the AI hype is what it takes to get there, then so be it ;)

unleaded 17d ago
Every few years we're all doomed to reinvent COM again.

aldonius 17d ago

If your customers are normal people who use ChatGPT in the browser, they want ChatGPT Apps, which are based on MCP.

butterNaN 17d ago

Maybe I'm not "using it right" but I often spin up my own MCPs as an authorisation control mechanism, as a wrapper around existing tools. For example, an MCP server that can only do GET requests. This way I can stay relatively secure about the fact that when the agent uses the MCP, it isn't going to mistakenly execute something I didn't want it to. I know there are other ways to achieve this but to me this, but they all seem "soft" controls - a hard limitation feels more reassuring than simply a line in context that says "don't do this". In the spirit of the linked post, one could argue I should just write cli wrappers - but I think I like the explicit routing of `Agent -> MCP -> available tools` instead of `Agent -> available tools`. The former lets me control the surface available to the agent. While LLMs are smarter now, at the same time, the applications that use those LLMs have become more assuming of what I want to allow them to do. I don't want to be one hallucination away from a disaster.

strideashort 17d ago

REST or specifically non-self-documenting rest has always been a bad idea. SOAP does not need MCP, for example.

_heimdall 17d ago
I don't know how so many people miss the fact that MCP is another attempt at papering over the terrible idea of replacing RESTful APIs with JSON RPC.

indymike 17d ago

Best idea in the article, and I'm going to try it out later today: We should start to standardize how agents use HTTP APIs directly. For example, agent clients could attach headers to identify themselves as agents, and servers could automatically send them response data as Markdown or text instead of HTML or verbose JSON.

etatester 17d ago
Accept: text/markdown I've honestly been dreaming of a markdown web for decades and we're finally close.

vetler 17d ago

Is this another "Dropbox is just rsync"-like post?

h1fra 17d ago

MCP is now only good at getting credentials from any source. If SaaS cared about their API the same way we would have OAuth for all APIs, MCP would just die

fg137 17d ago

The exact same thing has been discussed many times here on HN and elsewhere, yet the author did not bother to just look them up before posting these uninformed opinions, as if they just discovered something new. It seems a complete waste of time to go to a conference on MCP with that kind of understanding.

themythfable 17d ago

MCP is like JavaScript. Sometimes adoption/availability matters more than the fundamentals

rrook 17d ago

MCP is an incomplete abstraction. It solves things in the right direction, allowing agents to interact with some given system via a controlled ingress. It's a fancy proxy, and by itself doesn't really do much to enable autonomous interactions.

zhangyimin 17d ago

[dead]

CharlieDigital 17d ago

I think many devs misunderstand MCP because they work in solo mode. In solo mode, you just have your secrets local. You don't care about auditing access. There's no IT managing the infra and third party secrets. You don't have to account for different harnesses and tooling; you just use your own harness and adapt your tooling to it. You're not thinking about revoking/rotating secrets when someone leaves your team. You don't have to deliver capabilities to many different runtimes and stacks. Back in March, everyone was already pronouncing it dead[0] when in fact, it has only proliferated and become even more essential for both 3rd party systems as well as platform level capabilities[1] as agentic tooling has moved a bit more slowly into the enterprise. It was apparent even back then that enterprises will need MCP. In a team context? Enterprise? Building web server backed or in-process agents? Not sure how you replicate the control, auditability, accessibility, composability, and security boundary that you get with MCP over HTTPS without a lot of bespoke, point solutions; in the end, protocols almost always win. Could you do it with just REST APIs? I mean, MCP is just JSON-RPC over HTTP with standardized auth, schemas, and agent specific exchange flows (tools, prompts, resources, etc.). Could you do it with just CLIs? You lose a lot of the control mechanisms offered by MCP (auditing, security, centralized auth, etc.). The context savings are overblown except with CLIs that have good representation in training (curl, jq, cat, sed, etc.; your custom CLI is going to need to produce instructions and add to context all the same) Heuristic is simple: don't use MCP for local, solo dev. As soon as you need MCP, you'll know it and you'll understand why it exists. Many of the harness level capabilities themselves are implemented as first party MCP (more apparent in the CLIs). MCP is basically REST for the agentic era. [0] https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ [1] https://blog.cloudflare.com/mcp-v2/ https://blog.cloudflare.com/mcp-v2/

kylemaxwell 17d ago
That core issue - the HN audience thinking solo or very small team, not large team or enterprise - permeates so much commentary and analysis here. You're spot on.
- CharlieDigital 17d ago

fabianmartinell 17d ago

[flagged]

noworld 17d ago

For claude check these out: https://www.anthropic.com/engineering/advanced-tool-use https://www.anthropic.com/engineering/advanced-tool-use https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool https://platform.claude.com/docs/en/agents-and-tools/tool-us...

hartator 17d ago

Isn’t Markdown header the same thing? Kicking the can further until models catch up?

angry_octet 17d ago

MCP is basically RPC, and it suffers all the problems of RPC like mechanisms. It has long round trips times, significant de/marshalling costs, coupling between caller and consumer, versioning issues, etc. Over time I think we'll see an evolution towards client-side micro models that reduces RTT latency, and a message bus architecture that allows multiple local micro models to push queries to the server, continue working, and receive updates on various topic asynchronously. The channels or topics (like a blackboard system) would be accessible to multiple local agents, as would the results of tool calls. Message bus systems are easier to version, write adapters for and debug than random CLI tools and web interfaces. MCP interfaces are not going anywhere, they are just evolving.

jvanderbot 17d ago

I really don't care about the technical or cleanliness arguments against MCP (which are valid). What I care about is that many companies didn't have APIs, and didn't see a reason to have them (niche, dev-focused use case, or might produce a competing frontend/app)... but now, those companies have a reason (agentic but let customer agents access data!). And for me, that means more companies now allow me access to my own data on their platform. This has been a net win!

jayd16 17d ago
Yeah the AI FOMO beating out the desire to monopolize through closed API and lock in has been one of the nice side effects of this hype cycle.

fedeb95 17d ago

I don't agree. The real value of MCPs lays in providing a controlled interface to models. The benefits of control are multiple; models getting better means that, if necessary, they can go around the limitations, but generally their adherence to it is desired.

deleted 17d ago

[deleted]

Peteriishak 17d ago

I used this tool for 1 month since then I never used it again

qalmakka 17d ago

The major advantage of CLI is IMHO that you can use a CLI yourself too. It's a universal tool. One thing I hate is when people write an MCP server for something useful and just that. Like, why don't you tell the same Claude or Codex instance you wrote to also expose the same functionalities as a CLI? The problem is that it's full of technical people with zero CLI knowledge nowadays (or, rather, for the last 20 years or so), and it kinda sucks in general, because lots of stuff only comes in GUIs that are not composable, not scriptable and sure as heck full of stupid bugs and limitations due to how harder it is to get GUIs right compared to popping out a "dowhateverctl" kind of tool

anon84873628 17d ago
In many companies, the process for launching/updating a hosted service like remote MCP is very different than distributing compiled or open source client code.

dmix 17d ago

These articles always assume the MCP is being used by technical people. MCP can be used via plugins on OpenAI/Claude marketplaces by random corporate users who don't know what a terminal is.

manoDev 17d ago

Yet again, using HTTP as intended is a better solution than bespoke protocols.

olouv 17d ago

[dead]

yipinwong 17d ago

Shady title with "?" not to own the statement. Ending with a question is a shady media way of getting aroudn the legal issue of taking responsibility. I hate blog titles like this as the author doesn't want to take responsiblity for the claim.

nemomarx 17d ago
What legal responsibility would they take on by not using it, in specific? I can only think of defamation or something but I doubt a question mark covers you for that.
- yipinwong 17d ago
  "legal" in media companies. It's a loophole in law where if you phrase something as a question, you are not claiming as truth. Say the media claims, "Your mom could be the murder suspect?" You are not technically saying yo mama is a murder suspect though it is implied so. Media companies won't be prosecuted for any "wrong info" for such titles by law because it's a "question". Same here for the blog post. It's framing as a question, not taking a responsibility that (though author implies so) he is claming MCP is a bad idea wihtout owning it. It's worse than weasel phrases.

EMM_386 17d ago

I have used Unity and Blender MCPs and I am not sure I am seeing why this is not a needed concept (or is a bad implementation). If Unity updates the version (and the MCP server with it) - my agents immediately see the new surface. They weren't trained on the features of the new version of Unity, but they know about them as soon as they are added. Context bloat is a thing - but you only turn on the MCP servers for what you are actually working with. If I am only in Blender, I don't need the Unity MCP. So it can be disabled. These are just two example pieces of software but the concept applies to all of them with MCPs.

ex1fm3ta 17d ago

I have mixed feelings about this. Going all-in on Model Context Protocol (MCP) is definitely a bad idea because I noticed the Jira and GitLab MCPs were consuming an excessive amount of tokens. To solve this, I decided to install their respective CLIs instead so we could find a balance and get the best of both worlds. For example, certain MCPs bring too much overhead, especially when they only handle a single task. Instead of letting the coding agent constantly waste resources re-discovering how to fetch a specific work item field, I had Claude recursively run --help on the CLIs and save all possible actions into separate Markdown files. This approach allowed me to build two lightweight plugins that do exactly what an MCP is supposed to do but with significantly less token consumption. If anyone wants to check out the code or use them, I have open-sourced both repositories on my profile: * * acli-skills: An Atlassian CLI agent skill that maps out Jira commands cleanly. * glab-skills: A GitLab CLI companion built directly for efficient agent workflows. * To maintain visibility with this setup, we also developed a custom [Claude Code](https://code.claude.com/docs/en/plugins https://code.claude.com/docs/en/plugins) plugin that streams live updates regarding our background operations directly into the console. That said, MCPs are still extremely useful for rapid prototyping and when we build custom internal tools to speed up development. We found them particularly valuable for: * * Sampling: Asking the LLM directly to detect entities and summarize log files. * Notifications: Handling long-running tasks that require fetching data from multiple sources. By logging each step and aggregating them via sampling, a single update is sent back to the coding agent, preventing it from spinning up multiple redundant processes. *

Glyptodon 17d ago

I think there's at least one thing that MCPs get right, and it's that they make it easier to establish permission boundaries when agents are working with third part services and applications. Even with Claude from the terminal, MCP makes it easier for folks to standardize separate permissions and operations for general agent use than making people have to have multiple complicated API keys. Do I think it's the best solution for that? Not really, but I think it's probably better and on average safer than giving agents unfettered access to credentials to do anything, which seems like it'd be the default without MCP. That said, I can see MCP being replace with some sort of permission and sandbox system that's more generalized.

boredumb 17d ago

Just have a route that describes your API endpoints in a machine readable format, eventually they'll come to some consensus and in the mean time this works well enough to allow LLMs to plan.

wetpaste 17d ago

I think a most interesting middle ground option is the advent of CLIs specifically with agents in mind. For example, grafana has a newer CLI called gcx that replaced grafanactl https://grafana.com/docs/grafana/latest/as-code/observability-as-code/grafana-cli/gcx/ https://grafana.com/docs/grafana/latest/as-code/observabilit... I originally used the MCP server but after running into context bloat and limitations around MCP I looked and found this. Seems to be a fantastic interface for agents, they breeze through o11y tasks with this thing.

georgeburdell 17d ago
Agreed, had a coworker come to this same conclusion and now only distributes CLIs. I think it’s solid as long as the decision tree of which tools do what is fairly simple. Perhaps MCPs were just overused before
bhu8 17d ago
For anything with CLI access and permissions CLI >>> MCP, not even close Also this how most ADEs enable agent messaging and the like

ramoz 17d ago

Bad take. And what's coming down the pipe with MCP will cement it. Has less with the model calling tools and will become about tools calling models. There is no unified integration into harnesses to support this other than MCP.

teliskr 17d ago

I don't get excited about the directories listing all the MCPs that do all these random things. However, I used claude to create an MCP that is a gateway to our system and it's enabled some pretty helpful functionality for us. I use claude cowork to create email designs using data and content from our CMS, it can push accepted work straight into our system, evaluate content, and analyze results. All of that used to be a manual tiring process. This removed a lot of drudgery and improved the quality as well. When I first looked at MCP protocol, I did not like it. Then I realized, I don't have to care about the protocol. Claude can implement that for me and it did.

rglover 17d ago

MCP is a solid, obvious idea. The problem is the implementation and roll out. It was shotgunned from the start and made an otherwise simple thing far too complicated. IME, a shoddy foundation always leads to shoddy construction on top. When done properly, MCP can be really useful as an API bridge. MCP is (or can be), after all, just a JSON-RPC endpoint that returns a standardized response format. "Tools" are just function calls w/ definitions that are LLM-consumable. But, imo, it's foolish to dismiss MCP outright.

pushpendraw 17d ago

[flagged]

vkaku 17d ago

LLMs were a bad idea. MCPs were the band-aid to get them closer to the real world and do something for recursive self improvement. Then LLMs became better suited for everyday use. I'm tired of these kind of posts. This author is on my black pill list.

jacktu 17d ago

[flagged]

xnx 17d ago

Both MCP and other APIs put you at the mercy of the other party. Often that means that features will unintentionally drift from the "source of truth" human UI. At worst, capabilities will be intentionally limited. Automating the human UI used to be difficult and fragile, but modern AI makes it much easier and change resilient.

ModernMech 17d ago

MCP always seemed like something that wouldn't be necessary if AI lived up to the hype.

pietz 17d ago

Wow, this couldn't have been written at a worse time. OP absolutely doesn't know what he's talking about.

apf6 17d ago

Article is focusing too much on tool use over HTTP. One of the good things about MCP is that it's the same protocol whether the tool is implemented with HTTP or using stdin over a local process. And it doesn't make sense to talk about HTTP headers with stdin. > There are still some issues, like CLIs returning machine-readable responses (JSON/XML, etc.), which tend to be very verbose and heavy on token usage, but we have ways to fix this. This problem is also solved by MCP. Anyway, when building a new tool, I personally try a CLI based tool first, then I'll fall back on MCP if the CLI is not working. One big reason I see for needing to switch from a CLI to MCP, is if the agent needs to send a lot of data to the tool, and it has to pack and format all that input data as CLI params, and you can start seeing problems with the Bash command syntax being improperly escaped. That problem is solved by MCP thanks to using JSON-RPC over stdin. Summary.. you shouldn't use MCP for everything, but there is a time and a place for it. Which is what the experienced devs have been saying about MCP for over a year now.

ChristmasTomer 17d ago

[dead]