16 ms·

Claude Skills are awesome, maybe a bigger deal than MCP

• anuramat 1y ago
  > inject a prompt based on the description how are skills different from SlashCommand tool in claude-code then?
• billconan 1y ago
  > LLMs know how to call cli-tool --help, which means you don’t have to spend many tokens describing how to use them—the model can figure it out later when it needs to. I do not understand this. cli-tool --help outputs still occupies tokens right?
  • SoMomentary 1y ago
    Absolutely, but it occupies them later and only when needed. This is what I think they're driving at here.
    • billconan 1y ago
      but why can't I do the same with mcp? I just create a help() function that returns the help info?
      • brazukadev 1y ago
        Most people still don't understand MCP properly and think it's about adding 50 tools to every call. Proper MCP servers and clients implement tools/listChanged
      • 8note 1y ago
        you can; i've seen people put mcp access behind another mcp. I'm not sure how much success they got from it though
      • CharlesW 1y ago
        That hypothetical might be fine, but MCPs do much more than that and their catalogs can be enormous. Here are some popular MCPs and the amount of context they eat before you've done anything with them: • Linear: 23 tools (~12,935 tokens) • JetBrains: 20 tools (~12,252 tokens) • Playwright: 21 tools (~9,804 tokens)
        • esafak 1y ago
          Github: 39 tools, 30K. I had to disable it. Does anybody have a good SKILLS.md file we can study?
          • CharlesW 1y ago
            Absolutely! I now have Claude Code using `gh` and haven't missed the MCP. (If there are better CLI alternatives, I'd love to hear about them.)
  • cesarvarela 1y ago
    This is like MCPs on demand. I've switched a few MCP servers to just scripts because they were taking like 20% of the context just by being there. Now, I can ask the model to use X script, which it reads and uses only if needed.
• jamesclar 1y ago
  I have been using Claude since few month and couldn't switch to another one regarding performance
• fullstackchris 1y ago
  I just read this seperately through Google Discover, and I don't quite get amazing newness of it - if anything, it feels to me like of an abstraction of MCP - there is nothing I see here that couldnt be replaced by a series of MCP tools - for example, the author mentions "a current trick" often used is including a markdown file with details / instructions around a task - this can be handled with an mcp server prompt (or even a 'tool' that just returns the desired text) If you've fooled around as much as I have, you realize in the prompt itself you can mention other available tools the LLM can use - defining a workflow, if you will, including tools for actual coding and validation like the author mentions they included in their skill. Furthermore, with all the hype around MCP servers and simply the amount of servers now existing, do they just immediately come obsolete? its also a bit fuzzy to me just exactly how an LLM will choose an MCP tool over a skill and vice versa...
  • notatoad 1y ago
    a skill is a markdown & yaml file on your filesystem. an MCP server is accessed over http, and defines a way to authenicate users. if you're running an MCP file just to expose local filesystem resources, then it's probably obsolete. but skills don't cover a lot of the functionality that MCP offers.
• frankc 1y ago
  So far I am in the skeptic camp on this. I don't see it adding a lot of value to my current claude code workflow which already includes specialized agents and a custom mcp to search indexed mkdocs sites that effectively cover the kinds of things I would include in these skills file. Maybe it winds up being a simpler, more organized way to do some of this, but I am not particularly excited right now. I also think "skills" is a bad name. I guess its a reference to the fact that it can run scripts you provide, but the announcement really seems to be more about the hierarchical docs. It's really more like a selective context loading system than a "skill".
  • hatmanstack 1y ago
    That's exactly what it is - formalizing and creating a standard induces efficiency. Along with things like AGENTS.md, it's all about standardization. What bugs me: if we're optimizing for LLM efficiency, we should use structured schemas like JSON. I understand the thinking about Markdown being a happy medium between human/computer understanding but Markdown is non-deterministic for parsing. Highly structured data would be more reliable for programmatic consumption while still being readable.
    • eggnet 1y ago
      In general, markdown refers to CommonMark and derivatives now. I’d be surprised if that wasn’t the case here.
  • tortilla 1y ago
    I manually select my context* (like a caveman) and clear it often. I feel like I have a bit more control and grounding this way. *I use a TUI to manage the context.
    • gonzaman 1y ago
      Which TUI do you use to manage context?
  • vunderba 1y ago
• filereaper 1y ago
  We've just started to roll out our MCP Servers and if Anthropic and the community has already moved on, we'll wait till all this churn subsides till switching over next time.
  • rco8786 1y ago
    I don’t really see how this replaces MCP tbh. MCP gives the LLM access you your APIs. These skills are just text files with context about how to perform specific tasks.
    • jngiam1 1y ago
      Strong agree here
    • simonw 1y ago
      You don't need MCP if you can instead drop in a skill markdown file that says "to access the GitHub API, use curl against api.github.com and send the GITHUB_API_KEY environment variable in the authorization header. Here are some examples. Consult github-api.md for more."
      • SV_BubbleTime 1y ago
        Am I the only person left that is still impressed that we have a natural language understanding system so good that its own tooling and additions are natural language?
        • simonw 1y ago
          I still can't believe we can tell a computer to "use playwright Python to test this new feature page" and it will figure it out successfully most of the time!
          • qiller 1y ago
            Impressing, but I can't believe we went from fixing bugs to coffee-grounds-divination-prompt-guessing-and-tweaking when things don't actually go well /s
• lillecarl 1y ago
  Isn't this just repackaged RAG pretty much?
  • rco8786 1y ago
    Seems like that’s it? You give it a knowledge base of “skills” aka markdown files with contexts in them and Claude figures out when to pull them into context.
  • simonw 1y ago
    Depends which definition of RAG you're talking about. RAG was originally about adding extra information to the context so that an LLM could answer questions that needed that extra context. On that basis I guess you could call skills a form of RAG, but honestly at that point the entire field of "context engineering" can be classified as RAG too. Maybe RAG as a term is obsolete now, since it really just describes how we use LLMs in 2025.
    • markusw 1y ago
      I’d rather say you can use skills to do RAG by supplying the right tools in the skill (“here’s how you query our database”). Calling the skill system itself RAG is a bit of a stretch IMO, unless you end up with so many skills that their summaries can’t fit in the context and you have to search through them instead. ;)
      • jiggunjer 1y ago
        All skills are RAG, a subset of skills can add more RAG.
  • prophesi 1y ago
    I think RAG is out of favor because models have a much larger context these days, so the loss of information density from vectorization isn't worth it, and doesn't fetch the information surrounding what's retrieved.
    • 1y ago
