4 ms·

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

by simonw 6d 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 6d ago
Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans
rsolva 6d 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 6d 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 6d 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.
  - 0x696C6961 5d ago
    Yeah that's a good idea. Then we should standardize these tools and find an easy way for agents to discover and use them. ... Oh wait
    - mjmas 5d ago
      And call it not-closed API or something like that.
    - 0x445442 5d ago
      Just tell the clanker to read the api documentation that should already exist. You dont need an MCP server for that.
    - jimbokun 5d ago
      Congrats you just invented the Unix shell!
  - locknitpicker 5d ago
    > 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. The MCP is the deterministic program. You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface. It's the interface for your deterministic program. That's it.
    - 8note 5d ago
      they were suggesting that you take the agent out of the run time tool usage
      - locknitpicker 5d ago
        > they were suggesting that you take the agent out of the run time tool usage That only applies if you are talking about a well established recurrent workflow. That's not how MCPs are used to begin with.
      - themgt 5d ago
        It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.
        jimbokun 5d ago
        Heisenberg begs to differ with your view of reality.
        shwaj 5d ago
        So does Gödel. Maybe it was a joke? Unclear.
    - jimbokun 5d ago
  - Sayrus 5d ago
    Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something. Sharing Slack with Claude: - Using the "normal" way, it shares too much, including privates messages. - Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more. - Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.
  - lanstin 5d ago
    Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.
  - jimbokun 5d ago
    Yes, having LLMs write deterministic programs is still an under used solution. Less token spend, lower latency, more predictable results compared to having the LLM perform the task directly every time.
- deadbabe 5d ago
  The simplified interactions are how it should have been designed in the first place.
  - yorwba 5d ago
    It's difficult to come up with the optimal workflow on the first try. So an API should typically start out flexible even at the expense of complexity, in order to enable experimentation, and then you can optimize to make the common case simple, once you know what the common case is.
    - jimbokun 5d ago
      Sure but that common case should go into the core APIs, not an MCP.
      - dominotw 5d ago
        agreed lots of ppl writing mcp as a lipstick on the pig.
        lazyasciiart 5d ago
        Yea my company is willing to pour money into an MCP but has concretely resisted attempts to improve or care about the API for years.
        rsolva 5d ago
        MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.
        cindyllm 5d ago
        [dead]
0x696C6961 6d ago
Even if your agent has internet access, why waste tokens having it re-discover and re-implement its own API client each time? It doesn't make any sense.
- marcelo-earth 5d ago
  This is my favorite position, the advantage of an MCP tends to lie more in token optimization.
  - deadbabe 5d ago
    On the contrary, you burn more tokens with MCP.
    - 0x696C6961 5d ago
      This is not true.
      - cowmix 5d ago
        I guess it depends on the implementations. When I use the Atlassian CLI vs their MCP server, I tend to see something like half the token burn with the CLI with more accurate results. That could be an Atlassian issue but that's the results I'm seeing.
        dnautics 5d ago
        yeah MCP contains a provision for some blocktext for instructions. If your MCP has walls of text in those instructions, it will burn more tokens that a terse MCP.
      - dnautics 5d ago
        How do you think the LLM becomes aware of which mcps are available? Vibes?
        5d ago
barrkel 6d ago
A CLI doing all this is still a better UI for the agent though.
- 0x696C6961 5d ago
  What does that even mean?
  - bdangubic 5d ago
    totally makes no sense. so weird after all this time people don’t “get” the value of MCPs, so weird
- viccis 5d ago
  What if the agent doesn't have a CLI?
  - barrkel 5d ago
    You hobble the expressiveness of the LLM and reduce its capability. Think of an agentic harness as like a kind of body for the LLM. It gives it primitive inputs (read_file, web_search or whatever) and primitive outputs (edit file, respond to user, etc). Give it a command line environment (in a locked down sandbox, with as few or as many tools as you prefer), and you've given it a toolbox. It can do a whole lot more, faster and more efficiently. It can compose tools together. It makes fewer transcription errors manually shifting data around. It can tame verbosity with good protections in the harness and access to grep, sed and awk. It's really up to you how useful you want your agent to be.
    - viccis 5d ago
      Yeah but you're still assuming it's running on someone's machine with a CLI to even use.
- pixlmint 5d ago
  What if I don't want my agent to have terminal access though? I get the feeling many people here simply never worked with smaller models, those will confuse cli args really quickly once context expands, and then you have no idea what damage they might do. With MCP's, they get just the access they actually need. Is the Principle of least privilege just not something we want to apply anymore?
maharshi365 5d ago
1. Control can be done via CLIs --> api key based access controls. We have been doing it forever. 2. I think this really only applies to Oauth based MCPs. Many server support api key based auth, stored as files --> security is still flawed imo. 3. This can be done via apis/clis too --> not something unique to MCP iimo 4. Same thing, not unique to MCP --> api servers can also be logged MCP doesn't inherently make this easier. its still requires engineering maintaincence.
- nortirn 5d ago
  Having a standard does make sense though, because it lets agent services handle external calls in a standard way. So, for example something like Anthropic's agent platform will proxy all MCP calls and hide the credentials so that you don't have to worry about the agent leaking secrets into code/logs/the internet. Of course you could build a similar layer to proxy traffic to various APIs, but it becomes easier to make the whole thing plug and play if everyone agrees on the shape of the API (MCP).
  - maharshi365 5d ago
    i think standards are good for low level things. APIs change, model behvaiors change, we basically are allowing an external service provider to control our agent prompts.
mikeocool 5d ago
All of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today). I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting. Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
- simonw 5d ago
  Hah, I made that same point last December: https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-only-year-of-mcp https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-... > For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that. I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
  - mikeocool 5d ago
    Yeah, from a design perspective MCP upsets me, because it’s a poorly designed standard and creating a good one could have been much easier. But you’re right, since clients don’t have a nicely sandboxed “make api request” tool, it’s basically the way to go for a lot of use cases.
    - rsalus 5d ago
      I think the new 07-28 spec is quite decent
  - agentdev001 5d ago
    "without first having to solve the problem of effectively sandboxing Bash" Hopefully this is easier as time goes on. Of course- also policy on the egress
  - 5d ago
