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

321–330 of 415 posts

Re: I still prefer MCP over skills

#321

Post by somnium_sn »

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

Give the model an interpreter like mlua and let it write code to compose MCP calls together. This is a well established method.

It’s the equivalent to calling CLIs in bash, except mlua is a sandboxes runtime while bash is not.

Re: I still prefer MCP over skills

#323

Post by noisy_boy »

I feel like MCPs are encapsulation of multiple steps where the input to the first step is sufficient to drive the flow. Why would I spend tokens for the LLM to do reasoning at each of the steps when I can just provide the input + MCP call backed by a fixed program that can deal with the overall flow deterministically. If I have to do the same series of steps everytime, a script beats LLM doing the each step individually in terms of cost and time. If the flow involved some sort of fuzzy analysis or decision making in multiple places, I would probably let the LLM carry out the flow or break it into a combination of MCP calls orchestrated by the LLM.

In my case, my MCP is setup with the endpoints being very thin LLM facing layer with the meat of the action being done by helper methods. I also have cli scripts that import/use the same helpers so the core logic is centralized and the only difference is that thin layer, which could be the LLM endpoint or cli's argparse. If I need another type of interface, that can also call the same helpers.

Re: I still prefer MCP over skills

#324

Post by tow21 »

theshrike79 wrote: post #271
tow21 wrote: post #114

This argument always sounds like two crowds shouting past each other. Are you a solo developer, are you fully in control of your environment, are you focused on productivity and extremely tight feedback loops, do you have a high tolerance for risk: you should probably use CLIs. MCPs will just irritate you. Are you trying to work together with multiple people at organizational scale and alignment is a problem; are you…

In an organisation we can’t limit MCP access. It’s all or nothing. Everything the user can touch, the MCP can touch. We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI. An Agent can delete a thousand items in a second while doing 30 other things. With bespoke CLI tools we can configure them so that they cannot access anything except specific resources,…

(everything I write about MCP means "remote MCP" by the way. Local MCP is completely pointless)

MCP provides you a clear abstracted structure around which you can impose arbitrary policy. "identity X is allowed access to MCP tool Y with reference to resource pool Z". It doesn't matter if the upstream MCP service provides that granularity or not, it's architecturally straightforward to do that mapping and control all your MCP transactions with policies you can reason about meaningfully.

CLI provides ... none of that. Yes, of course you can start building control frameworks around that and build whatever bespoke structures you want. But by the time you have done that you have re-invented exactly the same data and control structures that MCP gives you.

"Identity X can access tool Y with reference to resource pool Z". That literally is what MCP is structured to do - it's an API abstraction layer.

Re: I still prefer MCP over skills

#326

Post by jFriedensreich »

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…

If your llm sees even a difference between local skill and remote MCP thats a leak in your abstraction and shortcoming of the agent harness and should not influence the decision how we need to build these system for the devs and end users. They way this comment thinks about building for agents would lead to a hellscape.

Re: I still prefer MCP over skills

#327

Post by [deleted] »

theshrike79 wrote: post #276
jjice wrote: post #274

Earlier quoted context omitted.

> In an organisation we can’t limit MCP access. Why not? I'd imagine that you could grant specific permissions upon MCP auth. Is the issue that the services you're using don't support those controls, or is it something else?

I haven’t seen a single major MCP provider that would let us limit access properly Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything. For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff. -> thus, hard deterministic limits are non-negotiable.

[deleted]

Re: I still prefer MCP over skills

#329

Post by BeetleB »

pjm331 wrote: post #299
theshrike79 wrote: post #276

Earlier quoted context omitted.

I haven’t seen a single major MCP provider that would let us limit access properly Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything. For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff. -> thus, hard deterministic limits are non-negotiable.

it's straightforward to spin up a custom MCP wrapper around any API with whatever access controls you want the only time i reach for official MCP is when they offer features that are not available via API - and this annoys me to no end (looking at you Figma, Hex)

Indeed, ever since MCPs came out, I would always either wrap or simply write my own.

I needed to access Github CI logs. I needed to write Jira stories. I didn't even bother glancing at any of the several existing MCP servers for either one of them - official or otherwise. It was trivial to vibe code an MCP server with precisely the features I need, with the appropriate controls.

Using and auditing an existing 3rd party MCP server would have been more work.

Re: I still prefer MCP over skills

#330

Post by evanmoran »

BatteryMountain wrote: post #215
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 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 rea…

This is a great idea. Did you happen to release the source for this? I run into this all the time!
Post reply on HN