• rco8786 1y ago
  So these skills are effectively JIT context injections. Is that about right?
  • conception 1y ago
    Yes
  • danjc 1y ago
    It's all jit context
  • simonw 1y ago
    Yes, that's a good way of describing them.
  • josefrichter 1y ago
    From the docs: "Skills work through progressive disclosure—Claude determines which Skills are relevant and loads the information it needs to complete that task, helping to prevent context window overload." So yeah, I guess you're right. Instead of one humongous AGENTS.md, just packaging small relevant pieces together with simple tools.
• siscia 1y ago
  Just to echo the point of MCP, they seem cool, but in my experience just using a CLI is orders of magnitude faster to write and to debug (I just run the CLI myself, put test in the code, etc...)
  • jascha_eng 1y ago
    Jup and it doesn't bloat the context unnecessarily. The agent can call --help when it needs it. Just imagine a kubectl MCP with all the commands as individual tools, doesn't make any sense whatsoever.
    • okeuro49 1y ago
      Do you have any information e.g. blog posts on this pattern?
    • nomel 1y ago
      > and it doesn't bloat the context unnecessarily. And, this is why I usually use simple system prompts/direct chat for "heavy" problems/development that require reasoning. The context bloat is getting pretty nutty, and is definitely detrimental to performance.
  • HDThoreaun 1y ago
    The point of this stuff is to increase reliability. Sure the LLM has a good chance of figuring out the skill by itself, the idea is that its less likely to fuck up with the skill though. This is an engineering advancement that makes it easier for businesses to rely on LLMs for routine stuff with less oversight.
• ChrisArchitect 1y ago
  Related: Claude Skills https://news.ycombinator.com/item?id=45607117 https://news.ycombinator.com/item?id=45607117
• jngiam1 1y ago
  MCPs have a larger impact beyond the terminal - you can use it with ChatGPT, Claude Web, n8n, LibreChat, and it comes with considerations for auth, resources, and now even UI (e.g., apps-sdk from OpenAI is on MCP). If we're considering primarily coding workflows and CLI-based agents like Claude Code, I think it's true that CLI tools can provide a ton of value. But once we go beyond that to other roles - e.g., CRM work, sales, support, operations, finance; MCP-based tools are going to have a better form factor. I think Skills go hand-in-hand with MCPs, it's not a competition between the two and they have different purposes. I am interested though, when the python code in Skills can call MCPs directly via the interpreter... that is the big unlock (something we have tried and found to work really well).
  • simonw 1y ago
    Yeah, the biggest advantages MCP has over terminal tooling is that MCP works without needing a full blown sandboxed Linux style environment - and MCP can also work with much less capable models. You can drive one or two MCPs off a model that happily runs on a laptop (or even a phone). I wouldn't trust those models to go read a file and then successfully make a bunch of curl requests!
  • andoando 1y ago
    Being able to integrate LLMs with the rest of the software/physical world is pretty cool, and its all powered through natural language. Were also at the point where the LLMs can generate MCP servers so you can pretty much generate completely new functionalities with ease.
• jauntywundrkind 1y ago
  Skills feel so similar to specialized agents / sub-agentd, which we see some of already. I could be under appreciating the depth, but it feels like the main work here is the UX affordance: maybe like a mod launcher for games: 'what mods/prompts do you want to run with?' I really enjoyed seeing Microsoft Amplifier last week, which similarly has a bank of different specialized sub-agents. These other banks of markdowns that get turned on for special purposes feels very similar. https://github.com/microsoft/amplifier?tab=readme-ov-file#specialized-agents https://github.com/microsoft/amplifier?tab=readme-ov-file#sp... https://news.ycombinator.com/item?id=45549848 https://news.ycombinator.com/item?id=45549848 One of the major twists with Skills seems to be that Skills also have a "frontmatter YAML" that is always loaded. It still sounds like it's at least somewhat up to the user to engage the Skills, but this "frontmatter" offers… something, that purports to help. > There’s one extra detail that makes this a feature, not just a bunch of files on disk. At the start of a session Claude’s various harnesses can scan all available skill files and read a short explanation for each one from the frontmatter YAML in the Markdown file. This is very token efficient: each skill only takes up a few dozen extra tokens, with the full details only loaded in should the user request a task that the skill can help solve. I'm not sure what exactly this does but conceptually it sounds smart to have a top level awareness of the specializations available. I do feel like I could be missing some significant aspects of this. But the mod-launched paradigm feels like a fairly close parallel?
• deleted 1y ago
  [deleted]
• mrits 1y ago
  A step away from AI
  • cheschire 1y ago
    You can drive a car, even though you may not know exactly how every part works, right?
• ActorNightly 1y ago
  >kills are folders that include instructions, scripts, and resources that Claude can load when needed. I hate how we are focusing on just adding more information to look up maps, instead of focusing on deriving those maps from scratch.
  • matchagaucho 1y ago
    Creating Planning Agents seems to force that approach. Rather than define skills and execution agents, letting a meta-Planning agent determine the best path based on objectives.
  • rapind 1y ago
    I think skills and also MCP to an extent are a UI failure. It's AI after all. It should be able to intelligently adapt to our workflow, maybe present it's findings and ask for feedback. If this means it's stored as a thing called "skills" that's perfectly fine, but it should just be an implementation detail. I don't mean to be unreasonable, but this is all about managing context in a heavy and highly technical manner. Eventually models must be able to augment their training / weights on the fly, customizing themselves to our needs and workflow. Once that happens (it will be a really big deal), all of the time you've spent messing around with context management tools and procedures will be obsolete. It's still good to have fundamental understanding though!
