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:**