HN

Comments (187)

• Menu

  antirez
  Don't focus on what you prefer: it does not matter. Focus on what tool the LLM requires to do its work in the best way. MCP adds friction, imagine doing yourself the work using the average MCP server. However, skills alone are not sufficient if you want, for instance, creating the ability for LLMs to instrument a complicated system. Work in two steps: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.
• Menu

  tow21
  This argument always sounds like two crowds shouting past each other.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.
• Menu

  plandis
  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.
• Menu

  alierfan
  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.
• Menu

  _pdp_
  Scanning through the comments here I am almost certain the majority of people in this thread run coding agents on-device. Skills that access already available resources is then more convenient and you can easily make the argument that it is more agronomic.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.
• Menu

  lifeisstillgood
  I agree for a slightly different reason - human stupidity.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 throughJust 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 blockedReports 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
• Menu

  grensley
  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.
• Menu

  nextaccountic
  > Context Bloat: 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. 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().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 elseA 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
• alexhans
  This frames MCP vs Skills as an either/or, but they operate at different layers. MCP exposes capabilities and Skills may shape how capabilities are used.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...
• Menu

  usrbinbash
  > 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.Wrong. It needs to "understand" both these things. The only difference is where and how the strings explaining them are generated.
• kohlerm
  Yeah well. MCPs are better for use cases where remote access is required, but for development use cases what you need in the majority of use cases is to manipulate local files. Skills are just the more natural solution here. You can argue whether Skills should come with more type information (MCPs are slightly better here), but otherwise it seems pretty clear to me that if you do not need remote access then MCPs are not really needed.
• rd42
  I think the key problem is that usage of MCP servers is not 'baked' into the LLM training - but API's and CLI's are already a part of training. So to use your MCP server, the LLM has to use additional intelligence which could have been used to do the actual work instead.
• qrbcards
  The comparison to app stores is interesting but I think MCP registries solve a different problem. App stores are for humans browsing. MCP registries are for agents discovering tools at runtime based on the task at hand. The user never browses — they describe what they need and the agent finds the tool.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.
• pjmlp
  Complete in synch with the author MCP and A2A for the win.
• Menu

  robotobos
  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.
• alienbaby
  Different techniques appropriate in different situations, I would decide on what's appropriate given the goals you have. Whichg is nearly always the answer to X is a better way than Y arguments.
• Menu

  Aperocky
  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.
• chris_money202
  I think the worse thing is when someone takes a clearly defined list of steps to do something and writes it as a skill rather than just having AI write it as a script. It’s like people have forgot what scripting is
• TonyAlicea10
  I prefer peanut butter over jelly.
• imron
  My biggest gripe with skills is that even clear and explicit instructions are regularly ignored - even when the skill is brief (< 100 lines).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”
• Menu

  anshulbhide
  >>>The core philosophy of MCP is simple: it’s an API abstraction.That's exactly the problem. As agents become better and can read API documentation themselves, WHY do you need an API abstraction?
• s-xyz
  I never understood why there is a discussion about it, one or the other… both serve a different purpose and are complementary.
• anon
  undefined
• throwpoaster
  They’re different things. You can have skills using MCP.
• lewisjoe
  > 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?
• ghm2199
  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?
• rakamotog
  There is one area where MCP typically has challenges - Not a technical challenge but a practical challenge.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.
• tomaytotomato
  As others have said I have found CLI tools much betterThis 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
• mantyx
  Having developed mantyx.io, I believe that rest apis are still champion. MCP is nothing more than rest wrappers most of the time and skills are cli wrappers which in turn are rest wrappers.
• choam2426
  This tracks with my experience.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.
• Xenoamorphous
  I use both and don't feel they're mutually exclusive.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.
• raincole
  Seriously, the only drawback of MCP is its name. If it were named "API discovery protocol" (which is what it is) none of these debates would have existed.API vs MCP sounds like a real debate, but it really isn't. It's "API vs API discovery protocol." See how asinine it sounds if we call things for what they are.
• michaelashley29
  100% MCPs truly give the agent tools and allow the agent to make better informed decisions given you can have configured the right MCP tools. Skills are good for knowledge and general guidelines. They give context to the agent, and I have seen some skills being excessively long that could into eat into the context window of the agent. This tool https://protomcp.io/ helps a lot with testing MCP servers before integrating into the agent workflow. You can even see the agent call different tools in real time and view the trace.
• leonidasv
  This is the same as saying "I still prefer hammer over screwdriver".