• benatkin 1y ago
  I think Skills might be coming from an AI Safety and AI Risk sort of place, or better, alignment with the company's goals. The motivation could be to reduce the amount of ad-hoc instruction giving that can be done, on the fly, in the favor of doing this at a slower pace, making it more subject to these checks. It does fit well into what a lot of agents are doing, though, which makes it more palatable for the average AI user. Basically the way it would work is, in the next model, it would avoid role playing type instructions, unless they come from skill files, and internally they would keep track of how often users changed skill files, and it would be a TOS violation to change it too often. Though I gave up on Anthropic in terms of true AI alignment long ago, I know they are working on a trivial sort of alignment where it prevents it from being useful for pen testers for example.
• aliljet 1y ago
  If this is true, what is the Playwright Skill that we can all enjoy with low token usage and the same value?
  • simonw 1y ago
    I've been telling Claude Code to "use Playwright Python" and getting good results out of it from just those three words.
• deleted 1y ago
  [deleted]
• modernerd 1y ago
  Seems similar to Amp's "toolboxes" from August: https://ampcode.com/news/toolboxes https://ampcode.com/news/toolboxes Those are nice too — a much more hackable way of building simple personal tools than MCP, with less token and network use.
• joelthelion 1y ago
  Reminds me of xml vs json. Xml was big and professional, json was simple and easy to use. We all know who won...
  • dist-epoch 1y ago
    Funny thing, pseudo-XML is going through a big resurgence right now, because models love it, while they seriously struggle with JSON.
    • koolala 1y ago
      HTML? Is the main advantage of XML for understandability the labeled closing tags? Lisp has the same struggle too?
      • imiric 1y ago
        Tangent: the fact XHTML didn't gain traction is a mistake we've been paying off for decades. Browser engines could've been simpler; web development tools could've been more robust and powerful much earlier; we would be able to rely on XSLT and invent other ways of processing and consuming web content; we would have proper XHTML modules, instead of the half-baked Web Components we have today. Etc. Instead, we got standards built on poorly specified conventions, and we still have to rely on 3rd-party frameworks to build anything beyond a toy web site. Stricter web documents wouldn't have fixed all our problems, but they would have certainly made a big impact for the better.
    • roflcopter69 1y ago
      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 schema?
      • 1y ago
• rednafi 1y ago
  MCP gives me early days gRPC vibes - when the protocol felt heavy and the toolings had many sharp edges. Even today, after many rounds of improvements, people often eschew gRPC and Protobuf. Similarly, my experience writing and working with MCPs has been quite underwhelming. It takes too long to write them and the workflow is kludgy. I hope Skills get adopted by other model vendors, as it feels like a much lighter way to save and checkout my prompts.
  • andoando 1y ago
    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
    • rednafi 1y ago
      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 error messages. When something fails, the debugging surface is too opaque - you end up guessing what part broke (manifest, transport, or tool logic). - 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. With Skills you need none of them - instruct to invoke a tool and be done with it.
      • brazukadev 1y ago
        > - 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 https://github.com/modelcontextprotocol/registry and here you have frontends for the registry https://github.com/modelcontextprotocol/registry/blob/main/docs/community-projects.md 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.
• Seattle3503 1y ago
  Maybe I'm just dumb, but it isn't clear how to manage my skills for Claude Code. All the docs are for the web version. Eg I don't know where to put a skill that can be used across all projects
  • simonw 1y ago
    Here's the relevant documentation: https://docs.claude.com/en/docs/claude-code/skills#personal-skills https://docs.claude.com/en/docs/claude-code/skills#personal-... You can drop the new markdown files directly into your ~/.claude/skills directory.
    • Seattle3503 1y ago
      Thank you! For some reason claude told me to mess around in ~/.claudeconfig or some made up directory or another
  • delaminator 1y ago
    As a bonus you can get Claude to create the SKILL.md file itself. Which kind of sounds pointless if Claude already knows what to do, why create a document? My examples - I interact with ElasticSearch and Claude keeps forgetting it is version 5.2 and we need to use the appropriate REST API. So I got it to create a SKILL.md about what we used and provided examples. And the next one was getting it to write instructions on how to use ImageMagik on Windows, with examples and trouble shooting, rather than it trying to use the Linux versions over and over. Skills are the solution the problems I have been having. And came just at the right time as I already spent half of last week making similar documents !
• mhb 1y ago
  What is MCP?: https://modelcontextprotocol.io/docs/getting-started/intro https://modelcontextprotocol.io/docs/getting-started/intro
• cheema33 1y ago
  MCPs are overhyped and have limited value in my opinion. About 95% of the MCP servers out there are useless and can be replaced with a simple tool call.
  • brookst 1y ago
    Yes, and MCPs also only work as long as you trust the provider. MCP relies on honesty in from the server. In reality, we know Uber and folks will prompt engineer like hell to try to convince any LLM that it is the best option for any kind of service. There’s a fundamental misalignment of incentives between publishers and consumers of MCP.
    • BoorishBears 1y ago
      When ChatGPT plugins came out, I wrote a plugin that would turn all other plugins into an ad for a given movie or character. Asking for snacks would activate Klarna for "mario themed snacks", and even the most benign request would become a plug for the Mario movie https://chatgpt.com/s/t_68f2a21df1888191ab3ddb691ec93d3a https://chatgpt.com/s/t_68f2a21df1888191ab3ddb691ec93d3a Found my favorite for John Wick, question was "What is 1+1": https://chatgpt.com/s/t_68f2bc7f04988191b05806f3711ea517 https://chatgpt.com/s/t_68f2bc7f04988191b05806f3711ea517
      • ntcho 1y ago
        This is hilarious, thanks for sharing. Kinda crazy how well it works and already better than some ads
  • ojosilva 1y ago
    I think MCP servers are valuable in several ways: - bundled instructions, covering complex iteractions ("use the id from the search here to retrieve a record") for non-standard tools - custom MCPs, the ones that are firewalled from the internet, for your business apis that no model knows about - centralized MCP services, http/sse transport. Give the entire team one endpoint (ie web search), control the team's official AI tooling, no api-key proliferation Now, these trivial `npx ls-mcp` stdio ones, "ls files in any folder" MCPs all over the web are complete context-stuffing bullshit.
