6 ms·

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 yoursel

by antirez 6mo ago

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.

tomaytotomato 6mo ago
Although the author is coming from a place of security and configuration being painful with Skills, I think the future will be a mix of MCP, Agents and Skills. Maybe even a more granular defined unit below a skill - a command... 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.
- senordevnyc 6mo ago
  Commands are already a thing, but they're falling out of favor because a user can just invoke a skill manually instead.
ReDeiPirati 6mo ago
> 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. 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.
prohobo 6mo ago
I feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - 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?
- pavelbuild 6mo ago
  [dead]
- xyzzy123 6mo ago
  My main complaint with mcp is that it doesn't compose well with other tools or code. Like if I want to pull 1000 jira tickets and do some custom analysis I can do that with cli or api just fine, but not mcp.
  - prohobo 6mo ago
    Right, that feels like something you'd do with a script and some API calls. 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.
    - 6mo ago
eblair 6mo ago
[dead]
siva7 6mo ago
> MCP adds friction, imagine doing yourself the work using the average MCP server. 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.
- _pdp_ 6mo ago
  I won't be surprised if MCP start shipping skills. They already ship prompts and other things exposed as resources. It is not even difficult to do with the current draft as skills can be exposed by convention without protocol changes. Future version of the protocol can easily expose skills so that MCPs can acts like hubs.
  - radiospiel 6mo ago
    Doesn't it already? https://modelcontextprotocol.io/specification/2025-11-25/server/prompts https://modelcontextprotocol.io/specification/2025-11-25/ser...
    - _pdp_ 6mo ago
      these are prompts - similar yes - but not the same
- insin 6mo ago
  The more things change in tech, the more they stay the same. The shoe is the sign. Let us follow His example! Cast off the shoes! Follow the Gourd!
- bavell 6mo ago
  They're complementary but also have significant overlap. Hence all the confusion and strong opinions.
- robot-wrangler 6mo ago
  > clearly don't understand either deeply No appetite for that. The MCP vs Skills debate has gradually become just a proxy war for the camps of AI skeptics vs AI boosters. Both sides view it as another chance to decide about more magic vs less, in absolute terms, without doing the work of thinking about anything situational. Nuance, questions, reasoning from first principles, focusing on purely engineering considerations is simply not welcome. The extreme factions do tend to agree that it might be a good idea to attack the middle though! There's no changing this stuff, so when it becomes tiresome it's time to just leave the HN comment section.
