Live data from Hacker News

I still prefer MCP over skills

david.coffee

211–220 of 415 posts

Re: I still prefer MCP over skills

#211
post #176

Earlier quoted context omitted.

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.

You can make it compose by also giving the agent the necessary tools to do so. 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 d…

But in the context of this discussion, Atlassian has a CLI tool, acli. I'm not quite following why that wouldn't have worked here. As a normal CLI you have all the power you need over it, and the LLM could have used it to fetch all the relevant pages and save to disk, sample a couple to determine the regular format, and then write a script to extract out what they needed, right? Maybe I don't understand the use case you're describing.

Re: I still prefer MCP over skills

#212

Earlier quoted context omitted.

[flagged]

You do understand that what it sounds like you're talking about is essentially a proto-MCP implementation right? Except more manual work involved.

This has devolved into "MCP is web scale." https://youtu.be/b2F-DItXtZs

Re: I still prefer MCP over skills

#214
For my use I prefer just a raw CLI. As long as it's built following conventions (e.g. using cobra for a Go app) then the agent will just natively know how to use it, by which I mean how to progressively learn what it needs by reading the `help` output. In that case you don't need a skill or anything. Just say "I want this information, use the xyz app". It will then try `xyz --help` or `xyz help` or a variant, just like a human would, see the subcommands, do `xyz help subcommand` and eventually find what it needs to do the job. Good tools provide an OAuth flow like `xyz login`, which will open a browser window where you can determine which resources you want to give the CLI (and thereby the agent) access to.

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.

Re: I still prefer MCP over skills

#215

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…

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.

Re: I still prefer MCP over skills

#216

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…

> 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…”

Re: I still prefer MCP over skills

#218
Skills are static; MCP servers is dynamic. Skills codify info and workflows, help decrease redundant instructions, and increase consistent outcomes. MCP servers allow access to changing resources across systems.

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.

Re: I still prefer MCP over skills

#219

Skills are static; MCP servers is dynamic. Skills codify info and workflows, help decrease redundant instructions, and increase consistent outcomes. MCP servers allow access to changing resources across systems. 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…

Skills are compensation for out-of-distribution task assignment (and very valuable training data for model providers)

MCP are tools - might as well have just called it API for AI, but that ship has sailed.

It's 100% apples and oranges!

Re: I still prefer MCP over skills

#220

Skills are static; MCP servers is dynamic. Skills codify info and workflows, help decrease redundant instructions, and increase consistent outcomes. MCP servers allow access to changing resources across systems. 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…

> I took crazy pills this morning

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.

Post reply on HN