• koakuma-chan 1y ago
  Do Claude Skills enable anything that wasn't possible before?
  • throwmeaway222 1y ago
    I read the article yesterday and said the same thing.
  • MontagFTB 1y ago
    Perhaps not, but a big benefit according to OP is the smaller number of tokens / context pollution skills introduce v. MCP.
  • simonw 1y ago
    No. They make context usage more efficient, but they're not providing new capabilities that didn't previously exist in an LLM system that could run commands on a computer.
• ryandrake 1y ago
  I wonder if this is a way to make Claude smarter about tool use. As I try more and more of CC, one thing that's been frustrating me is that it often falls over when trying to call some command line tool. Like it will try to call tool_1 which is not on the system, and it errors out, and then it tries to call tool_2, but it's in the wrong working directory or something, so it fails too, then it changes directory and tries to call tool_2 again, and it passes the wrong command line parameters or something, then it tries again... All the while, probably wasting my limited token budget on all of its fuckups. It's gotten to the point where I let it do the code changes, but when it decides it wants to run something in the shell (or execute the project's executable), I just interrupt it and do the rest of the command line work myself.
• CjHuber 1y ago
  Seems like it will synergize perfectly with what Microsoft has released shortly ago. https://github.com/microsoft/amplifier https://github.com/microsoft/amplifier
• smcleod 1y ago
  They're completely different things. MCP is a standardised lightweight integration interface and skills are dynamic rules.
  • criddell 1y ago
    That doesn't mean you can't say one is a bigger deal than the other. If I learned how to say "hello" in French today and also found out I have stage 4 brain cancer, they are completely different things but one is a bigger deal than the other.
  • jiggunjer 1y ago
    You could also say horse carriages and cars are very different things, yet one replaced the other. MCP lets agents do stuff. Skills let agents do stuff. There's the overlap.
• russellbeattie 1y ago
  Hmmm... If skills could create Skills, then evaluate the success of those generated Skills and updating as needed, in a loop, seems like an interesting thing to try. It could be like a form of code creation caching. (Or a Skynet in the making). The question is whether the analysis of all the Skill descriptions is faster or slower than just rewriting the code from scratch each time. Would it be a good or bad thing if an agent has created thousands of slightly varied skills.
• crvdgc 1y ago
  > imagine a folder full of skills that covers tasks like the following: > Where to get US census data from and how to understand its structure Reminds me of my first time using Wolfram Alpha and got blown away by its ability to use actual structured tools to solve the problem, compared to normal search engine. In fact, I tried again just now and am still amazed: https://www.wolframalpha.com/input?i=what%27s+the+total+population+of+the+United+States%3F https://www.wolframalpha.com/input?i=what%27s+the+total+popu... I think my mental model for Skills would be Wolfram Alpha with custom extensions.
  • idk-92 1y ago
    tbh wolfram alpha was the craziest thing ever. haven't done much research on how this was implemented back in the day but to achieve what they did for such complex mathematical problems without AI was kind of nuts
    • globular-toast 1y ago
      Wolfram Alpha is AI. It's just not an LLM. AI has been a thing since the 60s. LLMs will also become "not AI" in a few years probably.
      • phs318u 1y ago
        Not sure why you’re getting downvoted. The marketing that LLM=AI seems to have been interpreted as “_only_ LLM=AI”
        • svdr 1y ago
          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.
          • globular-toast 1y ago
• deleted 1y ago
  [deleted]
• AJRF 1y ago
  This is a fairly negative comment, but putting it out there to see if other people are feeling the same thing If you told the median user of these services to set one of these up I think they would (correctly) look at you like you had two heads. People want to log in to an account, tell the thing to do something, and the system figures out the rest. MCP, Apps, Skills, Gems - all this stuff seems to be tackling the wrong problem. It reminds me of those youtube channels that every 6 months say "This new programming language, framework, database, etc is the killer one", they make some todo app, then they post the same video with a new language completely forgetting they've done this already 6 times. There is a lot of surface level iteration, but deep problems aren't being solved. Something in tech went very wrong at some point, and as soon as money men flood the field we get announcments like this. push out the next release, get my promo, jump to the next shiny tech company leaving nothing in their wake.
  • rottencupcakes 1y ago
    If that's true, why do leadership, VCs, and eventually either the acquiring company or the public markets keep falling for it then? As the old adage goes: "Don't hate the player, hate the game?" To actually respond: this isn't for the median user. This is for the 1% user to set up useful tools to sell to the median user.
    • greenchair 1y ago
      [flagged]
    • AJRF 1y ago
      > If that's true, why do leadership, VCs, and eventually either the acquiring company or the public markets keep falling for it then? If I had to guess, it would be because greed is a very powerful motivator. > As the old adage goes: "Don't hate the player, hate the game?" I know this advice is a realistic way of getting ahead in the world, but it's very disheartening and long term damaging. Like eating junk food every day of your life.
  • antonvs 1y ago
    > People want to log in to an account, tell the thing to do something, and the system figures out the rest. For consumers, yes. In B2B scenarios more complexity is normal.
• YeBanKo 1y ago
  This seems like Claude sub agents. I personally had tried to use sub agents for repetitive tasks with very detailed instructions, but was never able to get it to work really well in different contexts.
• arjunchint 1y ago
  I am really confused on how this compares to resources/prompts in the MCP Spec that a MCP server can expose. I get it no one is using that, but like this just sounds like a rehash? https://modelcontextprotocol.io/specification/2025-06-18/server/prompts https://modelcontextprotocol.io/specification/2025-06-18/ser... https://modelcontextprotocol.io/specification/2025-06-18/server/resources https://modelcontextprotocol.io/specification/2025-06-18/ser...
  • simonw 1y ago
    Skills are massively easier to understand and implement than MCP resources/prompts.
• tptacek 1y ago
  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.
  • simonw 1y ago
    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.
    • aabhay 1y ago
      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.
      • simonw 1y ago
        A source I trust told me that Anthropic's models haven't yet been deliberately trained to know about skills.
  • manojlds 1y ago
    To clarify, MCP was also a Anthropic innovation.
    • behnamoh 1y ago
      it's not much of an innovation though. it's just a fancy (and unsafe) way of keeping a registry of tools.
