diff --git a/docs/approaches.md b/docs/approaches.md index 4acea04..ddd6c43 100644 --- a/docs/approaches.md +++ b/docs/approaches.md @@ -6,7 +6,15 @@ Whatever approach is adopted, community members have highlighted several principles: -> "There should be intentional focus on making it easy for server authors to create and expose skills... client hosts are strongly incentivized to have a relatively uniform way to discover and consume them — at least from the point of view of a server author — while also leaving room for client host innovation." — [Peder Holdgaard Pedersen](https://github.com/PederHP) +> "There should be intentional focus on making it easy for server authors to create and expose skills... client hosts are strongly incentivized to have a relatively uniform way to discover and consume them — at least from the point of view of a server author — while also leaving room for client host innovation. +> +> I also don't like creating dichotomy between first-class skills and skills as context, because pretty much everything an MCP server exposes is context. Skills-as-resources is much more accurate." — [Peder Holdgaard Pedersen](https://github.com/PederHP) + +Additional design considerations raised by community members: + +- **MCP is fundamentally about context, not just tools.** Skills are part of a broader challenge around context-as-resources discoverability and standardization of client host behavior. Framing skills as context-as-resources avoids creating artificial hierarchies between skills and other MCP primitives. +- **Don't be too prescriptive about client host behavior.** Client hosts may want to innovate on how skills are utilized (e.g., progressive disclosure) and what they can even *be*. The goal is uniform discovery and consumption patterns from the server author's perspective, while leaving room for client-side innovation. +- **Don't assume how tool paradigms will evolve.** The conceptual surface of skills shouldn't bake in assumptions about how tools develop. That doesn't preclude skills being implemented as a well-known tool, but the design should not couple skills to any particular tool evolution path. ## Central Tension: Convention vs. Protocol Extension diff --git a/docs/open-questions.md b/docs/open-questions.md index 3df06a1..d1c96e6 100644 --- a/docs/open-questions.md +++ b/docs/open-questions.md @@ -6,22 +6,14 @@ Should skills be discoverable through registry metadata ("if you install this se ## 2. How do "first-class" skills differ from "skills as context"? -Native agent skills can be presented through the user agent, bundled with subagents, etc. Do MCP-surfaced skills lose capabilities compared to directly installed skills? +'Native' agent skills can be presented through the user agent, bundled with subagents, etc. Do MCP-surfaced skills lose capabilities compared to directly installed skills? This question also ties into a more general topic about context-as-resources discoverability and standardization of client host behavior — it's not just a skills-specific framing question. -**Community input:** - -> "The only slight concern I have is the idea that there are still 'first class skills' (skills that agents recognize as skills, can be presented as skills through the user agent, can be bundled with subagents, etc) and these sort of 'skills as context' approaches where the agent can certainly discover and ingest the skills data, but possibly with some differences compared to how they would apply first class skills." — [Bob Dickinson](https://github.com/TeamSparkAI) - -> "I don't like creating dichotomy between first-class skills and skills as context, because pretty much everything an MCP server exposes is context. Skills-as-resources is much more accurate." — [Peder Holdgaard Pedersen](https://github.com/PederHP) +For more community input on this topic see: (approaches.md#design-principles) ## 3. Should server.instructions be extended for richer content? Or is the separation between "primitive server" and "skill that uses the primitive" the right abstraction? -**Community input:** - -> "I would caution against seeing skills as too tightly coupled with tools. Not all skills need to be related to the tools on a server — or even client-side tool use at all. This is especially true for agents that use very broad tools or heavily reliant on code interpreter and similar meta-tools." — [Peder Holdgaard Pedersen](https://github.com/PederHP) - ## 4. How should skills relate to multiple servers? A skill orchestrating tools from several servers can't live in any single server's instructions. diff --git a/docs/problem-statement.md b/docs/problem-statement.md index a751f5b..5bce488 100644 --- a/docs/problem-statement.md +++ b/docs/problem-statement.md @@ -9,6 +9,10 @@ - **No discovery mechanism** — users installing MCP servers from a registry don't know if there's a corresponding skill they should also install - **Multi-server orchestration** — skills may need to coordinate tools from multiple servers, which doesn't fit the single-server instruction model +## Broader Context + +Skills discoverability is a specific instance of a more general MCP challenge: context-as-resources discoverability and standardization of client host behavior around non-tool primitives. The ecosystem has largely optimized for tools, and patterns for how clients discover and consume other forms of context — including skills — remain underdeveloped. Solutions in this space are likely to have implications beyond skills alone. + ## Key Use Cases See [use-cases.md](use-cases.md) for detailed use cases and community input. In summary: