Skills that teach agents how to perform multi-step workflows that they wouldn't know how to execute from tool descriptions alone.
Example: Bob Dickinson's mcpGraph toolkit requires a skill file of 875+ lines to instruct agents on building directed graphs of MCP nodes. This orchestration logic is "way more than you'd want to put in instructions."
Community input:
"Skills may define how to use tools, possibly from different servers, to accomplish complex workflows requiring contextual reasoning that could not be coded with MCP tools." — Daniele Martinoli
Workflows that reference tools conditionally based on context, requiring rich structured instructions that can be dynamically loaded.
Example: A skill that guides an agent through different branches of a debugging workflow depending on the type of error encountered, loading relevant sub-instructions only when needed.
Skills that leverage tools from multiple off-the-shelf servers where you can't (or don't want to) modify their individual instructions. Skills can also make it more natural to translate ad-hoc tool-call-based workflows into scripted workflows, without fundamentally changing the content of the skill.
Related: agentskills/agentskills#110 — Skill dependency declaration
Community input:
"I think there might also be a subtle difference between the kind of skill that allows you to orchestrate a set of tools, possibly from different servers, to do something the agent wouldn't have necessarily known how to do without the skill (more of a skill registry issue), and the 'you're pretty much going to need this skill to make use of this server at all' (an MCP server registry issue, maybe)." — Bob Dickinson
"The ecosystem has been too focused on the server being the main deliverable in some ways, and actually there's a lot that can be done in terms of composition that we miss by people generally imagining their code as being the server boundary and not providing functionality more as a library." — Sam Morrow
Beyond multi-server tool orchestration, skills themselves may be composable — one skill depending on another skill's output or behavior. This extends the dependency model beyond tool availability to skill availability, and raises questions about declarative dependency metadata. See Open Question 4 for the emerging proposal on host-mediated dependency resolution.
See also: #39 — Skill dependency declaration, #45 — Worked examples for multi-server composition
Skills broken into linked sets of files for effective context management, loaded progressively as the agent needs them rather than all at once.
Community input:
"Especially mimicking progressive disclosure via resources and dynamically adding new ones as the agent reads pieces of the skill has been quite handy!" — Ozz / Juan Antonio Osorio
Practical limitation: In non-visual execution environments (CLI agents, headless), skills lack the "collapse" mechanism of UI-based progressive disclosure. Without a UI affordance to hide/show content, all disclosed context remains in the model's context window, contributing to the adherence decay problem (see Skill Reliability and Adherence). Tool-based expansion partially addresses this, since pruning a tool call also collapses the context, but this is not a general solution.
At scale: A server may expose hundreds or thousands of skills, but a client may only need a handful. This reinforces the need for selective loading via progressive disclosure rather than loading all skill content at once.
"A server can contain 100s or 1000s of skills as an extreme but a client might only need handful of them." — Kaxil Naik (Astronomer), via Discord
Related: Anthropic's guidance on progressive disclosure
See also: #45 — Worked examples for progressive disclosure, #40 — Client-side reference implementation for model-driven resource loading
Servers that are difficult or impossible to use effectively without an accompanying skill.
Community input:
"Clients of the registry presumably understand MCP, but there is no guarantee that they understand skills. So if it is going to be hard for an agent to use the server without the 'skill' then doesn't it make sense for the MCP server to contain all the instructions necessary to use it?" — Cliff Hall
Example: chrome-devtools-mcp ships with a skills/ folder that requires a separate install path from the MCP server itself.
Skills that evolve over time and need version-aware distribution.
Community input:
"I'd like for skills over MCP to enable the client to make use of the version attribute... If a skill stored locally has an older version than the skill seen on the MCP server, the client can download the latest skill on the spot." — woweow
Organizations building official MCP servers for established platforms are looking to skills as a distribution mechanism for domain-specific workflow guidance.
Community input:
"As part of Apache Airflow community, we are planning to build our official MCP Server... and I am specifically interested in integrating Skills as part of the MCP protocol." — Kaxil Naik
Related: Apache Airflow AIP-91 (MCP integration)
Skills whose instructions and examples dynamically adapt based on the platform or framework version in use, rather than versioning the skill artifact itself.
Example: Apache Airflow 2.x and 3.x have substantially different APIs, operators, and recommended patterns. A version-adaptive skill detects which Airflow version is running and returns only the relevant guidance — e.g., TaskFlow decorators in 2.x vs. updated Asset-based patterns in 3.x — so the agent never suggests deprecated or unavailable APIs.
Community input:
"As a SaaS company (Astronomer) building on Airflow, we need skills that adapt their content based on the Airflow version the customer is running. A skill that returns Airflow 2.x guidance to an Airflow 3.x user is worse than no skill at all. While skill reference files are valuable, a single version-aware skill that delivers tailored guidance is far more useful than hundreds of reference files where Airflow 2 and 3 diverge — best practices, recommended operators, and even DAG authoring patterns look fundamentally different between the two." — Kaxil Naik
SaaS companies serving per-user skill content that varies by subscription tier, role, or tenant — with auditing, logging, and RBAC governing what each user can access.
Example: A SaaS platform exposes the same MCP server endpoint to all customers, but a free-tier user receives basic workflow guidance while an enterprise user gets advanced optimization skills, custom operator libraries, and tenant-specific configuration — all controlled through RBAC policies and audit-logged per request.
Community input:
"At Astronomer we need to serve different skill content to different customers based on their subscription tier and role, with full audit logging. This goes beyond enterprise adoption — it's about multi-tenant commercial delivery of skills with fine-grained access control." — Kaxil Naik
MCP servers whose primary function is serving documentation through a small set of tools — typically a search tool (with a local or remote index) and a fetch tool (returning specific markdown pages). This pattern applies progressive disclosure to documentation: the model receives a list of available topics and selectively loads content as needed.
Examples:
- Strands Agents MCP server uses a local TF-IDF index for search and on-demand fetching of individual doc pages
- AWS Knowledge MCP server is a fully managed remote MCP server that indexes AWS documentation, code samples, and regional availability
- MCPDoc serves documentation via the llms.txt convention — listing titles so the model can selectively enable content
- Mintlify auto-generates MCP endpoints for public documentation sites (e.g., modelcontextprotocol.io/mcp, agentclientprotocol.com/mcp)
Skills connection: These doc servers often pair with skill-like instruction files that provide quick code samples and direct the agent to use the MCP server for deeper information. For example, the Strands Kiro powers bundle starter instructions alongside the MCP server.
Community input:
"I'm seeing a common pattern of MCP servers with two tools:
search_docs,fetch_doc.search_docshas either a local index or a remote index, andfetch_docsgenerally is just a web fetch of a specific markdown documentation page." — Clare Liguori (AWS), via Discord
Coding assistants are converging on plugin capabilities that let users one-click install a combination of skills and MCP servers. The skill files within these plugins serve different roles — some describe how to use the remote MCP server, while others describe how to use local CLIs or tools — but they're bundled and distributed as a single installable unit.
This is related to but distinct from Server-Skill Pairing: that use case focuses on servers that need skills to function; this one focuses on the distribution and composition mechanism that bundles skills with servers (and other tools) into a cohesive plugin.
Examples:
- Kiro uses "powers" and "steering files" — functionally the same as plugins + skills
- Supabase Kiro powers bundle skill files that describe both how to use the remote MCP server and how to use the Supabase CLI
- The AWS MCP server provides
retrieve_agent_sopandcall_awstools — the Agent SOPs are effectively skills that guide multi-step workflows through thecall_awstool
Community input:
"Several coding assistants incl Claude Code now have plugin capabilities that let you one-click install a combination of skills and MCP servers. Kiro calls them powers and steering files, but if you squint it's the same as plugins + skills." — Clare Liguori (AWS), via Discord