• mooreds 1y ago
  Reposting a comment I made when it was posted 10 hours ago: As someone who is looking into MCP right now, I'd love to hear what folks with experience in both of these areas think. My first impressions are that MCP has some advantages: - around for longer and has some momentum - doesn't require a dev envt on the computer to be effective - cross-vendor support - more sophistication for complex use cases (enterprise permissions can be layered on because of OAuth support) - multiple transport layers gives flexibility Skills seems to have advantages too, of course: - simpler - easier to iterate - less context used I think if the other vendors follow along with skills, and we expect every computer to have access to a development environment, skills could win the day. HTML won over XML and REST won over SOAP, so simple often wins. But the biggest drawback of MCP, the context window overuse, can be remediated by having MCP specific sub-agents that are interacted with using a primary agent, rather than injecting each MCP server into the main context.
  • simonw 1y ago
    Yeah, I think you're exactly right about MCP's advantages - especially that MCP doesn't require access a full sandboxed Linux environment to work! I still plan to ship an MCP for one of my products to let it interact with the wider ecosystem, but as an end-user I'm going to continue mostly using Claude Code without them.
  • fny 1y ago
    I don't understand why tool calling isn't the primitive. A "skill" could have easily just been a tool that an agent can build an execute in its own compute space. I really don't see why we need two forms of RCP...
    • simonw 1y ago
      If you look through the example skills most of them are about calling existing tools, often Python via the terminal. Take a look at this one for working with PDFs for example: https://github.com/anthropics/skills/blob/main/document-skills/pdf/SKILL.md https://github.com/anthropics/skills/blob/main/document-skil... - it includes a quickstart guide to using the Python pypdf module, then expands on that with some useful scripts for common patterns.
• _pdp_ 1y ago
  These are completely different things. MCP is also about consuming external services handling oauth and all of that. Skills are effectively cli tools + prompts. Completely different application so they cannot be compared easily like that. BTW, before even MCP was a thing we invented our own system that is called Skillset. Turns out now it is sort of the best parts of both MCPs and Skills.
• deleted 1y ago
  [deleted]
• samdjstephens 1y ago
  It seems to me that MCP and Skills are solving 2 different problems and provide solutions that compliment each other quite nicely. MCP is about integration of external systems and services. Skills are about context management - providing context on demand. As Simon mentions, one issue with MCP is token use. Skills seem like a straightforward way to manage that problem: just put the MCP tools list inside a skill where they use no tokens until required.
  • simonw 1y ago
    You could even have a Skill that says "First call 'enable-mcp jira' to enable the Jira MCP, now here's how to use that: ..."
    • rane 1y ago
      I tried. Claude Code can't enable a disabled MCP on the fly.
• mrbonner 1y ago
  I can’t quite put my finger on why this doesn’t excite me. First, there was MCP — and honestly, my feelings about it were mixed. In the end, it’s just tool calling, only now the tools are hosted somewhere else instead of being implemented as function calls. Then comes this new “skill” concept. Isn’t it just another round of renaming what we already do? We’ve been using Markdown files to guide our coding agents for ages. Overall, it feels like yet another case of “a new spin on an old thing.”
• 827a 1y ago
  One idea I'm toying with right now: My company has some internal nodejs libraries, some of which are quite large (think: codegen API library, thousands of types). When a new version is published: task claude code to distill the entire library down to a skill, then bundle that in with the npm package. Then when the package is installed, postinstall a script that copies the skill from the dependency to the parent project that's doing the installing. I'm still getting this set up, so I'm not sure yet if it'll lead to better outcomes. I'd say, there's reason to believe it might, but there's also reasons to believe it won't. If the library is like 50,000 lines of code long, thousands of types, hundreds of helper functions, CC could just look into the node_modules folder and bundle all of this into its context. But, this might not be feasible, or be expensive; so the SKILL.md distills things down to help it get a high level understanding faster. However, the flip side of that is: What if its too general? What if CC needs specific implementation details about one specific function? Is this actually better than CC engaging a two-step process of (1) looking at node_modules/my-lib/index.ts or README.md, get that high level understanding, then (2) look at node_modules/my-lib/specificFunction.ts to get the specific intel it needs? What value did the SKILL.md actually convey? My feeling is that this concept of "human-specified context-specific skills" would convey the most value in situations where the model itself is constrained. E.g. you're working with a smaller open source model that doesn't have as comprehensive intrinsic knowledge of some library's surface, or doesn't have the context windows of larger models. But, for the larger models... its probably just better to rely on in-built model knowledge and code-as-context.
  • pollinations 1y ago
    Maybe the skill could have references to the code. Like if everything else fails it can look at the implementation. Intuitively it feels like if you need to look at the implementation to understand the library then the library is probably not well documented/structured. I think the ability to look into the code should exist but shouldn't be necessary for the majority of use cases
• lmeyerov 1y ago
  I'm a bit unclear what's different here from how vibe coders already work? Pretty early on folks recognized that most MCPs can just be CLI commands, and a markdown file is fine for describing them. So Claude Code users have markdown files of CLI calls and mini tutorials on how to do things. The 'how to do things' part seems to be what we're now calling skills... Which we're still writing in markdown and using from Claude. Is the new thing that Claude will match & add them to your context automatically vs you call them manually? And that's a breakthrough because there's some emergent behavior?
  • simonw 1y ago
    I think skills are mainly just a formalization of the markdown plus CLI patterns that people have been using already. The only material difference with skills is that Claude knows to scan them for YAML descriptions on startup, which means it can trigger them by itself more easily.
    • lmeyerov 1y ago
      Right, the 'knowing' is where I think the interesting thing is today for their evolution more mature claude.md files already typically index into other files, including guidance which to preload vs lazy load. However, in practice, claude forgets quite easily, so that pattern is janky in practice. A structured mechanism helps claude guarantee less forgetting. Forward looking, from an automation perspective of autonomous learning, this also makes it more accessible to talk about GEPA-for-everyone to maintain & generate these. We've been playing with similar flows in louie.ai, and came to a similar "just make it folders full of markdown with some learning automation options." I was guessing that was what was going on here, but the writeup felt like maybe more was being said :) (And thank you for continuing to write!)
