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

221–230 of 415 posts

Re: I still prefer MCP over skills

#221

Post by the_axiom »

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…

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

low quality troll

Re: I still prefer MCP over skills

#223

Post by __alexs »

insin wrote: post #176
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.

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…

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.

Re: I still prefer MCP over skills

#224

Post by Marha01 »

lll-o-lll wrote: post #125
friendzis wrote: post #112

Earlier quoted context omitted.

> If not, every API supports keys? How would MCP help you if the API does not support keys? But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to? You ARE running your agents in containers, right?

> How would MCP help you if the API does not support keys? Kerberos, OAuth, Basic Auth (username/password), PKI. MCP can be a wrapper (like any middleware). > But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to? If the cli can access the secrets, the agent can just reverse it and get the secr…

> If the cli can access the secrets, the agent can just reverse it and get the secret itself.

What do you mean by this? How "reverse it"? The CLI tool can access the secure storage, but that does not mean there is any CLI interface in the tool for the LLM to call and get the secret printed into the console.

Re: I still prefer MCP over skills

#225

Post by 0x696C6961 »

losvedir wrote: post #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 li…

You run the MCP server outside of the agent sandbox so it doesn't have access to the credentials.

Re: I still prefer MCP over skills

#226

Post by jmcodes »

xyzzy123 wrote: post #200
insin wrote: post #176

Earlier quoted context omitted.

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…

Hmm, but you can't write a standard MCP (e.g. batch_tool_call) that calls other MCPs because the protocol doesn't give you a way to know what other MCPs are loaded in the runtime with you or any means to call them? Or have I got that wrong? So I guess you had to modify the agent harness to do this? or I guess you could use... mcp-cli ... ??

I don't maintain this anymore but I experimented with this a while back: https://github.com/jx-codes/lootbox

Essentially you give the agent a way to run code that calls MCP servers, then it can use them like any other API.

Nowadays small bash/bun scripts and an MCP gateway proxy gets me the same exact thing.

So yeah at some level you do have to build out your own custom functionality.

Re: I still prefer MCP over skills

#227

Post by 0x696C6961 »

thecupisblue wrote: post #191
_pdp_ wrote: post #165

Earlier quoted context omitted.

You are mostly right except forgetting that not all SaaS companies want their users to shoot themselves in the foot by exposing the entire API surface and all of its quirks and risks to AI agents. Furthermore, In many cases some APIs, for better or worse, are not even sufficient. For example, the Notion MCP has full text search capabilities. Their API allows searching by title only. I don't know why but I am sure the…

Honestly it's on them, not on the users. In today's day and age, it's absurdly easy to create a proxy API for your API that only exposes a subset of operations. And not like other "easy" things which depend on them having done "the right thing" before, like OpenAPI specs, auth scoping etc. This is so easy, even corporations consider it easy, and everything there is a PITA. This is simple to make, to document and sinc…

If this is not /s then you need to read the MCP spec.

Re: I still prefer MCP over skills

#228

Post by bavell »

raincole wrote: post #193
noodletheworld wrote: post #184

Earlier quoted context omitted.

> The MCP exposes the API with those tools, it explains what the calendar app is So does an API and a text file (or hell, a self describing api). Which is more complex and harder to maintain, update and use? This is a solved problem. The world doesnt need MCP to reinvent a solution to it. If we’re gonna play the ELI5 game, why does MCP define a UI as part of its spec? Why does it define a bunch of different resource…

> So does an API and a text file (or hell, a self describing api). That sounds great. How about we standardize this idea? We can have an endpoint to tell the agents where to find this text file and API. Perhaps we should be a bit formal and call it a protocol!

> How about we standardize this idea? We can have an endpoint to tell the agents where to find this text file and API

Good news! It's already standardized and agents already know where to find it!

https://code.claude.com/docs/en/skills

Re: I still prefer MCP over skills

#229

Post by hrimfaxi »

__alexs wrote: post #223
insin wrote: post #176

Earlier quoted context omitted.

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…

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.

They can already do this, no? MCPs regularly dump their results to a textfile and other tools (cli or otherwise) filter it.

Re: I still prefer MCP over skills

#230

Post by bavell »

siva7 wrote: post #179
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…

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

They're complementary but also have significant overlap. Hence all the confusion and strong opinions.
Post reply on HN