A lot of the best tooling around AI we're seeing is adding deterministic gates that the probabilistic AI agents work with. This is why I'm using MCP over http. I'm happy for the the agent to use it's intelligence and creativity to help me solve problems, but for a range of operations, I want a gate past which actions run with the certainty of normal software functions. NanoClaw sells itself on using deterministic filtering of your WhatsApp messages before the agent gets to see them, and proxies API keys so the agent bever gets them - this is a similar type of deterministic gate that allows for more confidence when working with AI.

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app.

For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy somebody finally remembered what protocols are for: reusable communications abstractions that are application-agnostic.

The point of MCP is to be a common communications language, in the same way HTTP is, FTP is, SMTP, IMAP, etc. This is absolutely necessary since you can (and will) use AI for a million different things, but AI has specific kinds of things it might want to communicate with specific considerations. If you haven't yet, read the spec: https://modelcontextprotocol.io/specification/2025-11-25

As soon as MCP came out I thought it was over engineered crud and didn’t invest any time in it. I have yet to regret this decision. Same thing with LangChain.

This is one key difference between experienced and inexperienced devs; if something looks like crud, it probably is crud. Don’t follow or do something because it’s popular at the time.

This seems misguided when you have to work in enterprise settings. MCP is a very natural fit for all the API auditing and domain borders that exist in enterprise environments, because it provides deterministic tooling and auditable interfaces for agents. Nobody wants an AI agent doing random API calls or shell commands.

As someone charged with enabling users across an enterprise with AI tooling, the majority of whom are not in the software dev category, this article is perfectly mirroring my approach. Which is reassuring!

Challenges we are solving with centralised MCP are around brand guardianship, tone of voice, internal jargon and domain context, access to common data sources, and via the resources methods in MCP access to “skills” that prescribe patterns and shims for expected paths and ways of connecting/extracting data.

MCP is fine, particular remote MCP which is the lowest friction way to get access to some hosted service with auth handled for you.

However, MCP is context bloat and not very good compared to CLIs + skills mechanically. With a CLI you get the ability to filter/pipe (regular Unix bash) without having to expand the entire tool call every single time in context.

CLIs also let you use heredoc for complex inputs that are otherwise hard to escape.

CLIs can easily generate skills from the —help output, and add agent specific instructions on top. That means you can give the agent all the instructions it needs to know how to use the tools, what tools exist, lazy loaded, and without bloating the context window with all the tools upfront (yes, I know tool search in Claude partially solves this).

CLIs also don’t have to run persistent processes like MCP but can if needed

I’ve always felt like MCP is way better suited towards consumer usage rather than development environments. Like, yeah, MCP uses a lot of a context window, is more complex than it should be in structure, and it isn’t nearly as easy for models to call upon as a command line tool would be. But I believe that it’s also the most consumer friendly option available right now.

It’s much easier for users to find what exactly a model can do with your app over it compared to building a skill that would work with it since clients can display every tool available to the user. There’s also no need for the model to setup any environment since it’s essentially just writing out a function, which saves time since there’s no need to setup as many virtual machine instructions.

It obviously isn’t as useful in development environments where a higher level of risk can be accepted since changes can always be rolled back in the repository.

If I recall correctly, there’s even a whole system for MCP being built, so it can actually show responses in a GUI much like Siri and the Google Assistant can.

The problem with MCP isn't MCP. It's the way it's invoked by your agent.

IMO, by default MCP tools should run in forked context. Only a compacted version of the tool response should be returned to the main context. This costs tokens yes, but doesn't blow out your entire context.

If other information is required post-hoc, the full response can be explored on disk.

One part that makes me wary of these tools is security.

If I use a remote MCP or CLI that relies on network calls, and I give it in the hands of my coding assistant, wouldn't be too easy to inject prompts and exfiltrate data from my machine?

At least MCP don't have direct access to my machine, but CLIs do.

MCPs are great for some use cases

In v0, people can add e.g. Supabase, Neon, or Stripe to their projects with one click. We then auto-connect and auth to the integration’s remote MCP server on behalf of the user.

v0 can then use the tools the integration provider wants users to have, on behalf of the user, with no additional configuration. Query tables, run migrations, whatever. Zero maintenance burden on the team to manage the tools. And if users want to bring their own remote MCPs, that works via the same code path.

We also use various optimizations like a search_tools tool to avoid overfilling context

As yourself: what kind of tool I would love to have, to accomplish the work I'm asking the LLM agent to do? Often times, what is practical for humans to use, it is for LLMs. And the reply is almost never the kind of things MCP exports.

I find that skills work very well. The main SKILL file has an overview of all the capabilities of my platform at a high level and each section links to a more specific file which contains the full information with all possible parameters for that particular capability.

Then I have a troubleshooting file (also linked from the main SKILL file) which basically lists out all the 'gotchas' that are unique to my platform and thus the LLM may struggle with in complex scenarios.

After a lot of testing, I identified just 5 gotchas and wrote a short section for each one. The title of each section describes the issue and lists out possible causes with a brief explanation of the underlying mechanism and an example solution.

Adding the troubleshooting file was a game changer.

