Comment by mikestorrent
6 days 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.
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!
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.
You assume an MCP has to work a certain way that is not the case. MCP can work however you want, its just a protocol. The same answer applies to tools as applies to skills. A tool has to look exactly the same to the LLM no matter if its seved from a cli or an MCP or a js function framework level tool. Credentials have to be injected in the gateway in either case.