How do I install the MCP Docs skill?

Run npx skillmds@latest add modelcontextprotocol/mcp-docs in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is MCP Docs safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with MCP Docs?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is MCP Docs free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published MCP Docs?

modelcontextprotocol (@modelcontextprotocol) published this skill. Their other Agent Skills are listed on their SkillMD profile.

MCP Docs by modelcontextprotocol — Agent Skill

Name: MCP Docs
Author: modelcontextprotocol

MCP Docs

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.

File contents

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.

---name: mcp-docsdescription: 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.---# MCP Documentation SkillProvides 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/servers3. Fetch the specific page: ``` WebFetch("<page-url>", "Return the full content of this documentation page") ```### Version handlingAlways 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.

Frequently asked questions