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

381–390 of 415 posts

Re: I still prefer MCP over skills

#381

Post by anon84873628 »

JamesSwift wrote: post #252
prohobo wrote: post #138

Earlier quoted context omitted.

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…

Hard disagree. Apis and clis have been THOROUGHLY documented for human consumption for years and guess what, the models have that context already. Not only of the docs but actual in the wild use. If you can hook up auth for an agent, using any random external service is generally accomplished by just saying “hit the api”. I wrap all my apis in small bash wrappers that is just curl with automatic session handling so t…

By wrapping the API with a script and feeding that inventory to the LLM... You reinvented MCP.

Having service providers implement MCP saves everyone from having to do that work themselves.

Plus there are a lot more uses cases than developers running agents on their own machine.

Re: I still prefer MCP over skills

#382

Post by Twirrim »

xyzzy123 wrote: post #155
prohobo wrote: post #138

Earlier quoted context omitted.

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…

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.

Weird... I've been happily using Atlassian's MCP for this kind of thing just fine?

Re: I still prefer MCP over skills

#383

Post by anon84873628 »

bitexploder wrote: post #296
brabel wrote: post #192

Earlier quoted context omitted.

You haven’t actually done that have you. If you did, you would immediately understand the problems MCP solves on top of just trying to use an API directly: - easy tool calling for the LLM rather than having to figure out how to call the API based on docs only. - authorization can be handled automatically by MCP clients. How are you going to give a token to your LLM otherwise?? And if you do, how do you ensure it does…

An authnz aware egress proxy that also puts guard rails on MCP behavior?

Gee, that's starting to sound like a whole "bloated" framework...

Re: I still prefer MCP over skills

#384

Post by Twirrim »

CuriouslyC wrote: post #231
prohobo wrote: post #138

Earlier quoted context omitted.

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…

MCP is less discoverable than a CLI. You can have detailed, progressive disclosure for a CLI via --help and subcommands. MCPs needs to be wrapped to be composed. MCPs needs to implement stateful behavior, shell + cli gives it to you for free. MCP isn't great, the main value of it is that it's got uptake, it's structured and it's "for agents." You can wrap/introspect MCP to do lots of neat things.

I'm using an MCP to enhance my security posture. I have tools with commands that I explicitly cannot risk the agent executing.

So I run the agent in a VM (it's faster, which I find concerning), and run an MCP on the host that the guest can access, with the MCP also only containing commands that I'm okay with the agent deciding to run.

Despite my previous efforts with skills, I've found agents will still do things like call help on CLIs and find commands that it must never call. By the delights of the way the probabilities are influenced by prompts, explicitly telling it not to run specific commands increases the risk that it will (because any words in the context memory are more likely to be returned).

Re: I still prefer MCP over skills

#386

Post by JamesSwift »

anon84873628 wrote: post #381
JamesSwift wrote: post #252

Earlier quoted context omitted.

Hard disagree. Apis and clis have been THOROUGHLY documented for human consumption for years and guess what, the models have that context already. Not only of the docs but actual in the wild use. If you can hook up auth for an agent, using any random external service is generally accomplished by just saying “hit the api”. I wrap all my apis in small bash wrappers that is just curl with automatic session handling so t…

By wrapping the API with a script and feeding that inventory to the LLM... You reinvented MCP. Having service providers implement MCP saves everyone from having to do that work themselves. Plus there are a lot more uses cases than developers running agents on their own machine.

Wrapping here is literally just

```

  #!/usr/bin/env bash

  creds={path to creds}
  basepath={url basepath}

  url={parse from args}

  curl -H "Authorization: #{creds}" "#{basepath}/#{url}" $rest_of_args
```

Just a way to read/set the auth and then calling curl. Its generalizable to nearly all apis out there. It requires no work by the provider and you can shape it however you need.

Re: I still prefer MCP over skills

#387

Post by cruffle_duffle »

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

At that point might as well just use CLI

I totally agree that mcp not being compostable is a very big issue.

Re: I still prefer MCP over skills

#388

Post by cruffle_duffle »

csallen wrote: post #289
__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.

This is confusing to me. What is composability if not calling a program, getting its program, and feeding it into another program as input? Why does it matter if that output is stored in the LLM's context, or if it's stored in a file, or if it's stored ephemerally? Maybe I'm misunderstanding the definition of composability, but it sounds like your issue isn't that MCP isn't composable, but that it's wasteful because…

> Why does it matter if that output is stored in the LLM's context

Context window is expensive and precious. Much better to offload to some medium where it isn’t.

Re: I still prefer MCP over skills

#389

Post by cruffle_duffle »

BeetleB wrote: post #350
Aperocky wrote: post #346

Earlier quoted context omitted.

This maybe one of the area that MCP are ok-ish, however at huge cost to context.

As I and others have pointed out: The context problem with MCP is mostly solved. See https://news.ycombinator.com/item?id=47719249 for an example I gave.

Tool discovery is only one very small part of the “context problem”. The bigger problem is the outputs. You can’t compost them. Ever watch Claude code run some crazy shit through python and jq to take some input, transform it in some crazy way and output exactly what it needs back into its context? You simply can’t do that with mcp. It’s basically forced to accept the exact shape of the mcp output into its context and then take that intermediate output and dump it right back into another tool. That is incredibly wasteful!

If your lucky the mcp might expose a way to ship its output into a text file so at least the agent can have a go at it with CLI tools.

Re: I still prefer MCP over skills

#390

Post by BeetleB »

cruffle_duffle wrote: post #389
BeetleB wrote: post #350

Earlier quoted context omitted.

As I and others have pointed out: The context problem with MCP is mostly solved. See https://news.ycombinator.com/item?id=47719249 for an example I gave.

Tool discovery is only one very small part of the “context problem”. The bigger problem is the outputs. You can’t compost them. Ever watch Claude code run some crazy shit through python and jq to take some input, transform it in some crazy way and output exactly what it needs back into its context? You simply can’t do that with mcp. It’s basically forced to accept the exact shape of the mcp output into its context an…

I can see your point, but for pretty much everything I use MCP for, composability is not useful.
Post reply on HN