I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP.
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.
I keep getting hung up on securely storing and using secrets with CLI vs MCP. With MCP, you can run the server before you run the agent, so the agent never even has the keys in its environment. That way. If the agent decides to install the wrong npm package that auto dumps every secret it can find, you are less likely to have it sitting around. I haven’t figured out a good way to guarantee that with CLIs.
A CLI can just be a RPC call to a daemon, exact same pattern apply. In fact my most important CLI based skill are like this.. a CLI by itself is limited in usefulness.
Ok, but there are still many environments where an LLM will not have access to a CLI. In those situations, skills calling CLI tools to hook into APIs are DOA.
What are the advantages of using an environment that doesn't have access to a CLI, only having to run/maintain your own server, or pay someone else to maintain that server, so AI has access to tools? Can't you just use AI in the said server?
Obvious example is a corporate chatbot (if it's using tools, probably for internal use). Non-technical users might be accessing it from a phone or locked-down corporate device, and you probably don't want to run a CLI in a sandbox somewhere for every session, so you'd like the LLM to interface with some kind of API instead.
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.)
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.
This isn't a zero-sum game or a choice of one over the other. They solve different layers of the developer experience: MCP provides a standardized, portable interface for external data/tools (the infrastructure), while Skills offer project-specific, high-level behavioral context (the orchestration). A robust workflow uses MCP to ensure tool reliability and Skills to define when and how to deploy those tools.
I think many of us have been burned by the absolutely awful and unstable JIRA MCP and found that skills using `acli` actually work and view the rest of the MCP space thru that lens. Lots of early - and current! - MCP implementations were bad. So it’s an uphill battle to rebuild reputation.
I built an internal company MCP that uses Google Workspace auth and injects a mix of guidance (disguised as tools) on how we would like certain tasks to be accomplished via Claude as well as API-like capabilities for querying internal data and safely deploying small apps internally.
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.
I've started thinking of these systems as legacy systems. We have them. They are important and there's a lot of data in them. But they aren't optimal any more.
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.
Despite thinking this is AI-generated, I agree but everything has a caveat.
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.
If the model can figure it out with tokens, but my institutional knowledge MCP tool can do it with a few CPU cycles, it’s faster and deterministic and repeatable.
> Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge.
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?
For indie developers like myself, I often use chat GPT desktop and Claude desktop for arbitrary tasks, though my main workhorse is a customized coding harness with CC daemons on my nas. With the apps, b I missed having access to my Nas server where my dev environment is. So I wrote a file system MCP and hosted it with a reverse proxy on my Truenas with auth0. I wanted access to it from all platforms CharGPT mobile, desktop. Same for CC.
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?
Anthropic says that Skills and MCPs are complementary, and frankly the pure Skills zealots tend to miss that in enterprise environments you’ll have chatbots or the like that don’t have access to a full CLI. It doesn’t matter if your skills tell the agent exactly what to do if they can’t execute the commands. Also, MCP is better for restricted environments because you know exactly what it can or cannot do. That’s why MCP will exist for some time still. They solve distinct problem sets.
I've remained leaning a bit towards MCP until lately. Both have pretty easy ways to call the other (plenty of cli API callers, and tools like mcp-cli for the reverse https://github.com/philschmid/mcp-cli). Skills have really made progressive discovery if cli-tools much better, and MCP design has adapted likewise. I've lightly preferred MCP for formalism, for it feeling more concrete as a thing.
But what really changed my mind is seeing how much more casual scripting the LLMs do these days. They'll build rad unix pipes, or some python or node short scripts. With CLI tools, it all composes: every trick it learns can plug directly into every other capability.
Where-as with MCP, the LLM has to act as the pipe. Tool calls don't compose! It can read something like this tmux skill then just adapt it in all sorts of crazy ways! It can sort of do that with tool calls, but much less so. https://github.com/nickgnd/tmux-mcp
I'd love to see a capnproto capnweb or some such, with third party handoff (apologies Kenton for once again raising 3ph), where a tool call could return a result and we could forward the result to a different LLM, without even waiting for the result to come back. If the LLM could compose tool calls, it would start to have some parity with the composability of the cli+skill. But it doesn't. And as of very recently I've decided that is too strong a selling point to be ignored. I also just like how the cli remains the universe system: if these are so isomorphic as I keep telling myself, what really does the new kid on the block really bring? How much is a new incarnation better if their capabilities are so near? We should keep building cli tools, good cli tools, so that man and machine benefit.
That said I still leave the beads mcp server around. And I turn on the neovim MCP when I want to talk to neovim. Ah well. I should try harder to switch.
I love the idea of MCP, but it needs a progressive disclosure mechanism. A large MCP from a provider with hundreds or even thousands of tools can eat up a huge amount of your context window. Additionally, MCPs come in a bunch of different flavors in terms of transport and auth mechanisms, and not all harnesses support all those options well.
I’ve gone the other way, and used MCP-CLI to define all my MCP servers and wrap them in a CLI command for agent use. This lets me easily use them both locally and in cloud agents, without worrying about the harness support for MCP or how much context window will be eaten up. I have a minimal skill for how to use MCP-CLI, with progressive disclosure in the skill for each of the tools exposed by MCP-CLI. Works great.
All that said, I do think MCP will probably be the standard going forward, it just has too much momentum. Just need to solve progressive disclosure (like skills have!) and standardize some of the auth and transport layer stuff.
I thought Claude Code and others do progressive disclosure for MCP now as well.
The article claims so:
> Smart Discovery: Modern apps (ChatGPT, Claude, etc.) have tool search built-in. They only look for and load tools when they are actually needed, saving precious context window.
This author does not realize that skills can call APIs. The idea that you have to build dedicated CLI apps is not true at all and invalidates the entire article.
Can you clarify what exactly you mean? Skills are markdown files, so they definitely can't call APIs or CLIs. Are you saying that a skill can tell the agent to use curl to call web APIs? Or something different?
Technically they can at least how I'm using or abusing them - I ride windows so they have a generic powershell script bolted on to handle special API use through the skill to make it easier for the agent to call data up noted in the skill. does it lack full API details? absolutely. I have also a learning skill where if it has to go for a think / fail / try to figure something new out to grow a new skill or update an existing one.
skills to me suck when they are shared with a team - haven't found the secret sauce here to keep these organic skills synced between everyone
I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP.
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.
I keep getting hung up on securely storing and using secrets with CLI vs MCP. With MCP, you can run the server before you run the agent, so the agent never even has the keys in its environment. That way. If the agent decides to install the wrong npm package that auto dumps every secret it can find, you are less likely to have it sitting around. I haven’t figured out a good way to guarantee that with CLIs.
A CLI can just be a RPC call to a daemon, exact same pattern apply. In fact my most important CLI based skill are like this.. a CLI by itself is limited in usefulness.
Ok, but there are still many environments where an LLM will not have access to a CLI. In those situations, skills calling CLI tools to hook into APIs are DOA.
What are the advantages of using an environment that doesn't have access to a CLI, only having to run/maintain your own server, or pay someone else to maintain that server, so AI has access to tools? Can't you just use AI in the said server?
Obvious example is a corporate chatbot (if it's using tools, probably for internal use). Non-technical users might be accessing it from a phone or locked-down corporate device, and you probably don't want to run a CLI in a sandbox somewhere for every session, so you'd like the LLM to interface with some kind of API instead.
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.)
Why are they not calling APIs directly with strictly defined inputs and outputs like every other internal application?
The story for MCP just makes no sense, especially in an enterprise.
MCP is an API with strictly defined inputs and outputs.
The advantage is that I can have it in my pocket.
idk, just have a standard internet request tool that skills can describe endpoints to. like you could mock `curl` even for the same CLI feel
skills can have code bundled with them, including MCP code
People in the comments still confused about “agentic development” vs. “agentic development”. One uses the cli best, while the other cannot use a cli.
The first is using agents locally to develop.
The second is developing an agent.
They are different cases, MCP is great for the latter.
Occams Razor spares none.
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.
This isn't a zero-sum game or a choice of one over the other. They solve different layers of the developer experience: MCP provides a standardized, portable interface for external data/tools (the infrastructure), while Skills offer project-specific, high-level behavioral context (the orchestration). A robust workflow uses MCP to ensure tool reliability and Skills to define when and how to deploy those tools.
The "only skills" people are usually non-technical and the "only CLI" people are often solo builders.
MCP makes a lot of sense for enterprise IMO. Defines auth and interfaces in a way that's a natural extension of APIs.
I think many of us have been burned by the absolutely awful and unstable JIRA MCP and found that skills using `acli` actually work and view the rest of the MCP space thru that lens. Lots of early - and current! - MCP implementations were bad. So it’s an uphill battle to rebuild reputation.
I built an internal company MCP that uses Google Workspace auth and injects a mix of guidance (disguised as tools) on how we would like certain tasks to be accomplished via Claude as well as API-like capabilities for querying internal data and safely deploying small apps internally.
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.
I've started thinking of these systems as legacy systems. We have them. They are important and there's a lot of data in them. But they aren't optimal any more.
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.
Despite thinking this is AI-generated, I agree but everything has a caveat.
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.
> Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge.
Maybe I'm misinterpreting you, but can you explain this more? I've been using skills for repeatable tasks. Why an MCP instead?
If the model can figure it out with tokens, but my institutional knowledge MCP tool can do it with a few CPU cycles, it’s faster and deterministic and repeatable.
> Skills are good for instilling non-repeatable, yet intuitive or institutional knowledge.
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.)
You could hardcode the script as a file within a skill too right? Skills can contain code, not just markdown files.
For indie developers like myself, I often use chat GPT desktop and Claude desktop for arbitrary tasks, though my main workhorse is a customized coding harness with CC daemons on my nas. With the apps, b I missed having access to my Nas server where my dev environment is. So I wrote a file system MCP and hosted it with a reverse proxy on my Truenas with auth0. I wanted access to it from all platforms CharGPT mobile, desktop. Same for CC.
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?
Or use both. Remote MCPs are secure, CLI allows for programmatic execution. Use bash to run remote MCPs.
I built this to solve this exact problem. https://github.com/turlockmike/murl
What about remote MCPs lend themselves to security? For instance, do you think that it is more secure than a traditional endpoint?
This is the same as saying "I still prefer hammer over screwdriver".
Anthropic says that Skills and MCPs are complementary, and frankly the pure Skills zealots tend to miss that in enterprise environments you’ll have chatbots or the like that don’t have access to a full CLI. It doesn’t matter if your skills tell the agent exactly what to do if they can’t execute the commands. Also, MCP is better for restricted environments because you know exactly what it can or cannot do. That’s why MCP will exist for some time still. They solve distinct problem sets.
Use both. These do different things.
skills and mcp help with entirely different things. sure most products add a skill on using their mcp so that model's tool calling works good.
I've remained leaning a bit towards MCP until lately. Both have pretty easy ways to call the other (plenty of cli API callers, and tools like mcp-cli for the reverse https://github.com/philschmid/mcp-cli). Skills have really made progressive discovery if cli-tools much better, and MCP design has adapted likewise. I've lightly preferred MCP for formalism, for it feeling more concrete as a thing.
But what really changed my mind is seeing how much more casual scripting the LLMs do these days. They'll build rad unix pipes, or some python or node short scripts. With CLI tools, it all composes: every trick it learns can plug directly into every other capability.
Where-as with MCP, the LLM has to act as the pipe. Tool calls don't compose! It can read something like this tmux skill then just adapt it in all sorts of crazy ways! It can sort of do that with tool calls, but much less so. https://github.com/nickgnd/tmux-mcp
I'd love to see a capnproto capnweb or some such, with third party handoff (apologies Kenton for once again raising 3ph), where a tool call could return a result and we could forward the result to a different LLM, without even waiting for the result to come back. If the LLM could compose tool calls, it would start to have some parity with the composability of the cli+skill. But it doesn't. And as of very recently I've decided that is too strong a selling point to be ignored. I also just like how the cli remains the universe system: if these are so isomorphic as I keep telling myself, what really does the new kid on the block really bring? How much is a new incarnation better if their capabilities are so near? We should keep building cli tools, good cli tools, so that man and machine benefit.
That said I still leave the beads mcp server around. And I turn on the neovim MCP when I want to talk to neovim. Ah well. I should try harder to switch.
I still prefer apples over oranges
I love the idea of MCP, but it needs a progressive disclosure mechanism. A large MCP from a provider with hundreds or even thousands of tools can eat up a huge amount of your context window. Additionally, MCPs come in a bunch of different flavors in terms of transport and auth mechanisms, and not all harnesses support all those options well.
I’ve gone the other way, and used MCP-CLI to define all my MCP servers and wrap them in a CLI command for agent use. This lets me easily use them both locally and in cloud agents, without worrying about the harness support for MCP or how much context window will be eaten up. I have a minimal skill for how to use MCP-CLI, with progressive disclosure in the skill for each of the tools exposed by MCP-CLI. Works great.
All that said, I do think MCP will probably be the standard going forward, it just has too much momentum. Just need to solve progressive disclosure (like skills have!) and standardize some of the auth and transport layer stuff.
I thought Claude Code and others do progressive disclosure for MCP now as well.
The article claims so:
> Smart Discovery: Modern apps (ChatGPT, Claude, etc.) have tool search built-in. They only look for and load tools when they are actually needed, saving precious context window.
auth
This author does not realize that skills can call APIs. The idea that you have to build dedicated CLI apps is not true at all and invalidates the entire article.
No, the point was that you don’t have access to a CLI in every environment.
Can you clarify what exactly you mean? Skills are markdown files, so they definitely can't call APIs or CLIs. Are you saying that a skill can tell the agent to use curl to call web APIs? Or something different?
Technically they can at least how I'm using or abusing them - I ride windows so they have a generic powershell script bolted on to handle special API use through the skill to make it easier for the agent to call data up noted in the skill. does it lack full API details? absolutely. I have also a learning skill where if it has to go for a think / fail / try to figure something new out to grow a new skill or update an existing one.
skills to me suck when they are shared with a team - haven't found the secret sauce here to keep these organic skills synced between everyone
https://agentskills.io/specification
* references/ Contains additional documentation that agents can read when needed
* scripts/ Contains executable code that agents can run.
* assets/ Contains static resources
And call MCPs as well