| name | mcp-docs |
| description | Fresh library and framework documentation lookup through MCP documentation providers such as Context7. Use when implementation depends on current APIs, SDK behavior, framework conventions, setup steps, or migration details for libraries and platforms. |
| argument-hint | library, framework, API, version, error, or implementation question |
| license | MIT |
| metadata | {"category":"research","tags":["mcp","context7","documentation","libraries"],"effort":"medium","side_effect":"external-read","explicit_invocation":false} |
MCP Docs
Use this skill when stale or guessed library knowledge could affect the implementation.
Primary Source
Prefer MCP documentation tools, especially Context7 when available:
- Resolve the library ID for the package, framework, or platform.
- Query the docs with the narrow implementation question.
- Record the source library ID and the relevant decision in the working notes, plan, or review report.
If MCP documentation is unavailable, use official project documentation as fallback and state that the MCP source was unavailable.
Use Before
- Adding or upgrading dependencies.
- Writing integration code against SDKs, auth providers, payment APIs, deployment platforms, UI frameworks, ORMs, queues, or browser APIs.
- Fixing failures that may be caused by version drift.
- Choosing framework-specific conventions in
/bugfix, /refactor, /infra, /deploy, /deps-audit, or /harden.
Output
Return:
DOC SOURCE:
VERSION OR LIBRARY ID:
DECISION:
IMPLEMENTATION IMPACT:
FOLLOW-UP RISK:
Self-validation
Before final output, verify:
- Route, side-effect, and confirmation requirements match metadata.
- Required artifacts or read-only result are explicit.
- Verification, blockers, and next route are stated.
Rules
- Do not send secrets, proprietary source snippets, credentials, or private customer data to documentation tools.
- Prefer official or high-reputation documentation results.
- Keep queries narrow enough to answer the task at hand.
- Do not block tiny local fixes when the relevant API behavior is already proven by tests or code.
- If docs conflict with repository conventions, explain the conflict and prefer the repository convention unless it is broken or deprecated.