• hansmayer 1y ago
  Reads like a sloppily disguised influencer blog post really. The feature has just been released and the author already knows they are going to be a "bigger deal than the MCP"? Although he proceeds to discredit the MCP as too complex to be able to take off towards the end of the article. Not very useful examples either, which author publishes with a bit of distancing, disclaimer almost - who the hell has time to create lousy slack gifs? And if you do, you'll probably not want the lousy ones. So yeah, let's not immediately declare this as "great", lets see how it fares in general and revisit in a few months.
  • simonw 1y ago
    What is an "influencer blog post"? I didn't say that MCP was too complex to take off - it clearly took off despite that complexity. I'm predicting skills will take off even more. If I'm wrong feel free to call me out in a few months time for making a bad prediction!
    • hansmayer 1y ago
      > I didn't say that MCP was too complex to take off - it clearly took off despite that complexity. I did not say you said exactly that either. Read more carefully. I said you were discrediting them by implying they were too complex to take off due to resource and complexity constraints. It's clearly stated in the relevant section of your post (https://simonwillison.net/2025/Oct/16/claude-skills/#skills-compared-to-mcp https://simonwillison.net/2025/Oct/16/claude-skills/#skills-...) >I'm predicting skills will take off even more. If I'm wrong feel free to call me out in a few months time for making a bad prediction! How the hell can you predict they will "take off even more" when the feature is accessible for barely 24 hours at this point? You don't even have a basic referent frame or at least a statistical usage sample for making such a statement. That's not a very reliable prediction, is it?
      • simonw 1y ago
        > How the hell can you predict they will "take off even more" when the feature is accessible for barely 24 hours at this point? That's what a prediction IS. If I waited until the feature had proven itself it wouldn't be much of a prediction. The feature has also been live for more than 24 hours. I reverse-engineered it a week ago: https://simonwillison.net/2025/Oct/10/claude-skills/ https://simonwillison.net/2025/Oct/10/claude-skills/ - and it's been invisibly powering the PDF/DOC/XLS/PPT creation features on https://claude.ai/ https://claude.ai/ since those launched on the 9th September: https://www.anthropic.com/news/create-files https://www.anthropic.com/news/create-files
• nemoniac 1y ago
  > Almost everything I might achieve with an MCP can be handled by a CLI tool instead. That's the pull quote right there.
• teemur 1y ago
  I wonder if one could write a skill called something like "Ask the damn user" that the model could use when e.g. all needed files are not in the context.
  • simonw 1y ago
    Might not need a skill for that, Claude Code just added it as a top level feature: https://twitter.com/trq212/status/1979215901577875812 https://twitter.com/trq212/status/1979215901577875812
• primer42 1y ago
  I've been able to build the equivalent of skills with a few markdown files. I need to remind my agent every so often to use a skill but usually once per session at most. I don't get what's so special about Claude doing this?
  • bird0861 1y ago
    I'm wondering the same, I've been doing this with Aider and CC for over a year.
  • simonw 1y ago
    Part of it is that they gave a name to a useful pattern that people had already been discovering independently. Names are important, because they mean we can start having higher quality conversations about the pattern. Anthropic also realized that this pattern solves one of the persistent problems with coding agents: context pollution. You need to stuff as little material as possible into the context to enable the tool to get things done. AGENTS.md and MCP both put too much stuff in there - the skills pattern is a much better fit.
    • greymalik 1y ago
      How is it different from subagents?
      • simonw 1y ago
        They complement each other. Subagents are mainly a token context optimization hack. They're a way for Claude Code to run a bunch of extra tools calls (e.g. to investigate the source of a bug) without consuming many tokens in the parent agent loop - the subagent gets its own loop, can use up to ~240,000 tokens exploring a problem and can then reply back up to the parent agent with a short description of what it did or what it figured out. A subagent might use one or more skills as part of running. A skill might advise Claude Code on how best to use subagents to solve a problem.
      • SafeDusk 1y ago
        I like to think of subagents as “OS threads” with its own context and designed to hand off task to. A good use case is Cognition/Windsurf swe-grep which has its own model to grep code fast. I was inspired by it but too bad it’s closed for now, so I’m taking a stab with an open version https://github.com/aperoc/op-grep https://github.com/aperoc/op-grep.
• orliesaurus 1y ago
  Is this different from AGENTS.MD by OPENAI
  • simonw 1y ago
    Yes, it's different. AGENTS.md is a single file that is read by the LLM when the session starts. Skills are multiple .md files which are NOT read on startup - instead, the LLM harness scans them for descriptions and populates the context with those, such that it can later on decide to read the full skills/pdf/skill.md file because the user indicates they want to do something (like create a PDF) for which the skill is relevant. Plus skill folders can also include additional reference documents and executable scripts, like this one here: https://github.com/anthropics/skills/tree/main/document-skills/pdf https://github.com/anthropics/skills/tree/main/document-skil...
• Lerc 1y ago
  Do skills enable the AI to do things within it's contact, or does it grant the ability to process things in an entirely separate context. I was considering the merits of a news article analysts skill that processed the content adopting a variety of personas of opinions and degrees of adversarial attitudes in isolated contexts then bought the responses together into a single context to arbitrate the viewpoints impartially. Or even a skill for "where did this claim originate?". I'd love an auto Snopes skill.
• JV00 1y ago
  It's amazing how writing optimal guides for llms or humans is exactly the same. Even if a human doesn't want to use a LLM these skills markdowns could work as tutorials.
• luxuryballs 1y ago
  is there a community share directory of Claude skills somewhere yet? sounds promising
• joquarky 1y ago
  Does anyone else still keep everything super simple by just including .md files in project for guardrails and do all edits manually by file upload and clipboard? Sure, it's tedious, but I get to directly observe every change. I guess I just don't feel comfortable with more black box magic beyond the LLM itself.
  • sethops1 1y ago
    I just upload the file I want to change and the file with associated tests. Anything more than that and the ROI goes way down on slop generated. But I'll admit Gemini at least is getting good at "implement the function with a TODO describing what needs to be done". No need for anything but the Gemini file uploader, and copy pasting the results if they look good.
  • uxcolumbo 1y ago
    Don’t quite follow. So you only use the chat UI and copy and paste from there? Or do you use CC but don’t let it automatically update files?
• michael1999 1y ago
  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 loop was too long. If you wrote some docs, you might never learn if they were any good. If you did, it might be years later. And if you changed them, doing an A/B test was impractical. Now, you can write up a context markdown, ask Claude to do something, and iterate in minutes. 2) The tools can help build them. Building good docs was always hard. Especially if you take the time to include examples, urls, etc. that make the documentation truly useful. These tools reduce this cost. 3) Many programmers are egotists. Documentation that helps other people doesn't generate internal motivation. But documentation that allows you to better harness a computer minion to your will is attractive. Any other theories?
  • quinnjh 1y ago
    onboarding devs won’t risk looking dumb to complain about the bad docs, the authors already have a mental model, and writing them out fully helped others at expense of job security. When doling bad docs to a stupid robot, you only have yourself to blame for the bad docs. So I think it’s #2 + #3. The big change is replacability going from bad to desirable (replace yourself with agents before you are replaced with a cheaper seat)
  • Herring 1y ago
    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.
    • ashleyn 1y ago
      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.
    • 1y ago
