mcp-docs

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.