If it runs into a tricky issue, it checks that troubleshooting file. It's highly effective. It made the whole experience seamless and foolproof.

My platform was designed to reduce applications down to HTML tags which stream data to each other so the goal is low token count and no-debugging.

I basically replaced debugging with troubleshooting; the 5 cases I mentioned are literally all that was left. It seems to be able to quickly assemble any app without bugs now.

The 'gotchas' are not exactly bugs but more like "Why doesn't this value update in realtime?" kind of issues. They involve performance/scalability optimizations that the LLM needs to be aware of.

If it's a remote API, I suppose the argument is that you might as well fetch the documentation from the remote server, rather than using a skill that might go out of date. You're trusting the API provider anyway.

But it's putting a lot of trust in the remote server not to prompt-inject you, perhaps accidentally. Also, what if the remote docs don't suit local conditions? You could make local edits to a skill if needed.

Better to avoid depending on a remote API when a local tool will do.

I am not sure where the OP is hearing that the hype cycle is dissipating, but MCP adoption is actually accelerating, not decreasing [1]

More than 200% growth in official MCP servers in past 6 months: https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...

I have moved towards super-specific scripts (so I guess "CLI"?) for a few reasons:

1. You can make the script very specific for the skill and permission appropriately.

2. You can have the output of the script make clear to the LLM what to do. Lint fails? "Lint rules have failed. This is an important for reasons blah blah and you should do X before proceeding". Otherwise the Agent is too focused on smashing out the overall task and might opt route around the error. Note you can use this for successful cases too.

3. The output and token usage can be very specific what the agent needs. Saves context. My github comments script really just gives the comments + the necessary metadata, not much else.

The downsides of MCP all focus on (3), but the 1+2 can be really important too.

> Centralization is Key

> (I preface that this is primarily relevant for orgs and enterprises; it really has no relevance for individual vibe-coders)

The thing about tools that "democratize" software development, whether it is Visual Studio/Delphi/QT or LLMs, is that you wind up with people in organizations building internal tools on which business processes will depend who do not understand that centralization is key. They will build these tools in ignorance of the necessity of centralization-centric approaches (APIs, MCP, etc.) and create Byzantine architectures revolving around file transfers, with increasing epicycles to try to overcome the pitfalls of such an approach.

The only value—and it’s significant—that a fixed-tools protocol like MCP can provide is to serve as the capability base for an embedded agent security model.

The agent can only perform the operations it has been expressly given tools to perform, and its invocation of those tools can be audited and otherwise governed.

Whether MCP evolves to fulfill this role effectively, time will tell.

I don't know. Skill+http endpoint feel way safer, powerful and robust. The problem is usually that the entity offering the endpoint, if the endpoint is ai powered, concur in LLM costs. While via mcp the coding agent is eating that cost, unless you are also the one running the API and so can use the coding plan endpoint to do the ai thing

So if I release a new cli. How do I get the LLM to know about it? Do i tell it every time to run the command? Do I build a skill. Should I release a skill with the cli? Do I just create docs on GitHub and hope the next crawl gets into the training set?

There is another differentiator between CLIs and MCP.

The CLI are executed by the coding assistants in the project directory, which means that they can get implicit information from there (e.g. git branch and commit)

With an MCP you would need a prepare step to gather that, making things slower.

Today is Pi Day and I bumped into this blog:

https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#to...

Being 4.5 months behind the trend has its advantage. ;-)

I use Claude Cowork to talk to my (remote) CMS over MCP to continually improve all content in my website. If I find a new nugget of interesting information, I tell it to improve my content with it. I created lots of tools to help it do things that would require multiple calls in a pure, basic REST api. Plus you can describe lots of guidelines right in the MCP instructions.

I hear everyone talking about skills, but I this something I should use skills for?

Can you please share source code for the Resources/Prompts example ?

> Influencer Driven Hype Cycle

In MCP setups you do give the agent the full description of what the tool can do, but I don't see why you couldn't do the same for executables. Something like injecting `tool_exe --agent-usage` into the prompt at startup.

Great article otherwise. I've been wondering why people are so zealous about MCP vs executable tools, and it looks like it's just tradeoffs between implementation differences to me.

One aspect I think is often overlooked in the CLI vs. MCP debate: MCP's support for structured output and output schema (introduced in the 2025-06-18 spec). This is a genuinely underrated feature that has practical implications far beyond just "schema bloat."

Why? Because when you pair output schema with CodeAct agents (agents that reason and act by writing executable code rather than natural language, like smolagents by Hugging Face), you solve some of the most painful problems in agentic tool use:

1. Context window waste: Without output schema, agents have to call a tool, dump the raw output (often massive JSON blobs) into the context window, inspect it, and only then write code to handle it. That "print-and-inspect" pattern burns tokens and attention on data the agent shouldn't need to explore in the first place.

2. Roundtrip overhead: Writing large payloads back into tools has the same problem in reverse. Structured schemas on both input and output let the agent plan a precise, single-step program instead of fumbling through multiple exploratory turns.

There's a blog post on Hugging Face that demonstrates this concretely using smolagents: https://huggingface.co/blog/llchahn/ai-agents-output-schema