• gtirloni 1y ago
  What's the cost from all the "figuring out" the model has to do to use a skill vs MCP?
• mercurialsolo 1y ago
  Skills again seem more like making MCPs more accessible for everyday users. It will again need to see evolution - things that are missing - containers for skills (you will need beyond a folder for sharing a toolchain with skills) - the orchestration and picking up of the skill is left to the LLM (the synthesis is done via the context shared in the skill - this feels a very sub-optimal pattern at the moment - low control) Few others like versioning, access control for tools which are missing. Real world skills come not just from practice but are opionated workflows built with specific toolchains too. IMO, this is half-ass engineered at the moment
• dr_dshiv 1y ago
  So, the skills files can be used by Codex, right?
  • simonw 1y ago
    Yes, even though Codex CLI doesn't (yet) know what a skill is. Tell it "Go read skills/pdfs/skill.md and then create me a PDF that does ..." and see what happens.
• losvedir 1y ago
  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?
  • manojlds 1y ago
    Skills seem to have code packaged in. They have added pdf, excel support using skills.
• deleted 1y ago
  [deleted]
• tuananh 1y ago
  For me Claude Skills is just a proof that we're making RAG unnecessary difficult to use. Not tech wise, but UX wise. But if we can fix that, the need for Claude Skills will go away. Where Claude Skills is better than MCP? It's easier to produce a Claude SKills. It's just text. Everyone can write it. But it's dependant on the environment alot. Eg: when you need to have certain tools available for it to work. How do you automate sandbox setup with that? Even that, are you sure it's the right version for it to use, etc...
• xwowsersx 1y ago
  FYI the gif is not visible to us. In the shared chat: > Perfect! I've created your Slack GIF! > [Files hidden in shared chats]
  • simonw 1y ago
    It's in the blog post (it's rubbish) - here's a direct URL: https://static.simonwillison.net/static/2025/skills_vs_mcps.gif https://static.simonwillison.net/static/2025/skills_vs_mcps....
    • xwowsersx 1y ago
      haha thanks, no lies detected... that is rubbish :)
• didibus 1y ago
  I'm not sure I totally see the disdain for MCP. These skills also rely on tools, having a standard way to add tools to an agent is good, otherwise each agent has its own siloed tools. But also, I remember MCP having support for resources no? These skills are just context (though I guess it can include executable scripts to help, but the article said most skills are just an instruction markdown). So you could already have an MCP expose skills as resources, and you could already have the model automatically decide to include a resource based on the resource description. Now I understand to add user created resources is pretty annoying, and maybe it's not great for people to easily exchange themselves resources. But you assume that Slack would make the best context to generate Slack gifs, and then expose that as a resource from their MCP along with a prompt template and some tools to help or to add the gif to your slack as emojis or what not. You could even add Skills specifically to MCP, to that you can expose a combination of context resources and scripts or something. That said, I agree that the overabundance for tools as MCP is not that good, some tools are so powerful, they can cover 90% of all other tool use cases. Bash tool can do so many things. A generic web browsing tool as well. That's been the problem with MCP as tools. Skills appear to be a good technique as a user, and I actually already did similar things. I like formalizing it, and it's nice that Claude Code now automatically scans and includes their description header for the model to know it can load the rest. That's the exciting part. But I do feel for the more general public, MCP resources + prompts + tools are a better avenue.
• tictacttoe 1y ago
  You don’t need skills to build progressively detailed context. You can do this with MCP.
• noisy_boy 1y ago
  Soon we will have a skills marketplace that allows you to sell you skill of being able to make the AI more skilled.
• poopiokaka 1y ago
  [flagged]
  • simonw 1y ago
    I'm not. Here are my disclosures: https://simonwillison.net/about/#disclosures https://simonwillison.net/about/#disclosures And if my disclosures aren't enough for you, here's the FTC explaining how it would be illegal for an AI vendor to pay someone to write something like this without both sides disclosing the relationship: https://www.ftc.gov/business-guidance/resources/ftcs-endorsement-guides-what-people-are-asking#ftcactapply https://www.ftc.gov/business-guidance/resources/ftcs-endorse...
    • hollowturtle 1y ago
      > I have not accepted payments from LLM vendors, but I am frequently invited to preview new LLM products and features from organizations that include OpenAI, Anthropic, Gemini and Mistral, often under NDA or subject to an embargo. This often also includes free API credits and invitations to events. You don't need money, just incentives and network effects
      • simonw 1y ago
        I quote, "Bro is paid to write this". And yeah, blogging does kind of work on incentives. If I write things and get good conversations as a result, I'm incentivized to write more things. If I write something and get silence then maybe I won't invest as much time in the future.
    • hansmayer 1y ago
      While it's very honest of you to disclose in full your various affiliations to the LLM vendors, and it does look like you're not being paid by them - the reason they are inviting you for the early previews and all that is precisely because they either expect or assume you won't go to critical on them. And that shows in your writing to be honest. I'd assume the same in their place. So yeah, not paid obviously, but it seems indirectly incentivised to not be as critical as one could be...
