mcp-docs: Скилл для работы с протоколом MCP

--- name: mcp-docs description: > Fetch live MCP specification and docs from modelcontextprotocol.io. Training data may be outdated — default to using this skill when the query touches MCP protocol in any way. Trigger for: implementing or debugging MCP features (sampling, elicitation, completion, tools, resources, prompts, transports); SEPs or spec requirements; MCP transport behavior (SSE, Streamable HTTP, reconnection, retry); authorization/OAuth; conformance test failures; capability negotiation; message schemas. Skip only for pure Kotlin, build system, or refactoring tasks with zero MCP protocol dependency. When in doubt, trigger. user_invocable: true --- # MCP Documentation Skill Provides access to the official MCP specification and docs from modelcontextprotocol.io. The spec evolves faster than training data — always consult live documentation for protocol specifics like message schemas, required fields, capability negotiation, error handling, and transport requirements. ## When to use **Proactively** (without being asked): - Implementing a feature defined in the MCP spec - Reviewing code that implements MCP protocol behavior - Fixing conformance test failures **On demand** (user asks or invokes `/mcp-docs`): - Questions about how a specific MCP feature works - Clarifying spec ambiguities - Looking up SEPs (Specification Enhancement Proposals) ## How to fetch documentation ### Strategy: MCP tool first, llms.txt fallback **Step 1 — Try the MCP search tool.** If `search_model_context_protocol` is available, use it: ``` search_model_context_protocol(query: "<your search query>") ``` One call, semantically ranked results. Fastest path. **Step 2 — Fallback to llms.txt + WebFetch.** If the MCP tool is not available: 1. Fetch the documentation index: ``` WebFetch("https://modelcontextprotocol.io/llms.txt", "Return the full content as-is") ``` 2. Identify the relevant page URL(s) from the index. Key sections: - **Specification**: `specification/...` — protocol details, message formats, transports, lifecycle - **SEPs**: `seps/...` — specification enhancement proposals - **Learning**: `docs/learn/...` — architecture, concepts - **Development**: `docs/develop/...` — building clients/servers 3. Fetch the specific page: ``` WebFetch("<page-url>", "Return the full content of this documentation page") ``` ### Version handling Always use the latest spec version by default. Only use a specific version or draft when the user explicitly requests it (e.g., "check the 2025-03-26 spec" or "what does the draft say"). ### Search guidance - Protocol message formats, required fields, capability negotiation → **Specification** section - Feature motivation, design rationale → relevant **SEP** - High-level concepts and architecture → **Learning** resources - Use your judgment on query count. A field-level question may need one page; implementing a feature may need 2-3. ## Presenting information - **Always cite sources.** Include links to spec pages used: `(source: <url>)` - **Spec over training data** for specific protocol details (schemas, fields, error codes, capabilities). Training data is fine for general MCP concepts. - **Preserve RFC 2119 language.** The spec uses MUST/SHOULD/MAY — keep this distinction when explaining requirements. - **Be concise.** Focus on the details relevant to the user's task. Avoid dumping entire spec pages — extract what matters for the specific question or implementation at hand.