Enhance design principles and open questions documentation with additional community insights on skills as context and discoverability challenges

Co-Authored-By: rektide <53243+rektide@users.noreply.github.com>

docs/approaches.md

@@ -15,12 +15,13 @@ Building on this, several design considerations are emerging from community disc
 - **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.
+- **Let the primitive choice follow from the use case.** The answer may not be "resources" or "new primitive" — it may be both, depending on the interaction pattern. Some skills are context for the model. Some are context for the human. Some are both. The delivery mechanism should support that range. ([See related thread on SEP 2076](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076#discussion_r2736299627))
 
 ## Central Tension: Convention vs. Protocol Extension
 
 The approaches below span a spectrum. At one end, skills become a first-class MCP primitive with dedicated protocol methods (Approach 1). At the other, existing primitives are used with documented conventions (Approach 6). A key question for this IG is whether convention can prove patterns before standardization — or whether the ecosystem needs protocol-level support to achieve reliable interoperability. These are not mutually exclusive; convention work can inform and de-risk a future protocol extension.
 
-## 1. Skills as MCP Primitives
+## 1. Skills as Distinct MCP Primitives
 
 Add Agent Skills as a first-class, discoverable primitive in MCP. A skill is a named bundle of instructions plus references to tools, prompts, and resources that together teach an agent how to perform a domain-specific workflow.
 
@@ -56,14 +57,19 @@ Add skill references to MCP registry entries so users know to install associated
 
 > "We view skills as an opportunity to use them as both a standalone (general-purpose capabilities) & MCP-paired (tool-specific guidance). For the main registry, the binding could be softer: optional fields like suggestedSkills or recommendedSkills rather than definitive pairing, since skill authorship is often decoupled from server authorship." — [Mat Goldsborough](https://github.com/mgoldsborough)
 
-## 3. Skills as Tools
+## 3. Skills as Tools and/or Resources
+
+Examples:
+
+- Expose skills via tools like `list_skills` and `read_skills`. Server instructions can direct the agent to call the skill tool first.
+- Expose skills as resources (e.g. skill://...), which can also be exposed through tools
 
-Expose skills via tools like `list_skills` and `read_skills`. Server instructions can direct the agent to call the skill tool first.
 
 **Implementations:** 
 
 - [skilljack-mcp](https://github.com/olaservo/skilljack-mcp)
 - [skills-over-mcp](https://github.com/keithagroves/skills-over-mcp)
+- [my-cool-proxy](https://github.com/karashiiro/my-cool-proxy)
 
 **Community input:**
 

docs/open-questions.md

@@ -84,6 +84,8 @@ Note: Some apps like Claude Code have started to indicate in the skill frontmatt
 
 > "If the conclusion is 'just use resources', I am fine with that direction too — but then we should standardize a way to identify and list workflow resources as 'skills' so clients can reliably surface them (otherwise we are back to out-of-band conventions)." — [sebthom](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2167#issuecomment-3824771018)
 
+See also [Approaches](approaches.md) for more notes on using resources.
+
 ## 13. What is the optimal relationship between skills and MCP?
 
 Skills already work as simple files that agents load directly. Adding MCP to the process should provide clear value beyond what standalone skills already offer.
@@ -93,3 +95,5 @@ Skills already work as simple files that agents load directly. Adding MCP to the
 > "Skills are simple files that agents can load directly even if they don't have any MCP servers connected. Adding MCP to the process only for that would be over complicating something that already works well... the question becomes 'what is the optimal relationship between skills and MCP?'" — [Cliff Hall](https://github.com/cliffhall)
 
 >  "Skills can be benefit from MCP Servers as an "official" distribution channel from an organizations. Also, Skills _can be_ dependendent on the specific tools _only_ available on the MCP server they are distributed with. I see Skills and MCP are complementary to each other." — [Yu Yi](https://github.com/erain)
+
+> "MCP servers are most useful as an appendage of skills, like `scripts/` are. That also naturally answers the question of multi-server skills." — [Jonathan Hefner](https://github.com/jmhefner)