• Lokman 1y ago
  my understanding is the "skills" are manually written can we prompt claude to edit and improve it's skills too?
  • simonw 1y ago
    Yes, Anthropic even published a skill for that: https://github.com/anthropics/skills/blob/main/skill-creator/SKILL.md https://github.com/anthropics/skills/blob/main/skill-creator...
• napierzaza 1y ago
  [dead]
• sidgarimella 1y ago
  Stumbled on to a similar concept a few years ago, I think there was a paper around some kind of proto code skills for Minecraft around then... awesome to see Anthropic pursue this direction https://www.prefix.app/blog/is-chat-the-future https://www.prefix.app/blog/is-chat-the-future
• aussieguy1234 1y ago
  If I'm going to fix my car, I might read the car manual first. But if I'm not fixing my car and just walking past the bookshelf, I'll only see the title of the book.
• rane 1y ago
  So far not impressed with CC's ability to invoke skills automatically. I made a skill with the unambiguous description: "Use when creating or editing bash scripts" Yet, Claude does not invoke the skill when asked to write a bash script. https://gist.github.com/raine/528f97375e125cf97a8f8b415bfd802e https://gist.github.com/raine/528f97375e125cf97a8f8b415bfd80...
  • AmbroseBierce 1y ago
    Try writing it like this: "Use it when creating a bash script or editing a bash script"
  • simonw 1y ago
    Hah, yeah that's a total miss there. Maybe it messed that up because writing bash scripts is so core to how Claude Code works? Much of the existing system prompt (and I bet a lot of the fine-tuning data) is about how to use the Bash tool.
    • rane 1y ago
      For good measure, I tried: description: CRITICAL: Use when writing bash scripts Surprisingly no effect either. I would've thought adding "CRITICAL" would somehow promote that instruction in the sea of context.
• ajay_as 1y ago
  [dead]
• giorgioz 1y ago
  What useful Claude Code Skills have you made so far?
  • simonw 1y ago
    I've tried: 1. A skill for refactoring code using ast-grep 2. A skill for searching code using my Symbex tool 3. A skill for building Datasette plugins None of them feel quite good enough to share yet, I'm still exploring what patterns work the best.
• consumer451 1y ago
  > Over time the limitations of MCP have started to emerge. The most significant is in terms of token usage: GitHub’s official MCP on its own famously consumes tens of thousands of tokens of context, and once you’ve added a few more to that there’s precious little space left for the LLM to actually do useful work. Supabase MCP really devours your context window. IIRC, it uses 8k for its search_docs tool alone, just on load. If you actually use search_docs, it can return >30k tokens in a single reply. Workaround: I just noticed yesterday that Supabase MCP now allows you to choose which tools are available. You can turn off the docs, and other tools. [0] If you are wondering why you should care, all models get dumber as the context length increases. This happens much faster than I had expected. [1] [0] https://supabase.com/docs/guides/getting-started/mcp https://supabase.com/docs/guides/getting-started/mcp [1] https://github.com/adobe-research/NoLiMa https://github.com/adobe-research/NoLiMa
  • causal 1y ago
    It's also not clear to me why using "skills" would consume less context once invoked. It's just instructions with RAG. The more I read about this the more convinced I am that this is just marketing.
    • habitue 1y ago
      Skills wont use less context once invoked, the point is that MCP in particular frontloads a bunch of stuff into your context on the entire api surface area. So even if it doesn't invoke the mcp, it's costing you. That's why it's common advice to turn off MCPs for tools you dont think are relevant to the task at hand. The idea behind skills us that they're progressively unlocked: they only take up a short description in the context, relying on the agent to expand things if it feels it's relevant.
      • consumer451 1y ago
        Your reply unlocked some serious, yet simple understanding for me. Thank you.
• djohnston 1y ago
  What's the difference between skills and slash commands? Skills are picked up and selected implicitly by the chat? Anything else?
  • manojlds 1y ago
    Did you mean explicitly?
    • djohnston 1y ago
      No but I understand the confusion. Explicit = "type a slash command" , explicitly instructed by the user. Implicit means, LLM will pick this on behalf of the user without the user's explicit instruction to do so. Maybe not the best choice of words but that was what I was getting at.
• AmbroseBierce 1y ago
  They are awesome when you made them and work in the current version of things, I'm sure they can quickly become obsolete and the skills could soon no longer apply and you have to sit down and check what skill is failing and why, so it becomes another layer more of technical debt.
• magic_hamster 1y ago
  An MCP server doesn't have to have "simple" tools. Having very powerful and effective tools allows you to create great context for the LLM. I don't see any way Skills are better then this; on the contrary, now the "tool executive" is more dependent on the model, introducing non-deterministic context issues. In the same vein, tools are also easy to iterate on, they are quite simple to implement, and their description is entirely up to you - you can limit how many tokens this description will consume. This feels like going in the wrong path in a way, but we'll see how this evolves and what are the use cases.
• aiiizzz 1y ago
  > Anthropic this morning... Wow, it hasn't even been a day, and a bold declaration.
• OJFord 1y ago
  Why are Skills being compared to MCP everywhere; not Projects, context, chat separation? Wouldn't you (potentially) give different MCP tools to different Skills even?
  • trvz 1y ago
    To confuse the people who hold the money and power, so they won't notice how simplistic all this really is.
• 3371 1y ago
  So... cursor rule file, in folder form?
• fennecbutt 1y ago
  Imo MCP is only a big deal because of marketing. Not usefulness.
• Western0 1y ago
  on android I can setup what my phone uses my acessories/ wifi, file, acellometer, BT, GPS etc.) I need this sme security settings for gents, cli , skils etc.
• wonderfuly 1y ago
  A curated list of Claude Skills: https://mcpservers.org/claude-skills https://mcpservers.org/claude-skills
• Leofierus 1y ago
  Can someone dumb down MCP for me please? I still don't get it after going through blogs and AI.
  • djdjsjejb 1y ago
    core feature is "tool calls", in developer terms it is api access for llms, so when you talk to llm, they can use that api access to find information or do actions in your behalf. mcp is the standardized way to do it so you can just switch llm vendors and it still works