[deleted]
Claude Skills are awesome, maybe a bigger deal than MCP
231–240 of 383 posts
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#232We'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…
It is primarily a principal agent problem, with a hint of marshmallow test.
If you are a developer who is not writing the documents for consumption by AI, you are primarily writing documents for someone who is not you; you do not know what this person will need or if they will ever even look at them.
They may, of course, help you, but you may not understand that, have the time, or discipline.
If you are writing them because the AI using them will help you, you have a very strong and immediate incentive to document the necessary information. You also have the benefit of a short feedback loop.
Side note, thanks to the LLMs penchant of wiping out comments, I have a lot more docs these days and far fewer comments.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#233Earlier quoted context omitted.
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
I remain afraid of prompt injection. If I'm telling Claude Code to retrieve data from issues in public repos there's a risk someone might have left a comment that causes it to steal API keys or delete files or similar.
I'm also worried about Claude Code making a mistake and doing something like deleting stuff that I didn't want deleted from folders outside of my direct project.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#234For 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...
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#235Earlier quoted context omitted.
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
"Tool calls is 20% of MCP, at maximum"
What else is there? I know about resources and prompts but I've seen almost no evidence of people actually using them, as far as I can tell tools are 90% of the usage of MCP, if not more.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#236I'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…
Skills seem to have code packaged in. They have added pdf, excel support using skills.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#237Earlier quoted context omitted.
> 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
"Tool calls is 20% of MCP, at maximum" What else is there? I know about resources and prompts but I've seen almost no evidence of people actually using them, as far as I can tell tools are 90% of the usage of MCP, if not more.
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 management app.
> I know about resources and prompts but I've seen almost no evidence of people actually using them
these are features that MCP clients should implement and unfortunately, most of them still don't. The same for elicitation and sampling. Prompts, for example, are mostly useful when you use sampling, then you can create an agent from an MCP server.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#238Earlier quoted context omitted.
"Tool calls is 20% of MCP, at maximum" What else is there? I know about resources and prompts but I've seen almost no evidence of people actually using them, as far as I can tell tools are 90% of the usage of MCP, if not more.
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.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#239FYI the gif is not visible to us. In the shared chat:
> Perfect! I've created your Slack GIF! > [Files hidden in shared chats]
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#240Maybe 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
Here's the relevant documentation: https://docs.claude.com/en/docs/claude-code/skills#personal-... You can drop the new markdown files directly into your ~/.claude/skills directory.
Thank you! For some reason claude told me to mess around in ~/.claudeconfig or some made up directory or another