4 ms·

Sub agents, mcp, skills - wonder how are they supposed to interact with each other? Feels like fair bit of overlap here. It's ok to proceed in a direction wher

Sub agents, mcp, skills - wonder how are they supposed to interact with each other? Feels like fair bit of overlap here. It's ok to proceed in a direction where you are upgrading the spec and enabling claude wth additional capabilities. But one can pretty much use any of these approaches and end up with the same capability for an agent. Right now feels like a ux upgrade from mcp where you need a json but instead can use a markdown in a file / folder and provide multi-modal inputs.

JyB 1y ago
Claude Skills just seem to be the same as MCP prompts: https://modelcontextprotocol.io/specification/2025-06-18/server/prompts https://modelcontextprotocol.io/specification/2025-06-18/ser... I don't really see why they had to create a different concept. Maybe makes sense "marketing-wise" for their chat UI, but in Claude Code? Especially when CLAUDE.md is a thing?
- datadrivenangel 1y ago
  Yeah how is this different from MCP prompts?
- pizza 1y ago
  Narrowly focused semantics/affordances (for both LLM and users/future package managers/communities, ease of redistribution and context management: - skills are plain files that are injected contextually whereas prompts would come w the overhead of live, running code that has to be installed just right into your particular env, to provide a whole mcp server. Tbh prompts also seem to be more about literal prompting, too - you could have a thousand skills folders for different softwares etc but good luck with having more than a few mcp servers that are loaded into context w/o it clobbering the context
- jjfoooo4 1y ago
  I see this as a lower overhead replacement for MCP. Rather than managing a bunch of MCP's, use the directory structure to your advantage, leverage the OS's capability to execute
  - JyB 1y ago
    I think you are right.
  - ebonnafoux 1y ago
    For me the concept of MCP was to have a client/server relation. For skills everything will be local.
- pattobrien 1y ago
  MCP Prompts are meant to be user triggered, whereas I believe a Skill is meant to be an LLM-triggered, use-case centric set of instructions for a specific task. - MCP Prompt: "Please solve GitHub Issue #{issue_id}" - Skills: - React Component Development (React best practices, accessible tools) - REST API Endpoint Development - Code Review This will probably result in: - Single "CLAUDE.md" instructions are broken out into discoverable instructions that the LLM will dynamically utilize based on the user's prompt - rather than having direct access to Tools, Claude will always need to go through Skill instructions first (making context tighter since it cant use Tools without understanding \*how\* to use them to achieve a certain goal) - Clients will be able to add infinite MCP servers / tools, since the Tools themselves will no longer all be added to the context window It's basically a way to decouple User prompts from direct raw Tool access, which actually makes a ton of sense when you think of it.
simonw 1y ago
I think those three concepts complement each other quite neatly. MCPs can wrap APIs to make them usable by an LLM agent. Skills offer a context-efficient way to make extra instructions available to the agent only when it needs them. Some of those instructions might involve telling it how best to use the MCPs. Sub-agents are another context management pattern, this time allowing a parent agent to send a sub-agent off on a mission - optimally involving both skills and MCPs - while saving on tokens in that parent agent.

JyB 1y ago

Claude Skills just seem to be the same as MCP prompts: https://modelcontextprotocol.io/specification/2025-06-18/server/prompts https://modelcontextprotocol.io/specification/2025-06-18/ser... I don't really see why they had to create a different concept. Maybe makes sense "marketing-wise" for their chat UI, but in Claude Code? Especially when CLAUDE.md is a thing?

datadrivenangel 1y ago
Yeah how is this different from MCP prompts?
pizza 1y ago
Narrowly focused semantics/affordances (for both LLM and users/future package managers/communities, ease of redistribution and context management: - skills are plain files that are injected contextually whereas prompts would come w the overhead of live, running code that has to be installed just right into your particular env, to provide a whole mcp server. Tbh prompts also seem to be more about literal prompting, too - you could have a thousand skills folders for different softwares etc but good luck with having more than a few mcp servers that are loaded into context w/o it clobbering the context
jjfoooo4 1y ago
I see this as a lower overhead replacement for MCP. Rather than managing a bunch of MCP's, use the directory structure to your advantage, leverage the OS's capability to execute
- JyB 1y ago
  I think you are right.
- ebonnafoux 1y ago
  For me the concept of MCP was to have a client/server relation. For skills everything will be local.
pattobrien 1y ago
MCP Prompts are meant to be user triggered, whereas I believe a Skill is meant to be an LLM-triggered, use-case centric set of instructions for a specific task. - MCP Prompt: "Please solve GitHub Issue #{issue_id}" - Skills: - React Component Development (React best practices, accessible tools) - REST API Endpoint Development - Code Review This will probably result in: - Single "CLAUDE.md" instructions are broken out into discoverable instructions that the LLM will dynamically utilize based on the user's prompt - rather than having direct access to Tools, Claude will always need to go through Skill instructions first (making context tighter since it cant use Tools without understanding \*how\* to use them to achieve a certain goal) - Clients will be able to add infinite MCP servers / tools, since the Tools themselves will no longer all be added to the context window It's basically a way to decouple User prompts from direct raw Tool access, which actually makes a ton of sense when you think of it.

simonw 1y ago

I think those three concepts complement each other quite neatly. MCPs can wrap APIs to make them usable by an LLM agent. Skills offer a context-efficient way to make extra instructions available to the agent only when it needs them. Some of those instructions might involve telling it how best to use the MCPs. Sub-agents are another context management pattern, this time allowing a parent agent to send a sub-agent off on a mission - optimally involving both skills and MCPs - while saving on tokens in that parent agent.