prescriptivist 5d ago
Couldn't agree more. MCP is just Tool Use and the terminal agents all have embedded tool uses like WebSearch, Bash, Grep, etc and those are just MCP by another name. CLI's called by a model are just Bash Tool usage calls. Bash tool is just the most open ended broad MCP you can expose and what you gain is less context bloat (no specialized tool descriptions, just Bash) and what you lose is control over the agent -- until you setup a rigorous set of governing permissions on the Bash Tool. I have a fleet of sandboxed Claude Code instances running and they share files with each other. The files are stored on AWS but they don't have access to AWS at all -- they can't see the access keys. In fact they don't know the files are on AWS. Instead they have a set of MCP tools for listing/uploading/downloading from an internal, virtual filesystem with a special URI handler (ie agentfiles://somefile.json) and the outer orchestrator of the Claude Code instances takes the MCP requests and does the actual file manipulation on Claude's behalf. The LLM seems to adapt quite well to this strange, arbitrary filesystem and I get to keep these agents fully compartmentalized. And I have tool request logs and logs in the outer orchestrator for full auditing of the agents. MCP is a really natural fit for this kind of stuff.
- zahlman 5d ago
  > what you gain is less context bloat (no specialized tool descriptions, just Bash) Couldn't they train the understanding of a specific tool set directly into the model instead of needing it to be in context? Like isn't that basically what happens now with the Bash tool? Is there a reason we need to rely on such a high level of access for something that should really only ever be cleaning up the project directory, hitting the 'Run Test' button and authoring some Git commits?
  - blitzar 5d ago
    Perhaps a little out of date now, but I found claude was better (trained?) with the gh command line than with the github mcp. For a $corp internal tool ... I don't really see how and LLM would be able to be trained on it.
- kaoD 5d ago
  > MCP is just Tool Use I wish. https://modelcontextprotocol.io/specification/2026-07-28 https://modelcontextprotocol.io/specification/2026-07-28
viccis 5d ago
Exactly. A lot of people complaining about MCP are doing so because their only interactions with LLMs are via big batteries including code harnesses and don't understand what kind of (usually much more domain-specific) agentic systems are being built. For example, "CLI vs MCP" doesn't make any sense whatsoever if the agent doesn't have access to a CLI! MCP suffers from its harebrained choice early on to load everything into context up front.
- dnautics 5d ago
  The other problem with MCPs is that the harnesses don't auto-reconnect if you've enabled access. Connection status should be persistent
- williamse 5d ago
  [flagged]
locknitpicker 5d ago
> 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. I don't think this is a valid statement too. I'll explain why. A MCP server represents those APIs that agents and coding assistants can call. If you feel a need to provide data and services to agents through an API and feel so strongly about it and so compelled to implement your own APIs with the express purpose of being consumed by your agents, wouldn't it make sense to develop an API that is designed purposely for agents using a protocol designed to meet their needs and simplify their work? Because that's what MCP is all about. Nowadays, with the improvements in tool-calling and the dissemination of agent skills, MCP's value proposition isn't as clear as back when those weren't a given. But once you face usecases to either centralize your tools across an organization, manage access, and be able to audit it's usage, right now there is no alternative to MCP.
- jimbokun 5d ago
  Agents are perfectly capable of using the same APIs designed for humans.
jrm4 5d ago
Real hard to not think- "This is a job for a CLI/terminal, which is absolutely a million times easier to learn today, thanks to AI." Feels like MCP is still a product of -- well, "AI as a product" brain, which I have no love or use for. Give EVERYONE ALL the tools.
- crooked-v 5d ago
  So how do you make that CLI tool work in the context of a web client?
seanhunter 5d ago
Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.” Well yes.
- mikeocool 5d ago
  I think the point of those comments is this could have been much simpler for everyone if the model providers had given us some tools around existing standards. Instead they invented something new/weird/complex standard, and then every client implemented slightly differently (and different parts of it).
- lelanthran 5d ago
  > Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.” See my previous reply to simonw elsethread. It's not "If you just do <all the things mcp does a different way> you don’t need mcp at all", it's that many of us were already doing that in a CLI prior to LLMs. You think only github and amazon had CLI clients?
jwr 5d ago
> there's almost no reason to use MCPs if you are running a full-blown terminal agent I disagree. Adding "https://mcp.linear.app/mcp https://mcp.linear.app/mcp" and having everything happen (discovery, usage, updates to the API, etc) without having to install or configure anything else locally is a big deal.
- shibel 5d ago
  Funny you mention Linear’s specifically, I just posted about moving to a CLI instead because of the MCP’s egregious token-usage [1]. While this doesn’t discount the points you mentioned, I think the context savings (which can be huge, I hadn’t listed all differences in that post) outweigh them specifically in Linear’s case. It is just too inefficient in that regard. Edit: this of course says nothing about MCP vs API/CLI in general. It’s just a bad implementation by Linear. 1: https://thebiglog.com/links/linear-cli-instead-of-linear-mcp https://thebiglog.com/links/linear-cli-instead-of-linear-mcp
  - w0m 5d ago
    This surprises me a bit. I've found much better token usage with a proper/efficient MCP as even with a deep /skill defining usage, parsing MCP results is generally just better/more efficient than parsing CLI results. I say this having written a CLI tool explicitly for harness usage, and leveraging MCPs for the same. I'm sure there are bad MCPs and great CLI tools that parse poorly/well via harness, but I'd be curious on an better research study.
    - shibel 5d ago
      Your comment doesn’t contradict mine and mine doesn’t contradict yours. Linear’s MCP is just (very?) inefficient. I explain the source of the difference in the last two paragraphs.
    - estetlinus 5d ago
      How much are using Linear if token usage is a problem? Sounds like a case of straining at a gnat and swallowing a camel.
baalimago 5d ago
In essence: MPC servers are the sandbox
- jimbokun 5d ago
  True but a pretty shitty sandbox and we need a less leaky and more general sandbox solution ASAP.
  - baalimago 5d ago
    >pretty shitty sandbox Well, speak for yourself. My MCP servers are pretty solid. There's nothing in the protocol making them inherently poor other than perhaps popularity, causing a swarm of people vibe-coding things they don't understand.