neya 6mo ago
> Focus on what tool the LLM requires to do its work in the best way. 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-agent-evals https://vercel.com/blog/agents-md-outperforms-skills-in-our-...
- yunwal 6mo ago
  How do you shut off particular api calls with an agents.md?
  - neya 6mo ago
    I personally use tool calling for APIs, so really not sure (I don't use agents.md per se, I directly stuff info into the context window)
BatteryMountain 6mo ago
This is exactly what I do too. Works very well. I have a whole bunch of scripts and cli tools that claude can use, most of them was built by claude too. I very rarely need to use my IDE because of this, as I've replicated some of Jetbrains refactorings so claude doens't have to burn tokens to do the same work. It also turns a 5 minute claude session into a 10 second one, as the scripts/tools are purpose made. Its reallly cool. 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.
- evanmoran 6mo ago
  This is a great idea. Did you happen to release the source for this? I run into this all the time!
  - BatteryMountain 6mo ago
    Nope, I just dump it all in a folder (~/scripts) that claude can read & it picks them up as skills. A good chunk of them are regex based, many are find/replace type tools, some are small code generators & template inflators, some are deployment tools, some are audit tools. I cannot release them at this time, most of them are specific to our company, infra and codebase (main codebase is 1MLoC), sorry about that. Start with a simple "Let me build a script for claude that can rename the namespace for all the file in a folder". If you have 100K+ plus files, it effort is worth it and your tools start getting chained together too. So make sure each tool only has one purpose for existing and that its output is perfect. So when claude start chaining them and you see what is possible, the mind opens up even more to possibilities.
- smusamashah 6mo ago
  > I've replicated some of Jetbrains refactorings How? Jetbrains in a Java code baes is amazing and very thorough on refactors. I can reliably rename, change signature, move things around etc.
  - girvo 6mo ago
gitgud 6mo ago
> For instance it does not make sense to have an MCP to use git. 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…”
- NiloCK 6mo ago
  Just as easy to write a wrapper to the tool you want to restrict. You ban the restricted tool outright, and the skill instructs on usage of the wrapper. Safer than just giving an instruction to use the tool a specific way.
- Majromax 6mo ago
  Anyone who's ever `DROP TABLE`d on a production rather than test database has encountered the same problem in meatspace. In this context, the MCP interface acts as a privilege-limiting proxy between the actor (LLM/agent) and the tool, and it's little different from the standard best practice of always using accounts (and API keys) with the minimum set of necessary privileges. It might be easier in practice to set up an MCP server to do this privilege-limiting than to refactor an API or CLI-tool, but that's more an indictment of the latter than an endorsement of the former.
the_axiom 6mo ago
this comment just assumes skills ori better without dealing with any of the arguments presented low quality troll
federicosimoni 6mo ago
[dead]
fny 6mo ago
This is covered well in the article too. See "The Right Tool for the Job" and "Connectors vs. Manuals." Perhaps the title is just clickbait. :)
richardlblair 6mo ago
I've found makefiles to be useful. I have a small skill that guides the LLM towards the makefile. It's been great for what you're talking about, but it's also a great way to make sure the agent is interacting with your system in a way you prefer.
morgaesis 6mo ago
This is my life motto. Progressive exploration, codifying, use your codified workflows. > for each desired change, make the change easy (warning: this may be hard), then make the easy change - Kent Beck https://x.com/KentBeck/status/250733358307500032 https://x.com/KentBeck/status/250733358307500032
1minusp 6mo ago
Feels to me like the toolchain for using LLMs in various tasks is still in flux (i interpret all of this as "stuff in different places like .md or skills or elsewhere that is appended to the context window" (i hope that is correct)). Shouldnt this overall process be standardized/automated? That is, use some self-reflection to figure out patterns that are then dumped into the optimal place, like a .md file or a skill?
- jpadkins 6mo ago
  too early for standardization. resist the urge. Let a bunch of ideas flow, then watch the Darwinian process of the best setup will be found. Then standardize.
- pizzafeelsright 6mo ago
  The entire tooling ecosystem is in flux. Looking forward, the future is ad-hoc disposable software that once would take a large team a dozen sprints to release. Eventually it'll be use case -> spec -> validation -> result. The tv show Stargate showed different controls that scientifically calculated and operated starships so all the operator had to do was point the controls in the direction of the destination. The ai/computer/hardware knows how to get to the result and that result is human driven. I have evidence of this at work and in my own life with the key component being the tooling integration.
jFriedensreich 6mo ago
If your llm sees even a difference between local skill and remote MCP thats a leak in your abstraction and shortcoming of the agent harness and should not influence the decision how we need to build these system for the devs and end users. They way this comment thinks about building for agents would lead to a hellscape.
- mikestorrent 6mo ago
  Do you know who you're responding to? > a difference between local skill and remote MCP A local skill is a text file with a bunch of explanations of what to do and how, and what pitfalls to avoid. An MCP is a connection to an API that can perform actions on anything. This is a pretty massive difference in terms of concept and I don't think it can be abstracted away. A skill may require an MCP be available to it, for instance, if it's written that way. Antirez' advice is what I've been doing for a year: use AI to write proper, domain-specific tools that you and it can then use to do more impressive things.
  - jFriedensreich 6mo ago
    Don't think its relevant who they are if they give advice that is based on outdated understanding of how agent harnesses are build and how to use MCP in an agent harness in the first place. You can serve agent skills via mcp or via text files accessed via local tools, if your harness makes this look different to the LLM in the end it is just a bad harness. The LLM should just see "ways to discover skills" and then "use the skills". If skills come from a folder or from an MCP is transparent implementation detail. This is more than just theoretical, if abstractions like the way skills are served leak into the context, this will measurably degrade agent performance, depending on model more or les severe!
    - mikestorrent 6mo ago
      What if the MCP needs to actually do something, like make an API call? It's nice sometimes to have those credentials out-of-band from the AI itself so it can't access them and is forced to go through the lens of tooling.
pojzon 6mo ago
This is how I work with my agent harness. Also have skills for writing tools and skills. And I still think ppl dont understand why MCPs are still needed and when to use them. Its actually pretty simple.
tehryanx 6mo ago
It makes a lot of sense to use an MCP for git and everything else if you want observability across many users. It gives you a place to shim security controls, monitoring, and alerting into the tool call pipeline.

by antirez 6mo ago

tomaytotomato 6mo ago

Although the author is coming from a place of security and configuration being painful with Skills, I think the future will be a mix of MCP, Agents and Skills. Maybe even a more granular defined unit below a skill - a command... 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.

senordevnyc 6mo ago
Commands are already a thing, but they're falling out of favor because a user can just invoke a skill manually instead.

ReDeiPirati 6mo ago

> 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. 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.

prohobo 6mo ago

I feel like the MCP conversation conflates too many things and everyone has strong assumptions that aren't always correct. The fundamental issue is between one-off vs. persistent access across sessions: - 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?

pavelbuild 6mo ago
[dead]
xyzzy123 6mo ago
My main complaint with mcp is that it doesn't compose well with other tools or code. Like if I want to pull 1000 jira tickets and do some custom analysis I can do that with cli or api just fine, but not mcp.
- prohobo 6mo ago
  Right, that feels like something you'd do with a script and some API calls. 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.
  - 6mo ago

eblair 6mo ago

[dead]

siva7 6mo ago

> MCP adds friction, imagine doing yourself the work using the average MCP server. 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.

_pdp_ 6mo ago
I won't be surprised if MCP start shipping skills. They already ship prompts and other things exposed as resources. It is not even difficult to do with the current draft as skills can be exposed by convention without protocol changes. Future version of the protocol can easily expose skills so that MCPs can acts like hubs.
- radiospiel 6mo ago
  Doesn't it already? https://modelcontextprotocol.io/specification/2025-11-25/server/prompts https://modelcontextprotocol.io/specification/2025-11-25/ser...
  - _pdp_ 6mo ago
    these are prompts - similar yes - but not the same
insin 6mo ago
The more things change in tech, the more they stay the same. The shoe is the sign. Let us follow His example! Cast off the shoes! Follow the Gourd!
bavell 6mo ago
They're complementary but also have significant overlap. Hence all the confusion and strong opinions.
robot-wrangler 6mo ago
> clearly don't understand either deeply No appetite for that. The MCP vs Skills debate has gradually become just a proxy war for the camps of AI skeptics vs AI boosters. Both sides view it as another chance to decide about more magic vs less, in absolute terms, without doing the work of thinking about anything situational. Nuance, questions, reasoning from first principles, focusing on purely engineering considerations is simply not welcome. The extreme factions do tend to agree that it might be a good idea to attack the middle though! There's no changing this stuff, so when it becomes tiresome it's time to just leave the HN comment section.

neya 6mo ago

> Focus on what tool the LLM requires to do its work in the best way. 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-agent-evals https://vercel.com/blog/agents-md-outperforms-skills-in-our-...

yunwal 6mo ago
How do you shut off particular api calls with an agents.md?
- neya 6mo ago
  I personally use tool calling for APIs, so really not sure (I don't use agents.md per se, I directly stuff info into the context window)

BatteryMountain 6mo ago

This is exactly what I do too. Works very well. I have a whole bunch of scripts and cli tools that claude can use, most of them was built by claude too. I very rarely need to use my IDE because of this, as I've replicated some of Jetbrains refactorings so claude doens't have to burn tokens to do the same work. It also turns a 5 minute claude session into a 10 second one, as the scripts/tools are purpose made. Its reallly cool. 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.

evanmoran 6mo ago
This is a great idea. Did you happen to release the source for this? I run into this all the time!
- BatteryMountain 6mo ago
  Nope, I just dump it all in a folder (~/scripts) that claude can read & it picks them up as skills. A good chunk of them are regex based, many are find/replace type tools, some are small code generators & template inflators, some are deployment tools, some are audit tools. I cannot release them at this time, most of them are specific to our company, infra and codebase (main codebase is 1MLoC), sorry about that. Start with a simple "Let me build a script for claude that can rename the namespace for all the file in a folder". If you have 100K+ plus files, it effort is worth it and your tools start getting chained together too. So make sure each tool only has one purpose for existing and that its output is perfect. So when claude start chaining them and you see what is possible, the mind opens up even more to possibilities.
smusamashah 6mo ago
> I've replicated some of Jetbrains refactorings How? Jetbrains in a Java code baes is amazing and very thorough on refactors. I can reliably rename, change signature, move things around etc.
- girvo 6mo ago

gitgud 6mo ago

> For instance it does not make sense to have an MCP to use git. 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…”

NiloCK 6mo ago
Just as easy to write a wrapper to the tool you want to restrict. You ban the restricted tool outright, and the skill instructs on usage of the wrapper. Safer than just giving an instruction to use the tool a specific way.
Majromax 6mo ago
Anyone who's ever `DROP TABLE`d on a production rather than test database has encountered the same problem in meatspace. In this context, the MCP interface acts as a privilege-limiting proxy between the actor (LLM/agent) and the tool, and it's little different from the standard best practice of always using accounts (and API keys) with the minimum set of necessary privileges. It might be easier in practice to set up an MCP server to do this privilege-limiting than to refactor an API or CLI-tool, but that's more an indictment of the latter than an endorsement of the former.

the_axiom 6mo ago

this comment just assumes skills ori better without dealing with any of the arguments presented low quality troll

federicosimoni 6mo ago

[dead]

fny 6mo ago

This is covered well in the article too. See "The Right Tool for the Job" and "Connectors vs. Manuals." Perhaps the title is just clickbait. :)

richardlblair 6mo ago

I've found makefiles to be useful. I have a small skill that guides the LLM towards the makefile. It's been great for what you're talking about, but it's also a great way to make sure the agent is interacting with your system in a way you prefer.

morgaesis 6mo ago

This is my life motto. Progressive exploration, codifying, use your codified workflows. > for each desired change, make the change easy (warning: this may be hard), then make the easy change - Kent Beck https://x.com/KentBeck/status/250733358307500032 https://x.com/KentBeck/status/250733358307500032

1minusp 6mo ago

Feels to me like the toolchain for using LLMs in various tasks is still in flux (i interpret all of this as "stuff in different places like .md or skills or elsewhere that is appended to the context window" (i hope that is correct)). Shouldnt this overall process be standardized/automated? That is, use some self-reflection to figure out patterns that are then dumped into the optimal place, like a .md file or a skill?

jpadkins 6mo ago
too early for standardization. resist the urge. Let a bunch of ideas flow, then watch the Darwinian process of the best setup will be found. Then standardize.
pizzafeelsright 6mo ago
The entire tooling ecosystem is in flux. Looking forward, the future is ad-hoc disposable software that once would take a large team a dozen sprints to release. Eventually it'll be use case -> spec -> validation -> result. The tv show Stargate showed different controls that scientifically calculated and operated starships so all the operator had to do was point the controls in the direction of the destination. The ai/computer/hardware knows how to get to the result and that result is human driven. I have evidence of this at work and in my own life with the key component being the tooling integration.

jFriedensreich 6mo ago

If your llm sees even a difference between local skill and remote MCP thats a leak in your abstraction and shortcoming of the agent harness and should not influence the decision how we need to build these system for the devs and end users. They way this comment thinks about building for agents would lead to a hellscape.

mikestorrent 6mo ago
Do you know who you're responding to? > a difference between local skill and remote MCP A local skill is a text file with a bunch of explanations of what to do and how, and what pitfalls to avoid. An MCP is a connection to an API that can perform actions on anything. This is a pretty massive difference in terms of concept and I don't think it can be abstracted away. A skill may require an MCP be available to it, for instance, if it's written that way. Antirez' advice is what I've been doing for a year: use AI to write proper, domain-specific tools that you and it can then use to do more impressive things.
- jFriedensreich 6mo ago
  Don't think its relevant who they are if they give advice that is based on outdated understanding of how agent harnesses are build and how to use MCP in an agent harness in the first place. You can serve agent skills via mcp or via text files accessed via local tools, if your harness makes this look different to the LLM in the end it is just a bad harness. The LLM should just see "ways to discover skills" and then "use the skills". If skills come from a folder or from an MCP is transparent implementation detail. This is more than just theoretical, if abstractions like the way skills are served leak into the context, this will measurably degrade agent performance, depending on model more or les severe!
  - mikestorrent 6mo ago
    What if the MCP needs to actually do something, like make an API call? It's nice sometimes to have those credentials out-of-band from the AI itself so it can't access them and is forced to go through the lens of tooling.

pojzon 6mo ago

This is how I work with my agent harness. Also have skills for writing tools and skills. And I still think ppl dont understand why MCPs are still needed and when to use them. Its actually pretty simple.

tehryanx 6mo ago

It makes a lot of sense to use an MCP for git and everything else if you want observability across many users. It gives you a place to shim security controls, monitoring, and alerting into the tool call pipeline.