No, a CLI with RPC can do exactly that, just smaller. It goes lower in the exact same stack without the fluff.
Than pass the program, your server or application can parse the instructions and work from the generated AST to do all sorts of interesting things, within the confines of your language features.
It's verifiable, since you are providing within the defined grammar, and with the parser provided.
It is implicitly sandboxed by the powers you give (or rather exclude) to your runtime via an interpreter/compiler
I've tried this before for a grammar I defined for searching documents, and found it to be quite good at creating valid often complex search instructions.
It seems like a lot of the discussion is arguing in favor of API usage without realizing that MCP basically standardizes a universal API, thus enabling code mode.
Take Codex, for example, it does not support the MCP prompts spec[0][1] which is quite powerful because it solves a lot of friction with deploying and synchronizing SKILL.md files. It also allows customization of virtual SKILL.md files since it allows compositing the markdown on the server.
It baffles me why such a simple protocol and powerful capability is not supported by Codex. If anyone from OpenAI is reading this, would love to understand the reasoning for the poor support for this relatively simple protocol.
[0] https://github.com/openai/codex/issues/5059
[1] https://modelcontextprotocol.io/specification/2025-06-18/ser...
The same thing plays out at the language layer. The pain of C++ multiple inheritance drove people toward better abstractions. If LLM's absorb that friction before it reaches anyone, the signal that produces the next Go never gets felt by the people who could act on it.
Wrote about where that leads: https://blog.covet.digital/a/the_last_language_you_can_read....
Both are useful to different people (and role families) in different ways and if you don't feel certain pain points, you may not care about some of the value they provide.
Agent skills are useful because they're standardized prompt sharing but more than that, because they have progressive disclosure so you don't bloat your context with an inefficietly designed MCP and their UX is very well aligned such that "/SkillBuilder" skills are provided from the start and provide a good path for developers or non traditional builders to turn conversations into semi or full automation. I use this mental model to focus on the iteration pattern and incremental building [1].
[1] https://alexhans.github.io/posts/series/evals/building-agent...
I’ll often see the agent saying it’s about to do something so I’ll stop it and ask “what does the xxx skill say about doing that?’ And it’ll go away and think and then say “oh, the skill says I should never do that”
That is a meaningful distribution shift. Products no longer need to be marketed to end users if an agent can find and invoke them directly. Skills require the developer to install them ahead of time, which means someone already decided this tool was relevant.
For chatgpt desktop and Claude desktop my experience with MCPs connected to my home NAS is pretty poor. It(as in the app) often times out fetching data(even though there is no latency for serving the request in the logs), often the existing connection gets invalidated between 2 chat turns and chat gpt just moves on answering without the file in hand.
I am not using it for writing code, its mostly read only access to Fs. Has anyone surmounted these problems for this access patterns and written about how to build mcps to be reliable?
> ChatGPT can’t run CLIs. Neither can Perplexity or the standard web version of Claude. Unless you are using a full-blown compute environment (like Perplexity Computer, Claude Cowork, Claude Code, or Codex), any skill that relies on a CLI is dead on arrival.
Incorrect observation. Claude web does support skills upload. I guess claude runs code_interpreter tool and filesystem in the background to run user uploaded skills. ChatGPT business plans too allow uploading custom skills in web.I can see Skills becoming a standard soon. But the concern still holds. When you publish a MCP you liberate the user out of installing anything. But with skills what happens if the skill running environment don't have access to the cli binary or if it isn't in PATH?
With the CLI the agent could check out the project, work on it locally with its standard file editing / patching / reading tools, then push the work back to device. Run and debug on device, edit locally, push.
With MCP the agent had to query the MCP server for every read and write and was no longer operating in its normal coding loop. It still works, though, and as a user you can choose to bypass the CLI and connect directly via MCP.
The MCP server was valuable as it gave us a consistent and deterministic language to speak. The CLI tool + Skill was valuable for agentic coding because it allowed the coding work to happen with the standard editing tools used by agents.
The CLI also gave us device discovery. So the agent can simply discover nearby devices running Codea and get to work, instead of a user having to add a specific device via its IP address to their agent.
This is how I am structuring stuff in Claude Code
- Ansible setup github cli, git, atlassian cli, aws-cli, terraform cli tooling
- Claude hooks for checking these cli tools are authenticated and configured
- Claude skills to use the CLI tooling
E.g. if I have some ElasticSearch cluster, I use a skill to describe the data, and if I ask the LLM to write code that queries ElasticSearch but to test it first it can use a combination of skill + MCP to actually run a query.
I think this model works nicely.
Imagine you are creating an asset which requires multiple API calls and your UI is designed to go through a 10-12 step setup process for that asset. In practice even if we give one tool for LLM to one-shot it, or even if we break it down into 10-12 tools the points of hallucinations are much higher.
Contrast this with "skills" and CLI.
I started out building an MCP server for an internal wiki, but ended up replacing it with a simple CLI + skill because the wiki had no access control and the simpler setup was good enough in practice.
I think that's the important boundary, though: once access control, auth, or per-user permissions enter the picture, I'd much rather have MCP as the interface than rely on local tooling conventions.
- "CLIs need to be published, managed, and installed" -- same for MCP servers which you have to define in your config, and they frequently use some kind of "npx mcp-whatever" call.
- "Where do you put the API tokens required to authenticate?" -- where does an MCP server put them? In your home folder? Some .env file? The keychain? Same like CLI tools.
- "Some tools support installing skills via npx skills, but that only works in Codex and Claude Code, not Claude Cowork or standard Claude" -- sure, but you also can't universally define MCP servers for all those tools. You have to go ahead and edit the config anyway.
- "Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs" -- yeah, but it's on-demand rather than exposing ALL MCP servers' tool signatures. Have you ever tried to use playwright MCP?
I just don't buy the "without any setup" argument.
The first is using agents locally to develop.
The second is developing an agent. Not necessarily for coding, mind you. Not even for just text sometimes.
They are different cases, MCP is great for the latter.
1. Ask the LLM to build a tool, under your guide and specification, in order do a specific task. For instance, if you are working with embedded systems, build some monitoring interface that allows, with a simple CLI, to do the debugging of the app as it is working, breakpoints, to spawn the emulator, to restart the program from scratch in a second by re-uploading the live image and resetting the microcontroller. This is just an example, I bet you got what I mean.
2. Then write a skill file where the usage of the tool at "1" is explained.
Of course, for simple tasks, you don't need the first step at all. For instance it does not make sense to have an MCP to use git. The agent knows how to use git: git is comfortable for you, to use manually. It is, likewise, good for the LLM. Similarly if you always estimante the price of running something with AWS, instead of an MCP with services discovery and pricing that needs to be queried in JSON (would you ever use something like that?) write a simple .md file (using the LLM itself) with the prices of the things you use most commonly. This is what you would love to have. And, this is what the LLM wants. For complicated problems, instead, build the dream tool you would build for yourself, then document it in a .md file.
Are you a solo developer, are you fully in control of your environment, are you focused on productivity and extremely tight feedback loops, do you have a high tolerance for risk: you should probably use CLIs. MCPs will just irritate you.
Are you trying to work together with multiple people at organizational scale and alignment is a problem; are you working in a range of environments which need controls and management, do you have a more defensive risk tolerance ... then by the time you wrap CLIs into a form that are suitable you will have reinvented a version of the MCP protocol. You might as well just use MCP in the first place.
Aside - yes, MCP in its current iteration is fairly greedy in its context usage, but that's very obviously going to be fixed with various progressive-disclosure approaches as the spec develops.
I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive.
If I need to call an API, a skill with existing CLI tooling is more than capable.
A skill is just a description for how to use an existing CLI tool. You don't need to write new code for the LLM to interact with some system. You just tell the LLM to use the same tool humans do. And if you find the CLI is lacking in some way, you can improve it and direct human usage benefits from that improvement too.
On the other hand, an MCP requires implementing a new API for a service, an API exclusive to LLMs, and keeping parallel documentation for that. Every hour of effort put into it is an hour that's taken away from improving the human-facing API and documentation.
The way skills are lazy-loaded when needed also keeps context clean when they're not used. To be fair, MCPs could be lazy-loaded the same way, that's just an implementation detail.
That being said, majority of users on this planet don't use AI agents like that. They go to ChatGPT or equivalent. MCP in this case is the obvious choice because it provides remote access and it has better authentication story.
In order to make any argument about pro/con of MCP vs Skills you first need to find out who is the user.
This only works for people using agents themselves on computers they control, rather than, e.g., the Claude web app, but is a good chunk of my usage.
I think people are either over or under thinking the auth piece, though. The agent should have access to their own token. Both CLIs and MCPs and even raw API requests work this way. I don't think MCPs provide any further security. You should assume the agent can access anything in its environment and do everything up to what the credential permits. You don't want to give your more powerful credential to the MCP server and hope that the MCP server somehow restricts the agent to doing less (it can probably find the credential and make out-of-band calls if it wants). The only way I think it could work like that is how... is it Sprite does it?... where you give use a fake token and have an off-machine proxy that it goes through where it MitMs the request and injects the real credential.
Despite many decades of proof that automation simplifies and reveals the illogical in organisations, digitisation has mostly stopped at below the “CXO” level - and so there are not APIs or CLIs available to anyone - but MCP is cutting through
Just consider:
Throughout companies large and small, Agile is what coders do, real project managers still use deadlines and upfront design of what will be in the deadline - so any attempt to convert the whole company to react to the reality of the road is blocked
Reports flow upwards - but through the reporting chain. So those PowerPoints are … massaged to meet to correct story, and the more levels it’s massaged the more it fails to resemble reality. Everyone knows this but managing the transition means potentially losing control …
There are plenty of digitisationmprojects going on - but do they enable full automation or are they another case of an existing political arena building its own political choices in software - “our area in a database to be accessed via an UI by our people” - almost never “our area to be used by others via API and totally replacing our people”.
(I think I need to be more persuasive
MCP makes a lot of sense for enterprise IMO. Defines auth and interfaces in a way that's a natural extension of APIs.
MCP has severe context bloat just by starting a thread. If harnesses were smart enough to, during install time, summarize the tools provided by a MCP server (rather than dumping the whole thing in context), it would be better. But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else
A solution is to have the agent run a cli tool to access mcp services. That way the agent can filter the output with jq, store it in a file for analysis later, etc
Wrong. It needs to "understand" both these things. The only difference is where and how the strings explaining them are generated.
Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge.
MCP’s are great for custom, repeatable tasks. After 5-10 runs of watching my LLM write the same exact script, I just asked it to hardcode the solution and make it a tool. The result is runs are way faster and repeatable.
Everything will go to the simplest and most convenient, often both, despite the resistance of the complexity lovers.
Sorry MCP, you are not as simple as CLI/skill/combination, and no, you are not more secure just because you are buried under 3 level of spaghetti. There are no reason for you to exist, just like Copilot. I don't just wish, but know you'll go into obscurity like IE6.
You may dislike MCP, and there are certainly valid arguments to be made there, but that doesn't mean you can replace it with skills. If you could replace a given MCP server with a skill it would only indicate that someone misunderstood the assignment and chose the wrong tool in the first place. It wouldn't indicate the superiority of one thing over the other.
This whole article, and it's current rank on HN (#5), is making me feel like I took crazy pills this morning. A colleague suggests this Skills vs MCP discourse is big on Twitter, so maybe I lack the necessary background to appreciate this, but aren't these different tools, solving for different things, in different ways? Is this parody? Am I falling into a bot engagement trap by even responding to this? The article certainly reads like LinkedIn drivel, with vague, emphatic opinions about nothing.
That's exactly the problem. As agents become better and can read API documentation themselves, WHY do you need an API abstraction?
I built this to solve this exact problem. https://github.com/turlockmike/murl
edit: just want to add, i still haven't implemented a single mcp related thing. Don't see the point at all. REST + Swagger + codegen + claude + skills/tools works fine enough.
What if you don’t want the AI to have any write access for a tool? I think the ability to choose what parts of the tool you expose is the biggest benefit of MCP.
As opposed to a READ_ONLY_TOOL_SKILL.md that states “it’s important that you must not use any edit API’s…”
These commands would be well defined and standardised, maybe with a hashed value that could be used to ensure re-usability (think Docker layers).
Then I just have a skill called:
- github-review-slim:latest - github-review-security:8.0.2
MCPs will still be relevant for those tricky monolithic services or weird business processes that aren't logged or recorded on metrics.
I noticed that LLMs will tend to work by default with CLIs even if there's a connected MCP, likely because a) there's an overexposure of CLIs in training data b) because they are better composable and inspectable by design so a better choice in their tool selection.
low quality troll
If an enterprise already has internal tooling with authn/z, there's no reason to overlay on top of that.
MCPs main value is as a structured description of an agent-usable subset of an API surface with community traction, so you can expect it to exist, be more relevant than the OpenAPI docs.
I’d really love to get away from the SSE MCP endpoints we use, as the Claude desktop app can get really finicky about disconnects. I thought about distributing some CLIs with Skills instead. But, MCP can be easily updated with new tools and instructions, and it’s easy to explain how to add to Claude for non-technical people. I can’t imagine trying to make sure everyone in my company had the latest skill and CLI on their machine.
Codex -> LiteLLM -> VLLM
|____> MCP
Takes a couple of minutes to setup.How we access them and where data lives is essentially an optimization problem. And AI changes what is optimal. Having data live in some walled garden with APIs designed to keep people out (most SAAS systems) is arguably sub optimal at this point. Sorting out these plumbing issues is actually a big obstacle for people to do productive things via agentic tools with these systems.
But a good way to deal with this is to apply some system thinking and figure out if you still need these systems at all. I've started replacing a lot of these things with simple coder friendly solutions. Not because I'm going to code against these things but because AI tools are very good at doing that on my behalf. If you are going to access data, it's nicer if that data is stored locally in a way that makes it easy to access that data. MCP for some SAAS thing is nice. A locally running SQL database with the data is nicer. And a lot faster to access. Processing data close to where it is stored is optimal.
As for MCP. I think it's not that important. Most agentic coding tools switch effortlessly between protocols and languages. In the end MCP is just another RPC protocol. Not a particularly good or optimal one even. If you had an API or cli already, it's a bit redundant to add MCP. Auth is indeed a key challenge. And largely not solved yet. I don't think MCP adds a whole lot of new elements for that.
lol and why do you need mcp for that, why cant that be a classic http request then?
Hi, author here. The “MCP has severe context bloat” problem has already been solved with tool discovery. Modern harnesses don’t load every single tool + their descriptions into the context on load, but use tool search to discover the tools lazily when they’re needed. You can further limit this by telling the LLM exactly which tool to load, the rest will stay unloaded / invisible
> But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else
This is semi-solved as agents and harnesses get smarter. Claude Code for example does discovery in subagents. So it spawns a sub-agent with a cheaper model that explores your codebase / environment (also through MCP) and provides a summary to the parent process. So the parent won’t get hit with the raw output log
Whether it's tools, MCP or skills: they are fundamentally all just prompts. Even if the LLM is trained to recognize those and produce the right shape of tokens that validate most of the time.
But I wouldn't use the word "understand" here, because that builds the wrong intuition. I think a more useful term would be "get guided by" or "get nudged by". Even "recognize" is slightly misleading, because it implies too much.
The majority of processes don't need nearly as many decision making points as an agent could deal with and look somewhat like this:
1. gather raw information => script
2. turn it into structured data => script
3. produce an actionable plan => script/user/agent (depends)
4. validate the plan => user
5. narrow down the implementation workflow and the set of tools needed => user/agent
6. follow workflow iteratively => user/agent
Doesn't need to be this exact shape, but the lesson I learned is to quasi front load and structure as much as possible with scripts and data. That can be done with agent assistance as well, for example by watching it do the task, or a similar one, in freeform at first.
After the first run, you have a script and an API: the agent discovery mechanism is a detail. If the script is small enough, and the task custom enough, you could simply add the script to the context and say "use this, adapt if needed".
Or am I misunderstanding you?
Definitely not AI generated. I wrote this during a non-internet flight. :)
Maybe I'm misinterpreting you, but can you explain this more? I've been using skills for repeatable tasks. Why an MCP instead?
What about just putting that sort of thing in human-targeted documentation? Why call it a “skill” and hide it somewhere a human is less likely to look?
(Skills are nice for providing /shortcuts.)
however it can't get infected because there is no internet access.
the worst you can do is put your secrets in the web search box
MCP are tools - might as well have just called it API for AI, but that ship has sailed.
It's 100% apples and oranges!
You should feel so. Every time a thread about MCP on HN appears, half of the commenters obviously don't even know what MCP actually is and how it's used. Just right below someone suggests one should use "an API and a text file" instead of MCP (like, what do they think MCP is?).
On Twitter the ratio is even worse.
The continuous exploits of MCP despite limited adoption really makes this seem wrong.
- If you need to interact with a local app in a one-off session, then use CLI.
- If you need to interact with an online service in a one-off session, then use their API.
- If you need to interact with a local app in a persistent manner, and if that app provides an MCP server, use it.
- If you need to interact with an online service in a persistent manner, and if that app provides an MCP server, use it.
Whether the MCP server is implemented well is a whole other question. A properly configured MCP explains to the agent how to use it without too much context bloat. Not using a proper MCP for persistent access, and instead trying to describe the interaction yourself with skill files, just doesn't make any sense. The MCP owner should be optimizing the prompts to help the agent use it effectively.
MCP is the absolute best and most effective way to integrate external tools into your agent sessions. I don't understand what the arguments are against that statement?
Why on earth don't people understand that MCP and skills are complementary concepts, why? If people argue over MCP v. Skills they clearly don't understand either deeply.
I completely agree with you. There was a recent finding that said Agents.md outperforms skills. I'm old school and I actually see best results by just directly feeding everything into the prompt context itself.
https://vercel.com/blog/agents-md-outperforms-skills-in-our-...
An agent will eventually forget, or hallucinate, guardrails and requirements. Yes to AGENTS.md, but when you're actively managing the whole context window in a long-running task you don't want to just keep jamming stuff in there and hope for the best. Skills help budget tokens and stabilize around specific outcomes.
If your use case is not agentic, as you build a skill corpus you can begin having the model reason at higher and higher levels about the outcomes you're aiming at.
Eg: I'm super lazy now and ask Claude to launch the project instead of just running the command myself. This is probably best done as a skill.
How about driving the same truck without that half ton of water?
Honestly, an agent shouldn’t really care how it’s getting an answer, only that it’s getting an answer to the question it needs answered. If that’s a skill, API call, or MCP tool call, it shouldn’t really matter all that much to the agent. The rest is just how it’s configured for the users.
I wrap all my apis in small bash wrappers that is just curl with automatic session handling so the AI only needs to focus on querying. The only thing in the -h for these scripts is a note that it is a wrapper around curl. I havent had a single issue with AI spinning its wheels trying to understand how to hit the downstream system. No context bloat needed and no reinventing the wheel with MCP when the api already exists
Future version of the protocol can easily expose skills so that MCPs can acts like hubs.
The shoe is the sign. Let us follow His example!
Cast off the shoes! Follow the Gourd!
Also worth mentioning that some paid MCP providers offer an actual value added. Sure, I can use curl or a self hosted crawler for web searches, but is it really worth the pain?
CLI is the same API in more concise format. At minimum, the same amount of context overhead exist for MCP, but most of the time more because the boxes have size.
CLI can be secure, AWS CLI is doing just fine. You can also play simple tricks to hide secret in a daemon or run them remotely, and all of them are still smaller than a MCP.
Especially portability is just not possible with Skills+CLI (yet). I can use the same MCP servers through remote MCP on my phone, web, iPad, in ChatGPT, Perplexity, Claude, Mistral and so on, which I can’t do with Skills.
this way it doesn't download a trojan or leak your data to someone
Literally my biggest use case for MCP is Jira and Confuence
MCP is just wrapper on top of API layer that RCP to a worker/daemon. That API layer itself can be the CLI. You get no more context usage, and no extra security impact, because fundamentally the model are the same, just without the fluff.
You are probably thinking of CLI as in "oh I must pass everything and it is stateless". I'd suggest you to explore more.
MCP is just a wrapper on top, there are no inherent differences other than complexity on top.
How do you think MCP work under the hood?
What am I missing out on?
MCPs needs to be wrapped to be composed.
MCPs needs to implement stateful behavior, shell + cli gives it to you for free.
MCP isn't great, the main value of it is that it's got uptake, it's structured and it's "for agents." You can wrap/introspect MCP to do lots of neat things.
Nope.
The best way to interact with an external service is an api.
It was the best way before, and its the best way now.
MCP doesn't scale and it has a bloated unnecessarily complicated spec.
Some MCP servers are good; but in general a new bad way of interacting with external services, is not the best way of doing it, and the assertion that it is in general, best, is what I refer to as “works for me” coolaid.
…because it probably does work well for you.
…because you are using a few, good, MCP servers.
However, that doesn't scale, for all the reasons listed by the many detractors of MCP.
Its not that it cant be used effectively, it is that in general it is a solution that has been incompetently slapped on by many providers who dont appreciate how to do it well and even then, it scales badly.
It is a bad solution for a solved problem.
Agents have made the problem MCP was solving obsolete.
Well yes you don’t need those things all the time and who knows if the inventor of mcp had this idea in mind but here we are
What about auth? Authn and authz. Agent should be you always? If not, every API supports keys? If so, no fears about context poisoned agents leaking those keys?
One thing an MCP (server) gives you is a middleware layer to control agent access. Whether you need that is use-case dependent.
Isn't in that case an API what they want?
An "MCP for a local app" is just an API that exposes the internal workings of the app. An "MCP for mixpanel" is just an API that exposes Mixpanel API behind Auth. There is nothing special about them for any type of user. It's just that MCP's were "made popular".
For the same type of user, I have built better and smoother solutions that included 0 MCP servers, just tools and pure API's.Define a tool standard DX and your LLM can write these tools, no need to run a server anywhere.
That is also what the author seems to be mistaken about - you don't need a CLI. A CLI is used because the DX is nice and easily permutable with all the preexisting bash tooling that is ingrained into every LLM's dataset. You don't need a .env file if you're using an API with a skill. A skill can include a script, or mentions of tools, and you are the one who controls these.
All in all, the whole "MCP vs Skill" debate online is mostly based on fundamental misunderstandings of LLM's and how they work, how harnesses work and how API's in general work, with a lot of it being fueled by people who have no relevant coding experience and are just youtube/twitter "content creators".
Some arguments against MPC's, no matter who is the user:
- MCP is just a noisy, hacky wrapper around an API or IPC (well, API behind IPC) - MCP's are too noisy for LLM's to be useful long-term, as they require a server. - You don't need an MCP, you need an easy accessible API with simple DX that the machine can use with as little context and decision making as required. - Skills are better than MCP because they basically encode the API docs/context in an LLM friendly manner. No need to run servers, just push text to system prompt.
Source?
https://developer.atlassian.com/cloud/acli/guides/introducti...
It has a pretty discoverable cli syntax (at least for Claude). I use it in my custom skills to pull Jira story info when creating and reviewing specs.
I don’t think that CLIs are the path forward either, but you certainly don’t have to teach a model how to use them. We’ve made internal CLIs that adhere to no best practices and expose limited docs. Models since 4o have used them with no issue.
The amount of terminal bench data is just much higher and more predictable in rl environments. Getting a non thinking model to use an MCP server, even hosted products, is an exercise in frustration compared to exposing a cli.
A lot of our work is over voice, and I’ve found zero MCPs that I haven’t immediately wanted to wrap in a tool. I’ve actually had zero MCPs perform at all (most recently last week with a dwh MCP and opus 4.6, where even the easiest queries did not work at all).
Sure, if I want my agents to use naked curl on the CLI, they need to know secrets. But that's not how I build my tools.
But I agree with the author on custom CLI tooling. I don’t want to install another opaque binary on my machine just to call some API endpoints.
How would MCP help you if the API does not support keys?
But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?
You ARE running your agents in containers, right?
They're using ChatGPT, Gemini, or Claude on the web.
Furthermore, In many cases some APIs, for better or worse, are not even sufficient. For example, the Notion MCP has full text search capabilities. Their API allows searching by title only. I don't know why but I am sure there are reasons.
MCP looks redundant until you start working with real users that don't know a thing about AI agents, programming and security.
- easy tool calling for the LLM rather than having to figure out how to call the API based on docs only. - authorization can be handled automatically by MCP clients. How are you going to give a token to your LLM otherwise?? And if you do, how do you ensure it does not leak the token? With MCP the token is only usable by the MCP client and the LLM does not need to see it. - lots more things MCP lets you do, like bundle resources and let the server request off band input from users which the LLM should not see.
"MCPs needs to implement stateful behavior" - also doesn't make any sense. Why would an MCP need to implement stateful behavior? It is essentially just an API for agents to use.
MCP is more for a back and forth communication between agent and app/service, or for providing tool/API awareness during other tasks. Like MCP for Jira would let the AI know it can grab tickets from Jira when needed while working on other things.
I guess it's more like: the MCP isn't for us - it's for the agent to decide when to use.
I encountered a similar scenario using Atlassian MCP recently, where someone needed to analyse hundreds of Confluence child pages from the last couple of years which all used the same starter template - I gave the agent a tool to let it call any other tool in batch and expose the results for subsequent tools to use as inputs, rather than dumping it straight into the context (e.g. another tool which gives each page to a sub-agent with a structured output schema and a prompt with extraction instructions, or piping the results into a code execution tool).
It turned what would have been hundreds of individual tool calls filling the context with multiple MBs of raw confluence pages, into a couple of calls returning relevant low-hundreds of KBs of JSON the agent could work further with.
Now let's say you want all your Claude Code sessions to use this calendar app so that you can always say something like "ah yes, do I have availability on Saturday for this meeting?" and the AI will look at the schedule to find out.
What's the best way to create this persistent connection to the calendar app? I think it's obviously an MCP server.
In the calendar app I provide a built-in MCP server that gives the following tools to agents: read_calendar, and update_calendar. You open Claude Code and connect to the MCP server, and configure it to connect to the MCP for all sessions - and you're done. You don't have to explain what the calendar app is, when to use it, or how to use it.
Explain to me a better solution.
what i see is that you give it a pass manager, it thinks, "oh, this doesn't work. let me read the password" and of course it sends it off to openai.
Although, I think MCP is not really appropriate for this either. (And frankly I don't think chatbots make for good UX, but management sure likes them.)
Kerberos, OAuth, Basic Auth (username/password), PKI. MCP can be a wrapper (like any middleware).
> But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?
If the cli can access the secrets, the agent can just reverse it and get the secret itself.
> You ARE running your agents in containers, right?
Do you inject your keys into the container?
In today's day and age, it's absurdly easy to create a proxy API for your API that only exposes a subset of operations. And not like other "easy" things which depend on them having done "the right thing" before, like OpenAPI specs, auth scoping etc. This is so easy, even corporations consider it easy, and everything there is a PITA.
This is simple to make, to document and since it's a proxy you're also able to include all bunch of LLM friendly shenanigans and overly verbal errors with suggestions to fix.
Shit, I should obviously make a SaaS for this, huh?
TL;DR: The AI space is pushing hard for “Skills” as the new standard for giving LLMs capabilities, but I’m not a fan. Skills are great for pure knowledge and teaching an LLM how to use an existing tool. But for giving an LLM actual access to services, the Model Context Protocol (MCP) is the far superior, more pragmatic architectural choice. We should be building connectors, not just more CLIs.
Maybe it’s an artifact of spending too much time on X, but lately, the narrative that “MCP is dead” and “Skills are the new standard” has been hammered into my brain. Everywhere I look, someone is celebrating the death of the Model Context Protocol in favor of dropping a SKILL.md into their repository.
I am a very heavy AI user. I use Claude Code, Codex, and Gemini for coding. I rely on ChatGPT, Claude, and Perplexity almost every day to manage everything from Notion notes to my DEVONthink databases, and even my emails.
And honestly? I just don’t like Skills.
I hope MCP sticks around. I really don’t want a future where every single service integration requires a dedicated CLI and a markdown manual.
Here’s why I think the push for Skills as a universal solution is a step backward, and why MCP still gets the architecture right.

Claude pulling recent user feedback from Kikuyo through the Kikuyo MCP, no CLI needed.
The core philosophy of MCP is simple: it’s an API abstraction. The LLM doesn’t need to understand the how; it just needs to know the what. If the LLM wants to interact with DEVONthink, it calls devonthink.do_x(), and the MCP server handles the rest.
This separation of concerns brings some unbeatable advantages:
npx -y or uv can auto-update on every launch.Not all Skills are the same. A pure knowledge skill (one that teaches the LLM how to format a commit message, write tests a certain way, or use your internal jargon) actually works well. The problems start when a Skill requires a CLI to actually do something.
My biggest gripe with Skills is the assumption that every environment can, or should, run arbitrary CLIs.
Most skills require you to install a dedicated CLI. But what if you aren’t in a local terminal? ChatGPT can’t run CLIs. Neither can Perplexity or the standard web version of Claude. Unless you are using a full-blown compute environment (like Perplexity Computer, Claude Cowork, Claude Code, or Codex), any skill that relies on a CLI is dead on arrival.
This leads to a cascade of annoying UX and architectural problems:
.env file you can dump plain-text secrets into. Some ephemeral environments wipe themselves, meaning your CLI works today but forgets your secrets tomorrow.npx skills, but that only works in Codex and Claude Code, not Claude Cowork or standard Claude. Pure knowledge skills work in Claude, but most others don’t. Some tools support a “skills marketplace,” others don’t. Some can install from GitHub, others can’t. You try to install an OpenClaw skill into Claude and it explodes with YAML parsing errors because the metadata fields don’t match.SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs. It’s like forcing someone to read the entire car’s owner’s manual when all they want to do is call car.turn_on().If a Skill’s instructions start with “install this CLI first,” you’ve just added an unnecessary abstraction layer and extra steps. Why not just use a remote MCP instead?

Codex pulling up a pure knowledge skill to learn how Phoenix colocated hooks work. No CLI, no MCP, just context.
I don’t want Skills to become the de facto way to connect an LLM to a service. We can explain API shapes in a Skill so the LLM can curl it, but how is that better than providing a clean, strongly-typed interface via MCP?
Here’s how I think the ecosystem should look:
When to use MCP: MCP should be the standard for giving an LLM an interface to connect to something: a website, a service, an application. The service itself should dictate the interface it exposes.
gcal CLI is fine. The problem is a Skill that tells the LLM to install it, manage auth tokens, and shell out to it. An OAuth-backed remote MCP owned by Google handles all of that at the protocol level, and works from any client without any setup.chrome-cli.step() is infinitely better than a separate hopper-cli.mcp.notion.so/mcp available natively, instead of forcing me to download notion-cli and manage auth state manually. (They actually do have a remote MCP now, which is exactly the right call.)When to use Skills: Skills should be “pure.” They should focus on knowledge and context.
.claude/skills folder that teaches the LLM how to use tools I already have installed. A skill explaining how to use curl, git, gh, or gcloud makes complete sense. We don’t need a “curl MCP”. We just need to teach the LLM how to construct good curl commands. However, a dedicated remote GitHub MCP makes much more sense for managing issues than relying on a gh CLI skill.fnox for this repo, here is how to use it” just makes sense. Every time we deal with secrets, Claude pulls up the skill. That’s way better than building a custom MCP just to call get_secret().
Skills living directly in the repo. The LLM picks them up automatically when working in that project.
Shower thought: Maybe the terminology is the problem. Skills should just be called LLM_MANUAL.md, and MCPs should be called Connectors.
Both have their place.
For the services I own, I already do this. A few examples:
mcp.microfn.dev so any MCP-capable client can use it out of the box.mcp.kikuyo.dev.mcp.mcpnest.dev/mcp. Built it because I kept wanting remote access to local MCPs without exposing my machine directly.For microfn and Kikuyo I also published Skills, but they cover the CLI, not the MCP. That said, writing this made me realize: a skill that explains how to use an MCP server actually makes a lot of sense. Not to replace the MCP, but to give the LLM context before it starts calling tools. What the service does, how the tools relate to each other, when to use which one. A knowledge layer on top of a connector layer. That’s the combination I’d want.
And this is actually a pattern I’ve been using more and more in practice. When I’m working with a MCP server, I inevitably discover gotchas and non-obvious patterns: a date format that needs to be YYYY-MM-DD instead of YYYYMMDD, a search function that truncates results unless you bump a parameter, a tool name that doesn’t do what you’d expect. Rather than rediscovering these every session, I just ask Claude to wrap everything we learned into a Skill. The LLM already has the context from our conversation, so it writes the Skill with all the gotchas, common patterns, and corrected assumptions baked in.

After discovering backlink gotchas and date format quirks in the NotePlan MCP, I asked Claude to package everything into a skill. Now every future session starts with that knowledge.
The result is a Skill that acts as a cheat sheet for the MCP, not a replacement for it. The MCP still handles the actual connection and tool execution. The Skill just makes sure the LLM doesn’t waste tokens stumbling through the same pitfalls I already solved. It’s the combination of both that makes the experience actually smooth.
At the same time, I’ll keep maintaining my dotfiles repo full of Skills for procedures I use often, and I’ll keep dropping .claude/skills into my repositories to guide the AI’s behavior.
I just hope the industry doesn’t abandon the Model Context Protocol. The dream of seamless AI integration relies on standardized interfaces, not a fractured landscape of hacky CLIs. I’m still holding out hope for official Skyscanner, Booking.com, Trip.com, and Agoda.com MCPs.
My two cents.
Speaking of remote MCPs: I built MCP Nest specifically for this problem. A lot of useful MCP servers are local-only by nature, think Fastmail, Gmail, or anything that runs on your machine. MCP Nest tunnels them through the cloud so they become remotely accessible, usable from Claude, ChatGPT, Perplexity, or any MCP-capable client, across all your devices. If you want your local MCPs to work everywhere without exposing your machine directly, that’s what it’s for.
Where I DO see MCPs getting actual use is when the auth story for something (looking at you slack, gmail, etc) is so gimped out that basically, regular people can't access data via CLI in any sane or reasonable way. You have to do an oauth dance involving app approvals that are specifically designed to create a walled garden of "blessed" integrations.
The MCP provider then helpfully pays the integration tax for you (how generous!) while ensuring you can't do inconvenient things like say, bulk exporting your own data.
As far as I can tell, that's the _actual_ sweet spot for MCPs. They're sort of a technology of control, providing you limited access to your own data, without letting you do arbitrary compute.
I understand this can be considered a feature if you're on the other side of the walled garden, or you're interested in certain kinds of enterprise control. As a programmer however I prefer working in open ecosystems where code isn't restricted because it's inconvenient to someone's business model.
It's not a choice between Skills or MCP, you can also just create your own tools, in whatever language you want, and then send in the tool info to the model. The wiring is trivial.
I write all my own tools bespoke in Rust and send them directly to the Anthropic API. So I have tools for reading my email, my calendar, writing and search files etc. It means I can have super fast tools, reduce context bloat, and keep things simple without needing to go into the whole mess of MCP clients and servers.
And btw, I wrote my own MCP client and server from the spec about a year ago, so I know the MCP spec backwards and forwards, it's mostly jank and not needed. Once I got started just writing my own tools from scratch I realised I would never use MCP again.
tool --help
tool subcommand1 --help
tool subcommand2 --help
man tool | grep "thing I care about"
As for stateful behavior, say you have the google docs or email mcp. You want to search org-wide for docs or emails that match some filter, make it a data set, then do analysis. To do this with MCP, the model has to write the files manually after reading however many KB of input from the MCP. With a cli it's just "tool >> starting_data_set.csv"
What it can do it call multiple MCPs, dumping tons of crap into the context and then separately run some analysis on that data.
Composable MCPs would require some sort of external sandbox in which the agent can write small bits of code to transform and filter the results from one MCP to the next.
So I guess you had to modify the agent harness to do this? or I guess you could use... mcp-cli ... ??
Then, the minimal skill descriptions are always in the model's context, and whenever you ask it to add something to the calendar, it will know to fetch that skill. It feels very similar to the MCP solution to me, but with potentially less bloat and no obligation to deal with MCP? I might be missing something, though.
The story for MCP just makes no sense, especially in an enterprise.
You absolutely DO want to run everything related to LLMs in a sandbox, that's basic hygiene
What do you mean by this? How "reverse it"? The CLI tool can access the secure storage, but that does not mean there is any CLI interface in the tool for the LLM to call and get the secret printed into the console.
You can implement progressive disclosure in MCP as well by implementing those same help commands as tools. The MCP should not be providing thousands of tools, but the minimum set of tools to help the AI use the service. If your service is small, you can probably distill the entire API into MCP tools. If you're AWS then you provide tools that then document the API progressively.
Technically, you could have an AWS MCP provide one tool that guides the AI on how to use specific AWS services through search/keywords and some kind of cursor logic.
The entire point of MCP is inherent knowledge of a tool for agentic use.
Isn't the same true of filtering tools available thru mcp?
The mcp argument to me really seems like people arguing about tabs and spaces. It's all whitespace my friends.
I implemented this in an agent which runs in the browser (in our internal equivalent of ChatGPT or Claude's web UI), connecting directly to Atlassian MCP.
Essentially you give the agent a way to run code that calls MCP servers, then it can use them like any other API.
Nowadays small bash/bun scripts and an MCP gateway proxy gets me the same exact thing.
So yeah at some level you do have to build out your own custom functionality.
We could use suid binaries (e.g. sudo) to prevent that, but currently I don't think we can. Most anyone would agree that using a separate process, for which the agent environment provides a connection, is a better solution.
Connected MCP tools are also always in the model's context, and it works for any AI agent that supports MCP, not just Claude Code.
So does an API and a text file (or hell, a self describing api).
Which is more complex and harder to maintain, update and use?
This is a solved problem.
The world doesnt need MCP to reinvent a solution to it.
If we’re gonna play the ELI5 game, why does MCP define a UI as part of its spec? Why does it define a bunch of different resource types of which only tools are used by most servers? Why did not have an auth spec at launch? Why are there so many MCP security concerns?
These are not idle questions.
They are indicative of the “more featurrrrrres” and “lack of competence” that went into designing MCP.
Agents, running a sandbox, with normal standard rbac based access control or, for complex operations standard stateful cli tooling like the azure cli are fundamentally better.
MCP is basically just an RPC API that uses HTTP and JSON, with some other features useful for AI agents today.
Self-describing APIs require probing through calls, they don't tell you what you need to know before you interact with them.
MCP servers are very simple to implement, and the developers of the app/service maintain the server so you don't have to create or update skills with incomplete understanding of the system.
Your skill file is going to drift from the actual API as the app updates. You're going to have to manage it, instead of the developers of the app. I don't understand what you're even talking about.
That sounds great. How about we standardize this idea? We can have an endpoint to tell the agents where to find this text file and API. Perhaps we should be a bit formal and call it a protocol!
…
> Let's say I made a calendar app that stores appointments for you. It's local, installed on your system,
> and the developers of the app/service maintain the server so you don't have to create or update skills
…
> I don't understand what you're even talking about.
You certainly do not.
Good news! It's already standardized and agents already know where to find it!
If you use the official MCP SDK, it has interfaces you implement for auth, so all you need to do is kick off the OAuth flow with a URL it figures out and hands you, storing the resulting tokens and producing them when requested. It also handles using refresh tokens, so there's just a bit of light friendly owl finishing on top.
Source: I just implemented this for our (F100) internal provider and model agnostic chat app. People can't seem to see past the coding agents they're running on their own machines when MCP comes up.