socketcluster 5d ago
MCP definitely has its niche in certain environments. It's good for a specific kind of constrained problem; not so constrained that you could solve the problem with just Node.js + fetch call to LLM API but not so open that you'd want to let the AI agent directly invoke any service it wants over the web. The latter is what happens if you give the agent access to curl. Though I agree with OP's point of view that MCP was overhyped for too many use cases. Complex agent-system integration problems are usually better solved with just AI agent + curl + SKILL.md. It's just way more flexible. It's another variant of the 'fat client/thin server vs thin client/fat server' debate. Some people want rigid, thin (e.g. web-based) frontends with the LLM doing work in secret behind the scenes. Others want fat, versatile frontends through which the LLM can interact with the user's own environment. I've always been a fat client guy and this time is no exception. I doubt the constrained approach is going to lead ground-breaking innovation. I also wish companies would treat SKILL.md + curl as the main mechanism for agent tool calling as opposed to MCP. MCP is niche.
- anon84873628 5d ago
  That niche environment is all SaaS-to-SaaS integrations. The client doesn't want to have users struggling to get every integration working on their platform. The service providers don't want to have to support non-standarized behavior by every client.
lelanthran 5d ago
> This article entirely misses the value that MCP brings today. Well, me too. I see the only advantage over a CLI app being an agreed-upon convention for syntax (not semantics). I have a CLI interface to my webapp, not an MCP. > 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 Access control is not built into my CLI, it's built into the WebApp. > 2. A way to handle authentication that doesn't allow the agent to directly access API keys My CLI takes credentials from the environment, which it uses to talk to endpoints. The caller sets the environment, then calls the CLI program. The caller provides no way for anyone sending it input (the Model) to request or retrieve environment variables. > 3. A sensible UI to allow users to connect and authenticate further services The parts of my WebApp that relays or re-requests to other third-party services handles access control. > 4. Strong audit logging for what's going on Not sure what this is supposed to mean: the WebApp already has auditing logs. > MCP makes all of that so much easier to provide. Sure; I'm considering writing a purely deterministic shim for MCP around my CLI. The semantic/information is the same, the only difference is syntactical in nature. > 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. It may as well be; coding agents are at one end of the control spectrum - run in bash, do anything/everything (so they can leak credentials to the model, or the harness). But a CLI app doesn't have to allow bash. My "harness" (using the term very loosely) can securely call other programs without giving its own caller a RCE via bash.
- simonw 5d ago
  So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself? Sounds to me like MCP with a slightly different interface.
  - lelanthran 5d ago
    > So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself? Yes, with the difference being it can call other CLIs, just not arbitrary CLIs. > Sounds to me like MCP with a slightly different interface. It is, except that it is not limited to being called from harnesses. Also usable from bash (automated scripts), or even humans if hey want to run it on the command-line. TBH, my webapp(s) had this prior to 2020, because it made automation simpler so I could write shell scripts to do various things on the WebApp.
podocarp 5d ago
Still don't get what's the advantage over just adding a special API key or a wrapper cli or whatever mechanism that achieves all of that without being a "protocol" and with all the context bloat. Like the github cli is a good example. You give it proper auth keys etc. and for sure there's some telemetry in there about usage as well. If there isn't then it's easy to do from the api side too. Even if you don't own the code or infra, like say a frontend team who wants models to test out the backend apis and do something. Well in that case how do regular devs do it? Do they also get unfettered access in the past? Surely there's still some mechanism you can repurpose for agents to use? I'm not trying to argue I'm just saying I didn't catch on the first time mcp was a thing and I still don't know what it's doing now.
- simonw 5d ago
  If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool. They can go as far as decompiling binaries, or rewriting them to log the key before it is used. If you are worried about a prompt injected agent stealing your keys, that's a problem. (There is a way around that: you can use an HTTP proxy that inserts those credentials but otherwise lives outside of the agent's realm of influence. MCP is a whole lot easier though.)
  - lelanthran 5d ago
    > If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool. So, don't do that then? Why do you need to use a full coding agent as the interface between the model and the CLI tool? A 10-line program can do the wrapping of any existing CLI program so that environment is not leaked to the model, while providing the CLI program with the environment as well as restricting what programs can be called to a whitelist. If you CLI program is echoing its keys in the response, or the endpoint is echoing keys back, that's not a problem that can be solved with MCP anyway.
    - simonw 5d ago
      So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request? One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls. (That performance overhead is so trivial as to not be worth caring about, but the state thing may be useful - keeping a stateful browser session running between tool calls is harder with a CLI, for example.)
pragma_x 5d ago
As someone who has never used MCP, or allowed an AI to directly talk to APIs, putting something between a model and a service just seems like common sense. If nothing else, it presents an opportunity to tightly control what the AI is allowed to do with external services, especially if the MCP code is outside of the AI's context. I would go as far as to say it's a necessary security measure.
- dominotw 5d ago
  well if you realease an api you should make sure its usable for ai out of box without 'something in between'. You should always assume ai might be directly calling your api.
  - anamexis 5d ago
    And if you don't have a public API, you should always assume AI will be using your UI, reverse engineering your private API, and driving it directly.
    - cruffle_duffle 5d ago
      I absolutely love when they do that unprompted. I once asked a Claude work agent to go pull comparable apartment listings and somehow it’s subagent reverse engineered like rentcafe or whatever’s private API to get the data. All unprompted. So yes. Absolutely assume AI agents acting on behalf of their humans are finding all the token efficient ways to get at your sites data.
  - Tractor8626 5d ago
    Ai can't use any api out of box. It requires thing called "harness" to use anything.
- jimbokun 5d ago
  The service itself needs to control what the agent can access. Relying on an intermediary to provide access controls, and that agents will never access the service directly, seems dangerous and naive.
