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

261–270 of 415 posts

Re: I still prefer MCP over skills

#261

Post by Aperocky »

zaphirplane wrote: post #104
plandis wrote: post #10

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.

This has been hashed to death and back. The mcp allows a separation between the agent and the world, at its most basic not giving the agent your token or changing a http header , forcing a parameter. Well yes you don’t need those things all the time and who knows if the inventor of mcp had this idea in mind but here we are

The separation is being oversold as if only MCP can do it, which is laughable. Any CLI can trivially do exactly what MCP do in terms of separation.

Re: I still prefer MCP over skills

#262

Post by cphoover »

I think language grammars are the an interesting way to define a ruleset too. Forget REST API's or MCP Servers for a second... Define a domain specific language, and let the language model generate a valid instruction within the confines of that grammar.

Than pass the program, your server or application can parse the instructions and work from the generated AST to do all sorts of interesting things, within the confines of your language features.

It's verifiable, since you are providing within the defined grammar, and with the parser provided.

It is implicitly sandboxed by the powers you give (or rather exclude) to your runtime via an interpreter/compiler

I've tried this before for a grammar I defined for searching documents, and found it to be quite good at creating valid often complex search instructions.

Re: I still prefer MCP over skills

#263

Post by michaelbuckbee »

prohobo wrote: post #159
xyzzy123 wrote: post #155

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.

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.

MCPs are for documentation. CLI->API is for interaction.

Re: I still prefer MCP over skills

#264

Post by Aperocky »

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…

It's like saying it is very safe and nice to drive a F150 with half ton of water on the truck bed.

How about driving the same truck without that half ton of water?

Re: I still prefer MCP over skills

#265

Post by Aperocky »

The most common mistake that I see here is people thinking only MCP can be bound to a server and store secrets and be called remotely

No, a CLI with RPC can do exactly that, just smaller. It goes lower in the exact same stack without the fluff.

Re: I still prefer MCP over skills

#267

Post by redsocksfan45 »

prohobo wrote: post #171
noodletheworld wrote: post #164

Earlier quoted context omitted.

> MCP is the absolute best and most effective way to integrate external tools into your agent sessions Nope. The best way to interact with an external service is an api. It was the best way before, and its the best way now. MCP doesn't scale and it has a bloated unnecessarily complicated spec. Some MCP servers are good; but in general a new bad way of interacting with external services, is not the best way of doing i…

Let's say I made a calendar app that stores appointments for you. It's local, installed on your system, and the data is stored in some file in ~/.calendarapp. Now let's say you want all your Claude Code sessions to use this calendar app so that you can always say something like "ah yes, do I have availability on Saturday for this meeting?" and the AI will look at the schedule to find out. What's the best way to creat…

[dead]

Re: I still prefer MCP over skills

#268

Post by juped »

prohobo wrote: post #180
frotaur wrote: post #175

Earlier quoted context omitted.

Why couldn't the calendar app expose in an API the read_calendar and update_calendar functionalities, and have a skill 'use_calendar' that describes how to use the above? Then, the minimal skill descriptions are always in the model's context, and whenever you ask it to add something to the calendar, it will know to fetch that skill. It feels very similar to the MCP solution to me, but with potentially less bloat and…

Why would I do that if the MCP already handles it? The MCP exposes the API with those tools, it explains what the calendar app is and when to use it. Connected MCP tools are also always in the model's context, and it works for any AI agent that supports MCP, not just Claude Code.

Why would you put a second, jankier API in front of your API when you could just use the API?

Re: I still prefer MCP over skills

#269

Post by __alexs »

insin wrote: post #238
__alexs wrote: post #223

Earlier quoted context omitted.

The agent cannot compose MCPs. What it can do is call multiple MCPs, dumping tons of crap into the context and then separately run some analysis on that data. Composable MCPs would require some sort of external sandbox in which the agent can write small bits of code to transform and filter the results from one MCP to the next.

At the level of the agent, it knows nothing about MCP, all it has is a list of tools. It can do anything the tools you give it let it do.

It cannot do "anything" with the tools. Tools are very constrained in that the agent must insert into it's context the tool call, and it can only receive the response of the tool directly back into its context.

Tools themselves also cannot be composed in any SOTA models. Composition is not a feature the tool schema supports and they are not trained on it.

Models obviously understand the general concept of function composition, but we don't currently provide the environments in which this is actually possible out side of highly generic tools like Bash or sandboxed execution environments like https://agenttoolprotocol.com/

Re: I still prefer MCP over skills

#270

Post by NiloCK »

gitgud wrote: post #216
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…

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

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.

Post reply on HN