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.
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.
I wish. https://modelcontextprotocol.io/specification/2026-07-28
In practice, I believe Tools represent 95%+ of what people actually use MCP for. I've not seen an MCP with Resources or Prompts that seems to have widespread use of those features, and I don't think I've ever seen anything implement Elicitation.
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?
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.
I disagree. Adding "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.
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
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.
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.
Less token spend, lower latency, more predictable results compared to having the LLM perform the task directly every time.
Best of both worlds in my view.
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.
That only applies if you are talking about a well established recurrent workflow. That's not how MCPs are used to begin with.
Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.
Not sure whats the norm nowadays, but it used to be MCP descriptions were loaded in from the start.
In any case, to be cheaper the `cli --help` command needs to more noisy than the json description.
Finally, and the really big one: cli can be composed with `grep`, `jq` , etc.
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.
Is using curl considered re-implementing your own api client each time?
And When "normal" people talk about api clients? lol This site is wild.
If it's just a set of tokens in the current session, well then next session it has to figure out the workflow, and then store it in a way to use in the next session.
Seems like maybe you should take your own advice.
> Seems like maybe you should take your own advice.
Seems like maybe if you have to use your own custom definition of a word in order to support a point you might not have one. lol.
Many apis require several requests to get things done. (one to auth, one or more to fecth resource ids, one or more to modify resources, etc).
That would be a series of curl calls with logic applied to the output of each call to curl. An api client just does those things in a single function call. The steps are the same, but in one case the AI has to figure out each curl call and implement the logic, rather than just call the function.
Irony died in this comment thread.
It makes sense though. It's the same logic that allows you to say promting an AI with "do a simple thing for me" makes you a programmer, and prompting an AI with "what is an api" allows makes you knowledgable about computers.
Well yes.
Instead they invented something new/weird/complex standard, and then every client implemented slightly differently (and different parts of it).
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?
Relying on an intermediary to provide access controls, and that agents will never access the service directly, seems dangerous and naive.
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.
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.
That's the opposite of a false sense of security.
However, maybe I'm missing something but how is defining access rights in an application layer the agent has access to more secure than defining the access rights at the target application itself?
Sure, hiding the filesystem via encapsulation tricks is one way to go. But what is the real-world usage-style of this vs. all MCP usages? I'd wager 1-10% are spending this extra effort, while 90% of users basically run shims so that they can expose APIs to their LLMs, for which they have no/bad access rights management.
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.
Sounds to me like MCP with a slightly different interface.
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.
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.
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.
> 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.
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.
Would be a much more robust and general solution of the problem of controlling and auditing agentic access to sensitive information.
Hopefully this is easier as time goes on. Of course- also policy on the egress
Implanting an MCP client in your agent code isn’t all that different from calling requests or whatever
I guess the main problem would be finding an API client that can easily plug into your harness, with a nice UI for turning specific APIs on and off.
"Sandboxing bash" is a problem that has been solved a zillion years ago already. Take your pick of any of the dozens of battle-proven solutions.
Bonus points if it's available on both macOS and Linux and doesn't come from a random unmaintained GitHub repository with a note in the README that says "don't run this in production".
For personal work, I run Codex in a VM that contains only what's necessary to do software development. Could it escape the VM? Sure, if there's a zero-day in VMWare Workstation.
Yeah, I'm using a pile driver when I really probably just need a hammer, but I've seen too many horror stories, and I don't trust guard rails. Even if there was an option to limit Bash calls to read-only operations, I would be 0% surprised to eventually run into "You're absolutely right! `rm -rf / --no-preserve-root` was a write operation! That's totally on me."
MCP was a convenient answer for companies that had spent the last few years shutting down APIs because allowing API access bad.
LLMs perform significantly better and faster when you strap them to plain old apis/and an open api spec with a search tool.
My current MCP design is… grab a fastapi spec shove it into fastmcp, shallow wrapper, search tool for the full schema.
Oh boy so exciting I just wrapped an api spec for no reason and have to host infra for the translation layer. If only we invented api gateways.
But I am Mr. AI now.
If you have self hosted models and/or self hosted APIs, maybe you don’t need MCP to provide a gateway to a secure resource.
If neither of those things are true, you need an authenticating gateway/proxy or a target API that supports single use credentials (and get the model to generate a call to use them).
We can argue whether MCP is a good authenticating middle layer, but not whether one is required.
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.
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
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-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).
okay, but now my agent needs a coding environment / sandbox.
MCP (or tool use in general) solves this without that (extremely tenuous and expensive to do at scale in prd) requirement.
The skill is totally orthogonal here--solving a totally separate problem
But if im running a customer support agent at scale, i'm not sure I want it to be able to write code. I do know I need it to be able to convert timezones though. (its also far more expensive / token inefficient to have it write code each time to convert timezones rather to use a predefined tool I made an know works)
It does not write code. It just calls my tool.
But I see your other points though.
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.
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.
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.
It works well, though there is some leakiness around paths. I opted to make it place/mount files at the same path as on the host so paths are the same (as opposed to manipulating the ACP messages to modify paths on the fly, that felt messy and buggy).
Configurable networking is on my list for the future, but I haven't decided whether to start with IP-level firewalls or if it's better to start with a proxy and firewall rules to force traffic to it. IP firewalls suck for APIs that might have semi-dynamic IPs.
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.
Going without the sandbox means hobbling the LLM. It can do things directly but is less able to construct ad-hoc programs to deal with looping, conditionality, tame verbosity, connect tools together, and so on.
It's a choice to not give the LLM an environment. As you say, it can be necessary if you're using dumb models. I don't find it particularly worth the trade most of the time.
These guys are the common factor, the guys running the evals that let all the AI agents out, it looks like.
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.
If you don't have something running somewhere, you don't have an agent, you don't have a harness. You've got a token generator, an LLM from the 2024 era.
MCP suffers from its harebrained choice early on to load everything into context up front.
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.
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.)
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.
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.)
Well, yeah. Subprocess execution is on the order of double-digit milliseconds. The "wiring up" is maintaining a whitelist of what tool commands map to which executable. It's a lookup table with very little maintenance required.
> 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.
I feel like I am taking crazy pills :-/
The overhead of forking, on the ancient machine I call my desktop, is at most double-digit milliseconds. The state isn't being tracked by the MCP server anyway, it'll be tracked by the harness and/or the model, no?
My main reason for adding MCP support is so that existing callers that want to use my WebApp(s) can just use it without needing any changes on their side.
IOW, I am going to add it at some point, but not for the reasons you give. I'll add it to be compatible.
(Oddly enough I did solve that with my own CLI tool for running browsers during my "who needs MCP" phase, but it's a bit of a nasty hack that involves leaving files with PIDs lying around: https://github.com/simonw/rodney#directory-scoped-sessions and https://github.com/simonw/rodney/blob/a842432246f39775ccb14f...)
We have reached the point where we need to control agent access the same way we control human access to systems.
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.
"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.
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.
MCP doesn't inherently make this easier. its still requires engineering maintaincence.
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?
Because the alternative, as proposed in the article, is that an agent researches an API/CLI/UI, builds software to interact with it, and then runs that. Every time again. Not only very inefficient, it's unpredictable, and often slow.
Just last week I had an MCP that was down (my mistake) and the agent "decided" that in order to finish my request, it needed to create a python script, refactor that, debug that, and then use that, so it could access my notes (Joplin) over the API and write it's weekly update markdown there. Somehow the thread produced a python tool with over 400 lines of code, five files. It, at some point, even considered putting all that in a git repo. And went on a side-quest to run docker containers.
With the MCP, this job typically takes between $0.05 (Mistral) or $0.90 (Claude Opus). It now cost me $17.00. It took nearly 30 minutes. To write a note in Joplin!
MCPs, or any de-facto standard/pre-known protocol, makes operating on external tools and resources cheaper, faster and above all more predictable.
The scripts that were generated included code to determine if joplin was running, and to launch it if not. It included a proxy server, that would listen on a localhost:xxxx and if a HTTP request came in, this proxy would auto-launch joplin and then forward the request/response. It then included quite some code to de/serialize json to/from datatypes.
Part of this "overengineering" came from a "skill" that claude found globally which I wrote for myself when working on a few python tools. The skill required strict typing, demanded refactoring, insisted on doing everything over http (and not local commands).
Basically, the agent could not perform its task over an MCP and should've stopped. But I suspect either tuning or some system-prompt made claude go on instead. It decided to use python, and then found my "requirements for when writing python", followed that, and burned a lot of tokens to make one or two HTTP requests.
Now, if you’re letting your agents abuse network traffic there becomes a point where you’re criminally liable. Unfortunately the current US government has no interest in prosecuting such abuse.
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.
Had we not abandoned REST we'd still have APIs that are self documenting and typed/schemaed. Bonus if browsers still supported XSLT, that same API could have been written in XML and only browsers wanting a visual representation would load HTML templates while agents could stick with the raw XML.
But you don't want to just give any old agent raw curl access, so now you've got to provide a special client that can call just the APIs /endpoints that they're supposed to be able to. And it needs to know what the agent shouldn't be able to do as well. And it also needs to be able to handle things like auth, because you don't want the average person (or the agent!) handling bearer tokens. And you probably want a layer in between that validates everything against an OAS so the agent can't make invalid requests.
And now you've effectively just reinvented the good parts of MCP with extra tokens.
Soap was a pain and a lot of people didn't like XML, but they solved exactly these problems.
With MCP we're effectively trying to bolt those features onto a platform that fundamentally doesn't support it. Where as with XML/XSLT we could have a single XML endpoint + XSLT templates for converting that into HTML for browsers. Instead we now have modern web frameworks building RPC calls right into the bundle/build step, splitting state and rendering across both client and server, and have to stand up a new API context for agents that needs documentation and maintenance to keep parity with new features.
Agents emit tool calls as JSON. Calling a REST API means emitting a JSON tool call that invokes a HTTP client with all the desirable properties (schema checking, safe auth) and none of the undesirable ones (raw key handling, arbitrary endpoint access). Then the response gets wrapped in JSON and returned to the LLM. That's not an MCP thing, that's a model thing.
MCP says "instead of http_post with a bunch of arguments that need to be correct, call get_weather with a zip code". And then it makes principled choices for how get_weather and its schema is defined. That's literally the whole point.
Even if you wanted to use WSDL to accomplish this, you either have to unwind how literally every function calling implementation of every model works today and teach them how to read WSDL and speak XML (and deal with all the other problems, like auth), or you avoid the two layers of indirection and define a system that works with what exists today, and that solution ends up looking very MCP-shaped.
You might say "well you could just have a little script/xslt that does the translation". That's exactly what a local MCP server is.
LLMs will happily work with XML, including to understand data schemas and discover available actions that can be taken.
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.
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.
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.
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/
There is usually a kernel of value that has to be extracted and translated to apply what works for the solo AI engineer and what works for the team.
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!
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.
For example, grafana has a newer CLI called gcx that replaced grafanactl 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.
Also this how most ADEs enable agent messaging and the like
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
Now both Google and Apple are making app interfaces legible and on-device tool calling discoverable. This will change apps in interesting ways.