adverbly 5d ago
> MCP makes all of that so much easier to provide. Easier being the key! Right now it really does feel like early web days where like 5% of the population is adopting things, but most people just get confused and don't participate. This is why I'm pretty excited about WebMCP in particular! WebMCP aligns more stakeholders than pure MCP - which seems heavily biased towards model providers. It also seems like it has the potential for a much cleaner ux.
jimbokun 5d ago
I feel like this would build a false sense of security. Authentication and access controls must be able to withstand an agent with full shell access. And auditing must be on the server side to provide a full picture of all activity from all clients, whether human or agent. We must treat agents as clever humans and secure and audit data access accordingly. The era of thinking we can handle agent access to sensitive information differently from human access has passed.
- simonw 5d ago
  My point about MCPs here is that they provide a way to make those secrets and API keys deterministically inaccessible to the agents - even agents that's have a shell execution environment. That's the opposite of a false sense of security.
  - mjburgess 5d ago
    just use an api gateway (ie., a reverse proxy for apis), eg., envoy. This should also be connected to observability and finops style management anyway rather than leaving it to model providers.
- brabel 5d ago
  Without tools LLMs can do nothing more than emit text. You are probably assuming a harness is provided to the LLM with shell access but that is absolutely not necessary for LLM usage depending on the use case. For interesting stuff, you do want to provide some tools, but nothing with the power of a terminal if you are worried about security. A MCP server is perfect to securely provide the LLM with some controlled power exactly because it can do nothing at all other than call tools that go through the MCP server and can therefore be scrutinized, audited and ensure credentials are not visible to the LLM.
cbeach 5d ago
Also MCP allows exposition, which helps an autonomous agent understand the semantics of the API. That's the killer feature from my PoV. I just point my agent at a URL and suddenly it knows when, why and how to use it.
- jimbokun 5d ago
  Congratulations you reinvented man pages!
anon84873628 5d ago
The article also doesn't contemplate the "skill distribution problem" which will be addressed by skills-over-mcp. With the plain ol' API solution, you still need some way for agents to fetch the instructions provided by the service. Of course there are answers for this, but they are not standardized. With MCP, all you have to do is provide the harness with a single URL and all context can be bootstrapped the same way for every service.
miguelspizza 5d ago
The article misses the point of MCP but he is not wrong that it was a mistake (in some ways) The mistake of MCP was building it in such a way that it needed to be on a separate process from the API. The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years. Now that MCP is stateless we can start building what is actually useful: extending API’s for agents. When people ask me if they should do MCP today, I say absolutely. But because the Oauth protocol side of MCP is very good and is a net positive for all public API’s This is not a dig at MCP, the original vision of MCP was much different from how the community used it.
- cruffle_duffle 5d ago
  > The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years. I remember discovering this when i wrote my first MCP server. It was like "huh? why would they do that? what use case did they have in mind?". We've spent decades making "internet shit" as stateless as possible on the backend because making it stateful is expensive and complex if you want to have any reasonable scalability. I mean good luck trying to host a stateful service on any kind of commodity serverless "scale-to-zero" infrastructure here in 2026. Maybe it's because these AI-labs are used to statefulness. I mean LLM-based sessions are hugely stateful if you want any kind of reasonable caching to happen and caching is the only way you can economically scale out LLM's. Seen from that perspective it kind of makes sense why they'd look at MCP and think "hey, why not make this stateful on the backend as well". Statefullness just part of their DNA.
