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

221–230 of 383 posts

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

#221

Post by TheOtherHobbes »

globular-toast wrote: post #178
svdr wrote: post #167

Earlier quoted context omitted.

I think the difference now is that traditional software ultimately comes down to a long series of if/then statements (also the old AI's like Wolfram), whereas the new AI (mainly LLM's) have a fundamentally different approach.

Look into something like Prolog (~50 years old) to see how systems can be built from rules rather than it/else statements. It wasn't all imperative programming before LLMs. If you mean that it all breaks down to if/else at some level then, yeah, but that goes for LLMs too. LLMs aren't the quantum leap people seem to think they are.

They are from the user POV. Not necessarily in a good way.

The whole point of algorithmic AI was that it was deterministic and - if the algorithm was correct - reliable.

I don't think anyone expected that soft/statistical linguistic/dimensional reasoning would be used as a substitute for hard logic.

It has its uses, but it's still a poor fit for many problems.

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

#222

Post by roflcopter69 »

samuelknight wrote: post #207
roflcopter69 wrote: post #129

Earlier quoted context omitted.

I'd be really interested in what you mean. Are the any studies that quantify this difference in model performance when using JSON or XML? What could be a good intuition for why there might be a big difference? If XML is better than JSON for LLMs, why isn't everyone and the grandma recommending me to use XML instead of JSON? Why is Google Gemini API offering structured output only with JSON schema instead of XML schem…

(1) JSON requires lots of escape characters that mangle the strings + hex escapes and (2) it's much easier for model attention to track when a semantic block begins and ends when it's wrapped by the name of that section ... ... can be much easier than { "instructions": "..\n...\n" } especially when there are newlines, quotes and unicode

Thanks for the reply, that part about the models attention is pretty interesting!

I would suspect that a single attention layer won't be able to figure out to which token a token for an opening bracket should attend the most to. Think of {"x": {y: 1}} so with only one layer of attention, can the token for the first opening bracket successfully attend to exactly the matching closing bracket?

I wonder if RNNs work better with JSON or XML. Or maybe they are just fine with both of them because a RNN can have some stack-like internal state that can match brackets?

Probably, it would be a really cool research direction to measure how well Transformer-Mamba hybrid models like Jamba perform on structured input/output formats like JSON and XML and compare them. For the LLM era, I could only find papers that do this evaluation with transformer-based LLMs. Damn, I'd love to work at a place that does this kind of research, but guess I'm stuck with my current boring job now :D Born to do cutting-edge research, forced to write CRUD apps with some "AI sprinkled in". Anyone hiring here?

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

#224

Post by roflcopter69 »

bird0861 wrote: post #173
simonw wrote: post #139

Earlier quoted context omitted.

I don't know if the XML is better than JSON thing still holds with this year's frontier models, but it was definitely a thing last year. Here's Anthropic's documentation about that: https://docs.claude.com/en/docs/build-with-claude/prompt-eng... Note that they don't actually suggest that the XML needs to be VALID! My guess was that JSON requires more characters to be escaped than XML-ish syntax does, plus matching op…

the Qwen team is still all in on XML and they make a good case for it

Can you please provide a source? I'd love to know their exact reasoning and/or evidence that XML is the way to go.

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

#225

Post by ashleyn »

Herring wrote: post #219
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…

Probably all the same reasons tech debt exists in the first place: business pressure, poor design, lack of resources. It used to be expensive to keep good documentation up to date as the code changes.

If documentation is a side effect to providing accurate and effective AI context, it's pretty logical there will be a significant incentive to maintain it.

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

#227

Post by carlgreene »

simonw wrote: post #197
behnamoh wrote: post #196

Earlier quoted context omitted.

I think you're overly enthusiastic about what's going on here (which is surprising because you've seen the trend in AI seems to be re-inventing the wheel every other year...)

I'm more excited about this than I was about MCP. MCP was conceptually quite complicated, and a pretty big lift in terms of implementation for both servers and clients. Skills are conceptially trivial , and implementing them is easy... provided you have a full Linux-style sandbox environment up and running already. That's a big dependency but it's also an astonishingly powerful way to use LLMs based on my past 6 mont…

I’m curious some of the things you’re having the LLM/agents do with a full Linux sandbox that you wouldn’t allow on your local machine

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

#228

Post by brazukadev »

rednafi wrote: post #104
andoando wrote: post #67

Earlier quoted context omitted.

What do you find difficult about writing MCPs? I havent worked much with them but it seems easy enough. I made an MCP that integrates with jenkins so I can deploy code from claude (not totally useful cause can just make a few cli commands), but still took like 10 mins and works flawlessly. But I suppose yeah, why not just write clis and have an llm call them

Writing one off simple MCPs are quite easy but once you need to manage a fleet of them, it gets hairy. - Writing manifests and schemas by hand takes too long for small or iterative tools. Even minor schema changes often require re-registration or manual syncing. There’s no good “just run this script and expose it” path yet. - Running and testing an MCP locally is awkward. You don’t get fast iteration loops or rich er…

> - There’s no consistent registry, versioning, or discovery story. Sharing or updating MCPs across environments feels ad hoc, and you often have to wire everything manually each time.

yes there is:

https://github.com/modelcontextprotocol/registry

and here you have frontends for the registry https://github.com/modelcontextprotocol/registry/blob/main/d...

Everything is new so we are all building it in real time. This used to be the most fun times for a developer: new tech, everybody excited, lots of new startups taking advantage of new platforms/protocols.

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

#229

Post by brazukadev »

TeMPOraL wrote: post #198
behnamoh wrote: post #192

Earlier quoted context omitted.

an MCP server can run code outside of the domain of tools that it supports, tool call can't

Tools are literally function calls with extra steps. MCPs are interpreters of those function calls. Same stuff, different name - only thing that's changed is that Anthropic got people to agree on RPC protocol. It's not like it's a new idea, either. MCP isn't much different from SOAP or DCOM - but it works where the older approaches didn't, because LLMs are able to understand API definitions and natural-language docum…

> MCPs are interpreters of those function calls.

No, tool calls are just one of many MCP parts. People thinking MCP = SOAP or DCOM or JSON-RPC or OpenAPI didn't stop 20 minutes to read and understand MCP.

Tool calls is 20% of MCP, at maximum. And a good amount of it is dynamically generating the tool list exposed to LLMs. But lots of people here think MCP === give the model 50 tools to choose from

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

#230

Post by losvedir »

I'm a little confused about the relationship of Skills and just plain tools. It seems like a lot of skills might just be tools. Or, they might rely on calling sets of tools with some instructions.

But aren't the tool definitions and skill definitions in different places? How do you express the dependency? Can skills say they require command line access, python, tool A, and tool B, and when you load the skill it sets those as available tool calls?

Post reply on HN