And the industry is clearly converging on this pattern. Cloudflare built their "Code Mode" around the same idea (https://blog.cloudflare.com/code-mode/), converting MCP tools into a TypeScript API and having the LLM write code against it rather than calling tools directly. Their core finding: LLMs are better at writing code to call MCP than at calling MCP directly. Anthropic followed with "Programmatic tool calling" (https://www.anthropic.com/engineering/code-execution-with-mc..., https://platform.claude.com/docs/en/agents-and-tools/tool-us...), where Claude writes Python code that calls tools inside a code execution container. Tool results from programmatic calls are not added to Claude's context window, only the final code output is. They report up to 98.7% token savings in some workflows.

So the point here is: MCP isn't just valuable for the centralization, auth, and telemetry story the author laid out (which I fully agree with). The protocol itself, specifically its structured schema capabilities, directly enables more efficient and reliable agentic workflows. That's a concrete technical advantage that CLIs simply don't offer, and it's one more reason MCP will stick around.

Long live MCP indeed.

This came up in recent discussions about the Google apps CLI that was recently released. Google initially included an MCP server but then removed it silently - and some people believe this is because of how many different things the Google Workspace CLI exposes, which would flood the context. And it seemed like in social media, suddenly a lot of people were talking about how MCP is dead.

But fundamentally that doesn’t make sense. If an AI needs to be fed instructions or schemas (context) to understand how to use something via MCP, wouldn’t it need the same things via CLI? How could it not? This article points that out, to be clear. But what I’m calling out is how simple it is to determine for yourself that this isn’t an MCP versus CLI battle. However, most people seem to be falling for this narrative just because it’s the new hot thing to claim (“MCP is dead, Long Live CLI”).

As for Google - they previously said they are going to support MCP. And they’ve rolled out that support even recently (example from a quick search: https://cloud.google.com/blog/products/ai-machine-learning/a...). But now with the Google Workspace CLI and the existence of “Gemini CLI Extensions” (https://geminicli.com/extensions/about/), it seems like they may be trying to diminish MCP and push their own CLI-centric extension strategy. The fact that Gemini CLI Extensions can also reference MCP feels a lot like Microsoft’s Embrace, Extend, Extinguish play.

This is confused and misguided.

The fundamental proposal here is that despite being bad MCP is the correct choice for Enterprise because:

> Organizations need architectures and processes that start to move beyond cowboy, vibe-coding culture to organizationally aligned agentic engineering practices. And for that, MCP is the right tool for orgs and enterprises.

…but, you can distill this to: the “cowboys” are off MCP because they've moved to yolo openclaw, where anything goes and there are no rules, no restrictions and no auditing.

…but thats a strawman from the twatter hype train.

Enterprises are not adopting openclaw.

It’s not “MCP or Openclaw”.

Thats a false dichotomy.

The correct question is: has MCP delivered the actual enterprise value and actual benefits it promised?

Or, were those empty promises?

Does the truely stupid MCP ui proposal actually work in practice?

Or, like the security and auditing, is it a disaster in practice, which was never really thought through carefully by the original authors?

It seems to me, that vendors are increasingly determining that controlled AI integrations with rbac are the correct way forward, but MCP has failed to deliver that.

Thats why MCP is dying off.

…because an open plugin ecosystem gives you broken crap like the Atlassian MCP server, and a bunch of maybe maybe 3rd party hacks.

Thats not what enterprises want, for all the reasons in the article.

>The LLM has no way of knowing which CLI to use and how it should use it…unless each tool is listed with a description somewhere either in AGENTS|CLAUDE.md or a README.md

This is what the skill file is for.

>Centralizing this behind MCP allows each developer to authenticate via OAuth to the MCP server and sensitive API keys and secrets can be controlled behind the server

This doesn't require MCP. Nothing is stopping you from creating a service to proxy requests from a CLI.

The problem with this article is it doesn't recognize that skills is a more general superset compared with MCP. Anything done with MCP could have an equivalent done with a skill.

Great article, and what I would expect from someone inspecting the hype and not jumping head first, just because influencers (paid or unpaid) are screaming for engagement just because a large X account posted their opinions.

This is one of the first posts that I've see that cuts through the hype against both MCPs and CLIs with nuance findings.

There were times where it didn't make sense for using MCPs (such as connecting it to a database) and CLIs don't make sense at all for suddenly generating them for everything. It just seems like the use-case was a solution in search of a problem on top of a bad standard.

But no-one could answer "who" was the customer of each of these, which is why the hype was unjustified.

I’m struggling to understand the recent wave of backlash against MCP. As a standard, it elegantly solves a very real set of integration problems without forcing you to buy into a massive framework.

It provides a unified way to connect tools (whether local via stdio or remote via HTTP), handles bidirectional JSON-RPC communication natively, and forces tools to be explicit about their capabilities, which is exactly what you want for managing LLM context and agentic workflows.

This current anti-MCP hype train feels highly reminiscent of the recent phase where people started badmouthing JSON in favor of the latest niche markup language. It’s just hype driven contrarianism trying to reinvent the wheel.