| 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:
-
Fetch the documentation index:
WebFetch("https://modelcontextprotocol.io/llms.txt", "Return the full content as-is")
-
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
-
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.