kaoD 5d ago
All of that can be solved in better ways than MCP. 1+2+4 belongs to sandboxing. 3 to sandbox UIs. Ideally baked into the next generation OSs. MCP is the wrong abstraction for all of that. Skills are better as pluggable interfaces, and I predict[0] chat and agentic loops will converge eventually (Anthropic already did this correctly; OpenAI, it's your turn) and skills marketplace will replace MCP in its current form. I see value in MCP, but it feels like a stopgap/stepping stone. [0] Where "predict" = "hope". The best solutions are often not the winners.
- tacoooooooo 5d ago
  Skills are adjacent to MCP. They do not cover the same surface, in anyway. I don't understand this argument at all (and I see lots of people making it, so enlighten me) I want my agent to be able to convert reliably between timezones. A skill does not solve this. It needs a deterministic tool it can call
  - kaoD 5d ago
    Skills are not only Markdown files. I often structure my skills as small Python scripts and the actual Markdown is only the skill front matter and maybe some brief documentation. You can even stick an OpenAPI schema or whatever you see fit. If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed. It's just files, all the way down. If you find yourself operating with dates a lot maybe you need a `datetime` skill wrapping a bunch of tiny scripts. Fully deterministic, cheap on tokens, and you can even run them without an agent (shocking nowadays :P) As I identify repetitive actions I add (Claude adds) new scripts to the Skill to save tokens in the future, whereas MCP I'm at the mercy of the server provider. E.g. I have a Magic the Gathering skill with a bunch of tools to retrieve card databases, simulate hands, get card images... This article enlightened me: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/ https://mariozechner.at/posts/2025-11-02-what-if-you-dont-ne... This is why I don't feel Skills are orthogonal. They feel like MCP on steroids since the scripts can be composed with Bash et al (huge battle-tested ecosystem, plenty in the training set)... and you don't need crappy abstractions like "resources" (yes, that's a thing in MCP) when the agent has a shell and a filesystem. I've used this pattern to great success. Nowadays I just share these `.skill` packages with my friends (I think they're just a fancy ZIP file?) The only thing missing for me is credentials and sandboxing (see my GP post). I have my own ideas on how to solve this (and some of that Claude in cloud already solves for me), but it's not easy (which is how MCP won).
ramoz 5d ago
Even for coding agents. MCP is the only unified interface INTO harnesses. This pattern has not struck yet for most, but will soon in the coming months given the MCP spec. MCP has been about models calling tools., it is about to become some form of inverse and MCP will be the only actual way to integrate into the models. Simple example is sending an event to the model (today models have to poll)... these coming updates will cement MCP as permanent infrastructure.
visarga 5d ago
What matters is local server or not. Using a remote server means exposure.
paper2d 5d ago
Agree. MCP also helps in some esoteric use cases like interacting with legacy windows applications over COM. I created an MCP for Outlook 2019 desktop version and COM was the most straightforward way to let my agent interact with my mails for classification.

by simonw 6d ago

maharshi365 6d ago

Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans

rsolva 6d 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 6d 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 6d 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.
- 0x696C6961 5d ago
  Yeah that's a good idea. Then we should standardize these tools and find an easy way for agents to discover and use them. ... Oh wait
  - mjmas 5d ago
    And call it not-closed API or something like that.
  - 0x445442 5d ago
    Just tell the clanker to read the api documentation that should already exist. You dont need an MCP server for that.
  - jimbokun 5d ago
    Congrats you just invented the Unix shell!
- locknitpicker 5d ago
  > 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. The MCP is the deterministic program. You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface. It's the interface for your deterministic program. That's it.
  - 8note 5d ago
    they were suggesting that you take the agent out of the run time tool usage
    - locknitpicker 5d ago
      > they were suggesting that you take the agent out of the run time tool usage That only applies if you are talking about a well established recurrent workflow. That's not how MCPs are used to begin with.
    - themgt 5d ago
      It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.
      - jimbokun 5d ago
        Heisenberg begs to differ with your view of reality.
        shwaj 5d ago
        So does Gödel. Maybe it was a joke? Unclear.
  - jimbokun 5d ago
- Sayrus 5d ago
  Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something. Sharing Slack with Claude: - Using the "normal" way, it shares too much, including privates messages. - Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more. - Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.
- lanstin 5d ago
  Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.
- jimbokun 5d ago
  Yes, having LLMs write deterministic programs is still an under used solution. Less token spend, lower latency, more predictable results compared to having the LLM perform the task directly every time.
deadbabe 5d ago
The simplified interactions are how it should have been designed in the first place.
- yorwba 5d ago
  It's difficult to come up with the optimal workflow on the first try. So an API should typically start out flexible even at the expense of complexity, in order to enable experimentation, and then you can optimize to make the common case simple, once you know what the common case is.
  - jimbokun 5d ago
    Sure but that common case should go into the core APIs, not an MCP.
    - dominotw 5d ago
      agreed lots of ppl writing mcp as a lipstick on the pig.
      - lazyasciiart 5d ago
        Yea my company is willing to pour money into an MCP but has concretely resisted attempts to improve or care about the API for years.
      - rsolva 5d ago
        MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.
        cindyllm 5d ago
        [dead]

0x696C6961 6d ago

Even if your agent has internet access, why waste tokens having it re-discover and re-implement its own API client each time? It doesn't make any sense.

marcelo-earth 5d ago
This is my favorite position, the advantage of an MCP tends to lie more in token optimization.
- deadbabe 5d ago
  On the contrary, you burn more tokens with MCP.
  - 0x696C6961 5d ago
    This is not true.
    - cowmix 5d ago
      I guess it depends on the implementations. When I use the Atlassian CLI vs their MCP server, I tend to see something like half the token burn with the CLI with more accurate results. That could be an Atlassian issue but that's the results I'm seeing.
      - dnautics 5d ago
        yeah MCP contains a provision for some blocktext for instructions. If your MCP has walls of text in those instructions, it will burn more tokens that a terse MCP.
    - dnautics 5d ago
      How do you think the LLM becomes aware of which mcps are available? Vibes?
      - 5d ago

barrkel 6d ago

A CLI doing all this is still a better UI for the agent though.

0x696C6961 5d ago
What does that even mean?
- bdangubic 5d ago
  totally makes no sense. so weird after all this time people don’t “get” the value of MCPs, so weird
viccis 5d ago
What if the agent doesn't have a CLI?
- barrkel 5d ago
  You hobble the expressiveness of the LLM and reduce its capability. Think of an agentic harness as like a kind of body for the LLM. It gives it primitive inputs (read_file, web_search or whatever) and primitive outputs (edit file, respond to user, etc). Give it a command line environment (in a locked down sandbox, with as few or as many tools as you prefer), and you've given it a toolbox. It can do a whole lot more, faster and more efficiently. It can compose tools together. It makes fewer transcription errors manually shifting data around. It can tame verbosity with good protections in the harness and access to grep, sed and awk. It's really up to you how useful you want your agent to be.
  - viccis 5d ago
    Yeah but you're still assuming it's running on someone's machine with a CLI to even use.
pixlmint 5d ago
What if I don't want my agent to have terminal access though? I get the feeling many people here simply never worked with smaller models, those will confuse cli args really quickly once context expands, and then you have no idea what damage they might do. With MCP's, they get just the access they actually need. Is the Principle of least privilege just not something we want to apply anymore?

maharshi365 5d ago

1. Control can be done via CLIs --> api key based access controls. We have been doing it forever. 2. I think this really only applies to Oauth based MCPs. Many server support api key based auth, stored as files --> security is still flawed imo. 3. This can be done via apis/clis too --> not something unique to MCP iimo 4. Same thing, not unique to MCP --> api servers can also be logged MCP doesn't inherently make this easier. its still requires engineering maintaincence.

nortirn 5d ago
Having a standard does make sense though, because it lets agent services handle external calls in a standard way. So, for example something like Anthropic's agent platform will proxy all MCP calls and hide the credentials so that you don't have to worry about the agent leaking secrets into code/logs/the internet. Of course you could build a similar layer to proxy traffic to various APIs, but it becomes easier to make the whole thing plug and play if everyone agrees on the shape of the API (MCP).
- maharshi365 5d ago
  i think standards are good for low level things. APIs change, model behvaiors change, we basically are allowing an external service provider to control our agent prompts.

mikeocool 5d ago

All of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today). I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting. Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.

simonw 5d ago
Hah, I made that same point last December: https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-only-year-of-mcp https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-... > For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that. I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
- mikeocool 5d ago
  Yeah, from a design perspective MCP upsets me, because it’s a poorly designed standard and creating a good one could have been much easier. But you’re right, since clients don’t have a nicely sandboxed “make api request” tool, it’s basically the way to go for a lot of use cases.
  - rsalus 5d ago
    I think the new 07-28 spec is quite decent
