Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I still prefer MCP over skills

david.coffee

Post reply on HN
Print view View original

301–310 of 415 posts

Re: I still prefer MCP over skills

#301

Post by BeetleB »

CuriouslyC wrote: post #242
prohobo wrote: post #235

Earlier quoted context omitted.

"MCP is less discoverable than a CLI" - that doesn't make any sense in terms of agent context. Once an MCP is connected the agent should have full understanding of the tools and their use, before even attempting to use them. In order for the agent to even know about a CLI you need to guide the agent towards it - manually, every single session, or through a "skill" injection - and it needs to run the CLI commands to c…

If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like: tool --help tool subcommand1 --help tool subcommand2 --help man tool | grep "thing I care about" As for stateful behavior, say you have the google…

> that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities,

Completely false. I was dealing with this problem recently (a few tools, consuming too many tokens on each request). MCP has a mechanism for dynamically updating the tools (or tool descriptions):

https://code.claude.com/docs/en/mcp#dynamic-tool-updates

We solved it by providing a single, bare bones tool: It provides a very brief description of the types of tools available (1-2 lines). When the LLM executes that tool, all the tools become available. One of the tools is to go back to the "quiet" state.

That first tool consumes only about 60 tokens. As long as the LLM doesn't need the tools, it takes almost no space.

As others have pointed out, there are other solutions (e.g. having all the tools - each with a 1 line description, but having a "help" tool to get the detailed help for any given tool).

Re: I still prefer MCP over skills

#302

Post by 1minusp »

antirez wrote: post #108

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…

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?

Re: I still prefer MCP over skills

#305

Post by prohobo »

throwanem wrote: post #212
prohobo wrote: post #205

Earlier quoted context omitted.

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

You're clearly very intelligent and a real software engineer, maybe you can explain where I'm wrong?

Re: I still prefer MCP over skills

#306

Post by tim-projects »

throwpoaster wrote: post #206
medbar wrote: post #52

I still use vanilla Claude Code without MCP or skills, am I in the minority? Not trying to be a luddite.

Skills and MCP are useful for when you need to repeat specific processes, perpetually. Without them the task description and reasoning falls out of the context window, or is compressed, and the process fails. An agent will eventually forget, or hallucinate, guardrails and requirements. Yes to AGENTS.md, but when you're actively managing the whole context window in a long-running task you don't want to just keep jammi…

AGENTS.md doesn't fall out of the context window so you just put whatever commands you use in there. Every time it gets too big you rewrite it.

Never had an issue doing this

Re: I still prefer MCP over skills

#307

Post by Eldodi »

prohobo wrote: post #138
antirez wrote: post #108

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…

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…

There was a great presentation at the MCP Dev Summit last week explaining MCP vs CLI vs Skills vs Code Mode: https://www.figma.com/deck/H6k0YExi7rEmI8E6j6R0th/MCP-Dev-Su...

Re: I still prefer MCP over skills

#308

Post by medbrane »

CuriouslyC wrote: post #242
prohobo wrote: post #235

Earlier quoted context omitted.

"MCP is less discoverable than a CLI" - that doesn't make any sense in terms of agent context. Once an MCP is connected the agent should have full understanding of the tools and their use, before even attempting to use them. In order for the agent to even know about a CLI you need to guide the agent towards it - manually, every single session, or through a "skill" injection - and it needs to run the CLI commands to c…

If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like: tool --help tool subcommand1 --help tool subcommand2 --help man tool | grep "thing I care about" As for stateful behavior, say you have the google…

>here's no mechanism for progressive disclosure of parts of the tool's abilities

In fact there is: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

If the special tool search tool is available, then a client would not load the descriptions of the tools in advance, but only for the ones found via the search tool. But it's not widely supported yet.

Re: I still prefer MCP over skills

#309

Post by locknitpicker »

kordlessagain wrote: post #280
CuriouslyC wrote: post #242

Earlier quoted context omitted.

If you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like: tool --help tool subcommand1 --help tool subcommand2 --help man tool | grep "thing I care about" As for stateful behavior, say you have the google…

Nobody said anything about an API with thousands of endpoints. Does that even exist? I've never seen it. Wouldn't work on it if I had seen it. Such is the life of a strawman argument. Further, isn't a decorator in Python (like @mcp.tool) the easy way to expose what is needed to an API, if even if all we are doing is building a bridge to another API? That becomes a simple abstraction layer, which most people (and LLMs…

> Writing a CLI for an existing API is a fool's errand.

I don't think your opinion is reasonable or well grounded. A CLI app can be anything including a script that calls Curl. With a CLI app you can omit a lot of noise from the context things like authentication, request and response headers, status codes, response body parsing, etc. you call the tool, you get a response, done. You'd feel foolish to waste tokens parsing irrelevant content that a deterministic script can handle very easily.

Re: I still prefer MCP over skills

#310

Post by hereme888 »

I see the real argument is against poorly-designed MCP servers and where a skill/script would be a better fit.

If all you need is "teach the model how to use an existing tool", then use a skill, or even scripts, which are great for bulk work or teaching workflows.

MCPs are good at giving agents a stable, app-owned interface to a system w/o making the agents having to rediscover the integration every session. There's no way a skill/script would be able to handle the stuff I do via my local MCPs for managing certain apps and databases.

Post reply on HN