• mememememememo
  Like saying I prefer websites over CLI, or bicycles over canoes. Chisels over planes. Depends what you are trying to achieve.
• Menu

  woeirua
  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.
• fedeb95
  I think both will stick around because they solve two different problems. 1) what are you able to do (skills) 2) which tools you have to do it (mcp)
• bachback
  the best agent framework in my opinion is Pi. Pi avoids MCP thats a good thing. why assume that the planet will migrate from HTTP to MCP? no, instead lets assume we have client code we can call. we already have a rich ecosystem of HTTP services and packages. and if we assume a rewrite for agents we probably wouldn't come up with MCP but something more powerful.
• qalmakka
  CLI is massively superior to MCP in my experience. First, because I also understand what's going on and do it myself if necessary. Second because it's so much cheaper in terms of tokens it's not even funny
• ok_dad
  People in the comments still confused about “agentic development” vs. “agentic development”. One uses the cli best, while the other cannot use a cli very well.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.
• Menu

  medbar
  I still use vanilla Claude Code without MCP or skills, am I in the minority? Not trying to be a luddite.
• nodomain
  The whole article serves just to promote his SaaS.
• pjmalandrino
  Not same tools, different purpose from my opinion
• baq
  Remote MCP solve the delivery and update issues just like saas and browsers did for human users. Not much more to it really
• Menu

  turlockmike
  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
• slhck
  Huh, I think the author might be deliberately ignoring how MCP works?- "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.
• nathias
  MCP is too thristy
• heckintime
  AI tools for non technical users that can work on browsers and mobile app will be super powerful. I think MCPs are currently the best way to reach this audience.
• Menu

  latentsea
  Different tools for different jobs man... I prefer the right tool for the job, and both skills and MCP seem necessary. Do you also prefer forks over spoons?
• Menu

  bijowo1676
  MCP pollutes the context, if you dont care about wasting context token for all MCP tools, go ahead and use MCP, but you should know that cli tool+skill can perfectly replace it with less token overhead and better matching due to skill's front matter
• nout
  Use both. These do different things.
• jauntywundrkind
  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-mcpI'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.
• EugeneOZ
  > 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 superiorThat's it. For some things you need MCP, for some things you need SKILLs - these things coexist.
• avinashselvam
  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.
• seyz
  MCP versus Skills -> wrong debate. MCP versus CLI -> real debate.
• contextbloat
  > 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.Isn't this, like, the exact thing MCP is the worst at? You need to load the entire MCP into the context even if you're not using the MCP's relevant functions. Which is why some people put them on subagents, which is like, equivalent to putting the MCP behind a CLI function, at which point, why not just have the CLI function and selectively load it when yo- OH WAIT, THERE'S A NAME FOR THAT!
• ai_slop_hater
  I still prefer apples over oranges
• polyterative
  why not both
• tpoacher
  > 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.There's your answer. If you want to use local tools, use Skills. If you want to use services, use MCP. Or, you know, whatever works best for your scenario.
• simianwords
  Yesterday I accidentally stumbled on a place where I could really appreciate MCP's.I wanted to connect my Claude account to my Notion account. Apparently all you need to do is just submit the notion MCP and log in. That's it! And I was able to interact with my Notion data from my Claude account!Imagine how hard this would be with skills? It is literally impossible because with skills, you may need to install some local CLI which Claude honestly should not allow.If not CLI, you need to interact with their API which again can't happen because you can't authenticate easily.MCP's fill this narrow gap in my opinion - where you don't own the runtime and you want to connect to other tools like plugins.
• simianwords
  SKILLS.md or AGENTS are good concepts but they miss two crucial things that will make them much more usable. I predict that this will happen.Each SKILLS.md will come with two hooks:1. first for installing the SKILL itself - maybe install the CLI or do some initial work to get it working2. Each skill may have dependencies on other skills - we need to install those firstExpressing these two hooks in a formal way in skills would help me completely replace MCP's.My concrete prediction is that this will happen soon.Wrote more about it here: https://simianwords.bearblog.dev/what-agent-skills-misses-no...
• lukewarm707
  i feel like giving an agent shell access and internet is batshit crazy.that's just me i guess.
• Menu

  senordevnyc
  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.
• Menu

  charcircuit
  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.
• lyime
  auth
• 0xy4sh
  [dead]
• techpulselab
  [dead]
• spotlayn
  [dead]
• edinetdb
  [dead]
• ajaystream
  [dead]
• aiedwardyi
  [dead]