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

Claude Skills are awesome, maybe a bigger deal than MCP

simonwillison.net

Post reply on HN
Print view View original

361–370 of 383 posts

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#361

Post by daxfohl »

michael1999 wrote: post #203

We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…

This is nothing new. v1 of something is always easy. Now in the coding assistant world, everything is v1. Let the tools go through a few deprecation cycles, weird things being added that don't map to the original intent, floods of overlapping tools and docs and everything else that someone has to reconcile, different LLM technologies that you need to support and adapt to, etc., and then see how things look.

I think all three things you mention come into play, but it's a bit early to judge whether the world has shifted or whether this is mainly a result of everything being fresh and new.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#362

Post by didibus »

tptacek wrote: post #238
brazukadev wrote: post #237

Earlier quoted context omitted.

It is funny most people discussing here does not understand MCP at all. Besides tools, MCP has resources, prompts, sampling, elicitation, roots and each one of them is useful when creating apps connected to LLMs. MCP is not only about MCP Servers, the host/client part is as important as the servers/tools. For example, nowadays most LLM clients are chatbots, but an MCP client could be a chess game or a project managem…

What can I do with MCP that I can't do with the function calling interface in the OpenAI Responses API? Besides, obviously, grafting function calls into agents I didn't write; we all understand that's the value prop of MCP. But you're suggesting it's more than that. Fill in the blanks for us.

The MCP can expose a list of tools, but also a list of prompt templates, a list of resources, it can ask the client to run something through the LLM (called sampling), and it can provide rules for when to follow up with questions.

But you can do all that yourself if you're building your own agent and directly calling a model. But if you want to be able to provide behavior to any agent, that's where MCP comes in.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#363

Post by didibus »

ming030890 wrote: post #331
brazukadev wrote: post #324

Earlier quoted context omitted.

The LLM can only use MCP tools, but the Client you use the model can access resources, prompts, elicitation and sampling, which are tools to help with querying the model. So one MCP server that implements some or all these features can act as an agent for the LLM dispatching tasks IF the client is also an MCP host/client.

But most of these can really be just a tool. For example, A resource can be just a getter tool, like getFile.

Resources could be a tool like list resources, but exposing them as resources means in the client you can show the user the list of resources, and the client can choose to include their descriptions in the context without the model choosing to do so for example.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#364

Post by hansmayer »

simonw wrote: post #359
hansmayer wrote: post #358

Earlier quoted context omitted.

On dictionaries: you're the one who insisted on dictionaries, only to produce wikipedia links instead :) Now how is it bias? Well, it's in your own answer. You are literally claiming things based on what you believe them to be, not based on what they likely are. For the latter, we'd need a longer timespan and more usage data. So you fiddled with it a bit in a timespan of a week or so and based on this tiny sample, ca…

I assumed bias was meant to mean I'm biased towards Anthropic, or to reflect some other unfair semi-hidden agenda that influences my writing. I do have a relevant bias here I guess: I'm biased towards the pattern of granting an LLM the ability to execute commands in a Unix-style environment. I've been a huge fan of that approach ever since ChatGPT Code Interpreter launched in early 2023 and I'm excited that skills fu…

Well, personally I believe you don't have any ulterior motives here. But be warned - when you hype up stuff like that and aligns perfectly with the interests of Anthropic (or whatever other VC-propped GenAI company), it can certainly come across the wrong way. Take this feedback as an indicator to help you steer your writing, not as a personal attack.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#365

Post by didibus »

tptacek wrote: post #250
didibus wrote: post #246

Earlier quoted context omitted.

> Tool calls are incredibly interesting and useful. MCP is just one means to that end, and not one of the better ones. It's nice to have an open standard though. In that sense it's pretty awesome. But MCP isn't just tools, you can expose prompt templates and context resources as well. All the skills that don't have an added dependency on a local script could just be an MCP resource.

You don't need MCP for prompt templates and context resources. Those are both just forms of prompting.

I'm not sure what you mean? LLMs can only be interacted with using prompting. Even the tool call response from OpenAPI is them just wrapping the prompt on their side of the API with another prompt.

So everything else is just adding behavior around it.

MCP is a way to add behavior around LLM prompting for user convenience.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#366

Post by AtlasBarfed »

ryukoposting wrote: post #316
michael1999 wrote: post #203

We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…

> What was the barrier to creating these documents before? In a proprietary system, there is pressure against creating quality technical documentation because it can be used to train your replacement. Writing docs solely for your own benefit, or your colleagues' benefit, is also dubious because you already know the things you wrote. Although returning to a thing you made months/years ago can be painful, it's not the…

Or tangibly enabling the company to eliminate you in favor of the AI assistant

Arguably the same structural disincentives are in place

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#367

Post by jfb »

michael1999 wrote: post #203

We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…

I think 2 is the big one; I also built a tool to maintain these fragments, and it's like, huh, this is just ... developer onboarding documentation?

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#368

Post by aabhay »

simonw wrote: post #112
tptacek wrote: post #110

I do think the big story here is how hyperfocused and path-dependent people got on MCP, when the actually-interesting thing is simply "tool calls". Tool calls are incredibly interesting and useful. MCP is just one means to that end, and not one of the better ones.

I think MCP's huge adoption was mainly due to its timing. Tool calling was a thing before MCP, but the models weren't very good at it. MCP almost exactly coincided with the models getting good enough at tool calling for it to be interesting. So yeah, I agree - most of the MCP excitement was people learning that LLMs can call tools to interact with other systems.

One thing about MCP that some people forget is that the models are post trained on MCP-based rollouts. I think people imagine that MCP was something people discovered about models but it’s deeper than that — models are explicitly trained to be able to interpret various and unseen kinds of MCP system prompts.

The exact same is true of these Claude Skills. Technically this is “just a system prompt and some tools”, but it’s actually about LLM labs intentionally encoding specific frameworks of action into the models.

Re: Claude Skills are awesome, maybe a bigger deal than MCP

#370

Post by simonw »

aabhay wrote: post #368
simonw wrote: post #112

Earlier quoted context omitted.

I think MCP's huge adoption was mainly due to its timing. Tool calling was a thing before MCP, but the models weren't very good at it. MCP almost exactly coincided with the models getting good enough at tool calling for it to be interesting. So yeah, I agree - most of the MCP excitement was people learning that LLMs can call tools to interact with other systems.

One thing about MCP that some people forget is that the models are post trained on MCP-based rollouts. I think people imagine that MCP was something people discovered about models but it’s deeper than that — models are explicitly trained to be able to interpret various and unseen kinds of MCP system prompts. The exact same is true of these Claude Skills. Technically this is “just a system prompt and some tools”, but…

A source I trust told me that Anthropic's models haven't yet been deliberately trained to know about skills.
Post reply on HN