experimental-ext-skills

Background Open Question 4 asks how skills should relate to multiple servers. The dependency declaration schema is being actively developed in agentskills/agentskills#195. This issue focuses on the complementary question: given that a skill has declared dependencies, what should a conforming MCP host do with that information? The current field in the Agent Skills spec is freeform text — as noted in comments here, applications can't filter or act on it mechanically. That gap is what this issue addresses. Key community input:** "If [required tools/servers are] not available then the skill frontmatter shouldn't be loaded into model context, as it is effectively not an available skill." — Peder Holdgaard Pedersen "npx skills is ok for simple use-cases but doesn't work for dependencies across Skill — i.e. if Skill 1 uses Skill 2." — Kaxil Naik Scope 1. Document requirements for host-mediated dependency resolution behavior, informed by the schema emerging from agentskills/agentskills#195 2. Analyze the gating question: should a skill whose dependencies are not satisfied be suppressed from model context entirely, or handled more softly? 3. Document soft vs. strict dependency semantics and their tradeoffs 4. Address offline/caching implications — a skill with satisfied dependencies should be cacheable for offline use 5. Identify what the declaration schema needs to include for a host to evaluate it mechanically (to feed back to agentskills/agentskills#195 as a requirement) Out of Scope The dependency declaration schema itself (tracked in agentskills/agentskills#195) Acceptance Criteria [ ] Analysis document or PR to expanding OQ #4 [ ] Documented host-side resolution requirements (even if informal/draft) [ ] At least 2 concrete examples showing how host resolution would work in practice [ ] Identified coordination needs with Agent Skills spec maintainers References Open Question 4 Use Case 3 — Multi-Server Composition agentskills/agentskills#110 agentskills/agentskills#195

Background Multiple implementations already use different URI patterns for skill resources. NimbleBrain uses skill://, others use file-path-based patterns like /SKILL.md. Before the convention can be finalized, there needs to be agreement on the URI scheme. Scope 1. Survey existing patterns: NimbleBrain: skill://server-name/skill-name (see experimental-findings.md) skilljack-mcp: tool-based pattern Agent Skills Discovery RFC: /.well-known/skills/ with index.json FastMCP 3.0: check gofastmcp.com/servers/providers/skills skills-over-mcp (Keith Groves): resource-based pattern 2. Propose a recommended pattern considering: Consistency with MCP resource URI conventions Compatibility with resource templates for parameterized access Ability to distinguish skills from other resources in resources/list Human readability 3. Document the proposal** with examples: Single skill: skill:///my-skill Versioned skill: skill:///my-skill?version=1.0 Skill from a specific domain: skill://example.com/my-skill Resource template: skill:///{skill_name} Acceptance Criteria [ ] Survey of at least 4 existing URI patterns with pros/cons [ ] Proposed recommended URI scheme with rationale [ ] At least 3 example URIs covering common cases [ ] PR to docs/approaches.md or a new section in the convention draft References Approach 6 in docs/approaches.md NimbleBrain pattern in experimental-findings.md Agent Skills Discovery RFC