- agentdev001 5d ago
  "without first having to solve the problem of effectively sandboxing Bash" Hopefully this is easier as time goes on. Of course- also policy on the egress
- 5d ago

prescriptivist 5d ago

Couldn't agree more. MCP is just Tool Use and the terminal agents all have embedded tool uses like WebSearch, Bash, Grep, etc and those are just MCP by another name. CLI's called by a model are just Bash Tool usage calls. Bash tool is just the most open ended broad MCP you can expose and what you gain is less context bloat (no specialized tool descriptions, just Bash) and what you lose is control over the agent -- until you setup a rigorous set of governing permissions on the Bash Tool. I have a fleet of sandboxed Claude Code instances running and they share files with each other. The files are stored on AWS but they don't have access to AWS at all -- they can't see the access keys. In fact they don't know the files are on AWS. Instead they have a set of MCP tools for listing/uploading/downloading from an internal, virtual filesystem with a special URI handler (ie agentfiles://somefile.json) and the outer orchestrator of the Claude Code instances takes the MCP requests and does the actual file manipulation on Claude's behalf. The LLM seems to adapt quite well to this strange, arbitrary filesystem and I get to keep these agents fully compartmentalized. And I have tool request logs and logs in the outer orchestrator for full auditing of the agents. MCP is a really natural fit for this kind of stuff.

zahlman 5d ago
> what you gain is less context bloat (no specialized tool descriptions, just Bash) Couldn't they train the understanding of a specific tool set directly into the model instead of needing it to be in context? Like isn't that basically what happens now with the Bash tool? Is there a reason we need to rely on such a high level of access for something that should really only ever be cleaning up the project directory, hitting the 'Run Test' button and authoring some Git commits?
- blitzar 5d ago
  Perhaps a little out of date now, but I found claude was better (trained?) with the gh command line than with the github mcp. For a $corp internal tool ... I don't really see how and LLM would be able to be trained on it.
kaoD 5d ago
> MCP is just Tool Use I wish. https://modelcontextprotocol.io/specification/2026-07-28 https://modelcontextprotocol.io/specification/2026-07-28

viccis 5d ago

Exactly. A lot of people complaining about MCP are doing so because their only interactions with LLMs are via big batteries including code harnesses and don't understand what kind of (usually much more domain-specific) agentic systems are being built. For example, "CLI vs MCP" doesn't make any sense whatsoever if the agent doesn't have access to a CLI! MCP suffers from its harebrained choice early on to load everything into context up front.

dnautics 5d ago
The other problem with MCPs is that the harnesses don't auto-reconnect if you've enabled access. Connection status should be persistent
williamse 5d ago
[flagged]

locknitpicker 5d ago

> 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. I don't think this is a valid statement too. I'll explain why. A MCP server represents those APIs that agents and coding assistants can call. If you feel a need to provide data and services to agents through an API and feel so strongly about it and so compelled to implement your own APIs with the express purpose of being consumed by your agents, wouldn't it make sense to develop an API that is designed purposely for agents using a protocol designed to meet their needs and simplify their work? Because that's what MCP is all about. Nowadays, with the improvements in tool-calling and the dissemination of agent skills, MCP's value proposition isn't as clear as back when those weren't a given. But once you face usecases to either centralize your tools across an organization, manage access, and be able to audit it's usage, right now there is no alternative to MCP.

jimbokun 5d ago
Agents are perfectly capable of using the same APIs designed for humans.

jrm4 5d ago

Real hard to not think- "This is a job for a CLI/terminal, which is absolutely a million times easier to learn today, thanks to AI." Feels like MCP is still a product of -- well, "AI as a product" brain, which I have no love or use for. Give EVERYONE ALL the tools.

crooked-v 5d ago
So how do you make that CLI tool work in the context of a web client?

seanhunter 5d ago

Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.” Well yes.

mikeocool 5d ago
I think the point of those comments is this could have been much simpler for everyone if the model providers had given us some tools around existing standards. Instead they invented something new/weird/complex standard, and then every client implemented slightly differently (and different parts of it).
lelanthran 5d ago
> Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.” See my previous reply to simonw elsethread. It's not "If you just do <all the things mcp does a different way> you don’t need mcp at all", it's that many of us were already doing that in a CLI prior to LLMs. You think only github and amazon had CLI clients?

jwr 5d ago

> there's almost no reason to use MCPs if you are running a full-blown terminal agent I disagree. Adding "https://mcp.linear.app/mcp https://mcp.linear.app/mcp" and having everything happen (discovery, usage, updates to the API, etc) without having to install or configure anything else locally is a big deal.

shibel 5d ago
Funny you mention Linear’s specifically, I just posted about moving to a CLI instead because of the MCP’s egregious token-usage [1]. While this doesn’t discount the points you mentioned, I think the context savings (which can be huge, I hadn’t listed all differences in that post) outweigh them specifically in Linear’s case. It is just too inefficient in that regard. Edit: this of course says nothing about MCP vs API/CLI in general. It’s just a bad implementation by Linear. 1: https://thebiglog.com/links/linear-cli-instead-of-linear-mcp https://thebiglog.com/links/linear-cli-instead-of-linear-mcp
- w0m 5d ago
  This surprises me a bit. I've found much better token usage with a proper/efficient MCP as even with a deep /skill defining usage, parsing MCP results is generally just better/more efficient than parsing CLI results. I say this having written a CLI tool explicitly for harness usage, and leveraging MCPs for the same. I'm sure there are bad MCPs and great CLI tools that parse poorly/well via harness, but I'd be curious on an better research study.
  - shibel 5d ago
    Your comment doesn’t contradict mine and mine doesn’t contradict yours. Linear’s MCP is just (very?) inefficient. I explain the source of the difference in the last two paragraphs.
  - estetlinus 5d ago
    How much are using Linear if token usage is a problem? Sounds like a case of straining at a gnat and swallowing a camel.

baalimago 5d ago

In essence: MPC servers are the sandbox

jimbokun 5d ago
True but a pretty shitty sandbox and we need a less leaky and more general sandbox solution ASAP.
- baalimago 5d ago
  >pretty shitty sandbox Well, speak for yourself. My MCP servers are pretty solid. There's nothing in the protocol making them inherently poor other than perhaps popularity, causing a swarm of people vibe-coding things they don't understand.

socketcluster 5d ago

MCP definitely has its niche in certain environments. It's good for a specific kind of constrained problem; not so constrained that you could solve the problem with just Node.js + fetch call to LLM API but not so open that you'd want to let the AI agent directly invoke any service it wants over the web. The latter is what happens if you give the agent access to curl. Though I agree with OP's point of view that MCP was overhyped for too many use cases. Complex agent-system integration problems are usually better solved with just AI agent + curl + SKILL.md. It's just way more flexible. It's another variant of the 'fat client/thin server vs thin client/fat server' debate. Some people want rigid, thin (e.g. web-based) frontends with the LLM doing work in secret behind the scenes. Others want fat, versatile frontends through which the LLM can interact with the user's own environment. I've always been a fat client guy and this time is no exception. I doubt the constrained approach is going to lead ground-breaking innovation. I also wish companies would treat SKILL.md + curl as the main mechanism for agent tool calling as opposed to MCP. MCP is niche.

anon84873628 5d ago
That niche environment is all SaaS-to-SaaS integrations. The client doesn't want to have users struggling to get every integration working on their platform. The service providers don't want to have to support non-standarized behavior by every client.

lelanthran 5d ago

> This article entirely misses the value that MCP brings today. Well, me too. I see the only advantage over a CLI app being an agreed-upon convention for syntax (not semantics). I have a CLI interface to my webapp, not an MCP. > 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 Access control is not built into my CLI, it's built into the WebApp. > 2. A way to handle authentication that doesn't allow the agent to directly access API keys My CLI takes credentials from the environment, which it uses to talk to endpoints. The caller sets the environment, then calls the CLI program. The caller provides no way for anyone sending it input (the Model) to request or retrieve environment variables. > 3. A sensible UI to allow users to connect and authenticate further services The parts of my WebApp that relays or re-requests to other third-party services handles access control. > 4. Strong audit logging for what's going on Not sure what this is supposed to mean: the WebApp already has auditing logs. > MCP makes all of that so much easier to provide. Sure; I'm considering writing a purely deterministic shim for MCP around my CLI. The semantic/information is the same, the only difference is syntactical in nature. > 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. It may as well be; coding agents are at one end of the control spectrum - run in bash, do anything/everything (so they can leak credentials to the model, or the harness). But a CLI app doesn't have to allow bash. My "harness" (using the term very loosely) can securely call other programs without giving its own caller a RCE via bash.

simonw 5d ago
So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself? Sounds to me like MCP with a slightly different interface.
- lelanthran 5d ago
  > So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself? Yes, with the difference being it can call other CLIs, just not arbitrary CLIs. > Sounds to me like MCP with a slightly different interface. It is, except that it is not limited to being called from harnesses. Also usable from bash (automated scripts), or even humans if hey want to run it on the command-line. TBH, my webapp(s) had this prior to 2020, because it made automation simpler so I could write shell scripts to do various things on the WebApp.

podocarp 5d ago

Still don't get what's the advantage over just adding a special API key or a wrapper cli or whatever mechanism that achieves all of that without being a "protocol" and with all the context bloat. Like the github cli is a good example. You give it proper auth keys etc. and for sure there's some telemetry in there about usage as well. If there isn't then it's easy to do from the api side too. Even if you don't own the code or infra, like say a frontend team who wants models to test out the backend apis and do something. Well in that case how do regular devs do it? Do they also get unfettered access in the past? Surely there's still some mechanism you can repurpose for agents to use? I'm not trying to argue I'm just saying I didn't catch on the first time mcp was a thing and I still don't know what it's doing now.

simonw 5d ago
If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool. They can go as far as decompiling binaries, or rewriting them to log the key before it is used. If you are worried about a prompt injected agent stealing your keys, that's a problem. (There is a way around that: you can use an HTTP proxy that inserts those credentials but otherwise lives outside of the agent's realm of influence. MCP is a whole lot easier though.)
- lelanthran 5d ago
  > If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool. So, don't do that then? Why do you need to use a full coding agent as the interface between the model and the CLI tool? A 10-line program can do the wrapping of any existing CLI program so that environment is not leaked to the model, while providing the CLI program with the environment as well as restricting what programs can be called to a whitelist. If you CLI program is echoing its keys in the response, or the endpoint is echoing keys back, that's not a problem that can be solved with MCP anyway.
  - simonw 5d ago
    So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request? One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls. (That performance overhead is so trivial as to not be worth caring about, but the state thing may be useful - keeping a stateful browser session running between tool calls is harder with a CLI, for example.)

pragma_x 5d ago

As someone who has never used MCP, or allowed an AI to directly talk to APIs, putting something between a model and a service just seems like common sense. If nothing else, it presents an opportunity to tightly control what the AI is allowed to do with external services, especially if the MCP code is outside of the AI's context. I would go as far as to say it's a necessary security measure.

dominotw 5d ago
well if you realease an api you should make sure its usable for ai out of box without 'something in between'. You should always assume ai might be directly calling your api.
- anamexis 5d ago
  And if you don't have a public API, you should always assume AI will be using your UI, reverse engineering your private API, and driving it directly.
  - cruffle_duffle 5d ago
    I absolutely love when they do that unprompted. I once asked a Claude work agent to go pull comparable apartment listings and somehow it’s subagent reverse engineered like rentcafe or whatever’s private API to get the data. All unprompted. So yes. Absolutely assume AI agents acting on behalf of their humans are finding all the token efficient ways to get at your sites data.
- Tractor8626 5d ago
  Ai can't use any api out of box. It requires thing called "harness" to use anything.
jimbokun 5d ago
The service itself needs to control what the agent can access. Relying on an intermediary to provide access controls, and that agents will never access the service directly, seems dangerous and naive.

adverbly 5d ago

> MCP makes all of that so much easier to provide. Easier being the key! Right now it really does feel like early web days where like 5% of the population is adopting things, but most people just get confused and don't participate. This is why I'm pretty excited about WebMCP in particular! WebMCP aligns more stakeholders than pure MCP - which seems heavily biased towards model providers. It also seems like it has the potential for a much cleaner ux.

jimbokun 5d ago

I feel like this would build a false sense of security. Authentication and access controls must be able to withstand an agent with full shell access. And auditing must be on the server side to provide a full picture of all activity from all clients, whether human or agent. We must treat agents as clever humans and secure and audit data access accordingly. The era of thinking we can handle agent access to sensitive information differently from human access has passed.

simonw 5d ago
My point about MCPs here is that they provide a way to make those secrets and API keys deterministically inaccessible to the agents - even agents that's have a shell execution environment. That's the opposite of a false sense of security.
- mjburgess 5d ago
  just use an api gateway (ie., a reverse proxy for apis), eg., envoy. This should also be connected to observability and finops style management anyway rather than leaving it to model providers.
brabel 5d ago
Without tools LLMs can do nothing more than emit text. You are probably assuming a harness is provided to the LLM with shell access but that is absolutely not necessary for LLM usage depending on the use case. For interesting stuff, you do want to provide some tools, but nothing with the power of a terminal if you are worried about security. A MCP server is perfect to securely provide the LLM with some controlled power exactly because it can do nothing at all other than call tools that go through the MCP server and can therefore be scrutinized, audited and ensure credentials are not visible to the LLM.

cbeach 5d ago

Also MCP allows exposition, which helps an autonomous agent understand the semantics of the API. That's the killer feature from my PoV. I just point my agent at a URL and suddenly it knows when, why and how to use it.

jimbokun 5d ago
Congratulations you reinvented man pages!

anon84873628 5d ago

The article also doesn't contemplate the "skill distribution problem" which will be addressed by skills-over-mcp. With the plain ol' API solution, you still need some way for agents to fetch the instructions provided by the service. Of course there are answers for this, but they are not standardized. With MCP, all you have to do is provide the harness with a single URL and all context can be bootstrapped the same way for every service.

miguelspizza 5d ago

The article misses the point of MCP but he is not wrong that it was a mistake (in some ways) The mistake of MCP was building it in such a way that it needed to be on a separate process from the API. The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years. Now that MCP is stateless we can start building what is actually useful: extending API’s for agents. When people ask me if they should do MCP today, I say absolutely. But because the Oauth protocol side of MCP is very good and is a net positive for all public API’s This is not a dig at MCP, the original vision of MCP was much different from how the community used it.

cruffle_duffle 5d ago
> The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years. I remember discovering this when i wrote my first MCP server. It was like "huh? why would they do that? what use case did they have in mind?". We've spent decades making "internet shit" as stateless as possible on the backend because making it stateful is expensive and complex if you want to have any reasonable scalability. I mean good luck trying to host a stateful service on any kind of commodity serverless "scale-to-zero" infrastructure here in 2026. Maybe it's because these AI-labs are used to statefulness. I mean LLM-based sessions are hugely stateful if you want any kind of reasonable caching to happen and caching is the only way you can economically scale out LLM's. Seen from that perspective it kind of makes sense why they'd look at MCP and think "hey, why not make this stateful on the backend as well". Statefullness just part of their DNA.

kaoD 5d ago

All of that can be solved in better ways than MCP. 1+2+4 belongs to sandboxing. 3 to sandbox UIs. Ideally baked into the next generation OSs. MCP is the wrong abstraction for all of that. Skills are better as pluggable interfaces, and I predict[0] chat and agentic loops will converge eventually (Anthropic already did this correctly; OpenAI, it's your turn) and skills marketplace will replace MCP in its current form. I see value in MCP, but it feels like a stopgap/stepping stone. [0] Where "predict" = "hope". The best solutions are often not the winners.

tacoooooooo 5d ago
Skills are adjacent to MCP. They do not cover the same surface, in anyway. I don't understand this argument at all (and I see lots of people making it, so enlighten me) I want my agent to be able to convert reliably between timezones. A skill does not solve this. It needs a deterministic tool it can call
- kaoD 5d ago
  Skills are not only Markdown files. I often structure my skills as small Python scripts and the actual Markdown is only the skill front matter and maybe some brief documentation. You can even stick an OpenAPI schema or whatever you see fit. If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed. It's just files, all the way down. If you find yourself operating with dates a lot maybe you need a `datetime` skill wrapping a bunch of tiny scripts. Fully deterministic, cheap on tokens, and you can even run them without an agent (shocking nowadays :P) As I identify repetitive actions I add (Claude adds) new scripts to the Skill to save tokens in the future, whereas MCP I'm at the mercy of the server provider. E.g. I have a Magic the Gathering skill with a bunch of tools to retrieve card databases, simulate hands, get card images... This article enlightened me: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/ https://mariozechner.at/posts/2025-11-02-what-if-you-dont-ne... This is why I don't feel Skills are orthogonal. They feel like MCP on steroids since the scripts can be composed with Bash et al (huge battle-tested ecosystem, plenty in the training set)... and you don't need crappy abstractions like "resources" (yes, that's a thing in MCP) when the agent has a shell and a filesystem. I've used this pattern to great success. Nowadays I just share these `.skill` packages with my friends (I think they're just a fancy ZIP file?) The only thing missing for me is credentials and sandboxing (see my GP post). I have my own ideas on how to solve this (and some of that Claude in cloud already solves for me), but it's not easy (which is how MCP won).

ramoz 5d ago

Even for coding agents. MCP is the only unified interface INTO harnesses. This pattern has not struck yet for most, but will soon in the coming months given the MCP spec. MCP has been about models calling tools., it is about to become some form of inverse and MCP will be the only actual way to integrate into the models. Simple example is sending an event to the model (today models have to poll)... these coming updates will cement MCP as permanent infrastructure.

visarga 5d ago

What matters is local server or not. Using a remote server means exposure.

paper2d 5d ago

Agree. MCP also helps in some esoteric use cases like interacting with legacy windows applications over COM. I created an MCP for Outlook 2019 desktop version and COM was the most straightforward way to let my agent interact with my mails for classification.