Provides access to Express documentation and code examples, allowing users to fetch up-to-date library documentation.
Provides access to MongoDB documentation and code examples, allowing users to fetch up-to-date library documentation.
Provides access to Next.js documentation and code examples, allowing users to fetch up-to-date library documentation.
Provides access to React documentation and code examples, allowing users to fetch up-to-date library documentation.
Provides access to Supabase documentation and code examples, allowing users to fetch up-to-date library documentation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@stdio-context7 what's the latest documentation for React?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Alternative Context7 MCP implementation built to work with Claude Code via Docker MCP Toolkit
An alternative implementation of the Context7 MCP server, designed to work seamlessly with Claude Code via Docker MCP Toolkit. This version provides up-to-date library documentation and code examples through STDIO transport, addressing connectivity issues with the original Context7 server in Docker MCP environments.
This repository is also a Claude Code plugin marketplace. Installing the plugin registers the stdio-context7 MCP server with Claude Code, Cowork, and the Claude desktop app chat.
/plugin marketplace add tobymarsden/stdio-context7-mcp-server
/plugin install stdio-context7@stdio-context7-mcp-serverOr, for local development of the plugin:
claude --plugin-dir /path/to/stdio-context7-mcp-serverThe plugin runs a self-contained bundle, plugin/server.cjs, with node ${CLAUDE_PLUGIN_ROOT}/plugin/server.cjs. It needs only Node.js 20 or newer on the PATH: no Docker, no npx, no network install. Rebuild the bundle after changing src/ with:
npm run build:pluginTo use a Context7 API key for higher rate limits, set CONTEXT7_API_KEY in the environment the Claude app inherits. The key is optional.
The plugin files are:
.claude-plugin/plugin.json - plugin manifest
.claude-plugin/marketplace.json - marketplace manifest
.mcp.json - MCP server definition used by the plugin
plugin/server.cjs - bundled server (built from src/ by npm run build:plugin)
This fork fixes three things that stop @dolasoft/stdio-context7-mcp-server@1.0.1 working as a plugin MCP server:
resolve-library-id sent ?q= to the Context7 search API, which now requires ?query= and returned 400, surfaced as "Library not found".
The server exited after 5 minutes idle. Hosts such as the Claude desktop app keep stdio servers alive between calls and do not restart them, so the tools disappeared. The idle timeout is now off unless INACTIVITY_TIMEOUT_MS is set.
Log output went to stdout, which is the MCP JSON-RPC channel. All console output now goes to stderr when using the stdio transport.
Related MCP server: Context7 MCP Server
This is an alternative MCP server to the original Context7, specifically created to solve connectivity issues with Docker MCP Toolkit. Built with the specific goals of:
Docker MCP Toolkit Compatible: Works reliably with Claude Code via Docker Desktop's MCP infrastructure (where the original doesn't)
Claude Code Optimized: First-class support for Claude Code IDE workflows
Enhanced STDIO Transport: Direct, efficient communication via standard input/output
Production-Ready Security: Enterprise-grade Docker image with SBOMs, provenance, and signing support
Universal Compatibility: Works with all MCP-compatible AI assistants (Claude, Cursor, Windsurf, etc.)
🐳 Docker MCP Toolkit Native: Built for Docker Desktop MCP integration
🤖 Claude Code First: Optimized for Claude Code IDE workflows
🔍 Library Resolution: Resolve library names to Context7-compatible IDs
📚 Documentation Retrieval: Fetch up-to-date documentation and code examples
🎯 Topic Filtering: Focus on specific topics within libraries
⚡ STDIO Transport: Fast, local integration with MCP clients
🐳 Production Docker: Multi-arch with SBOMs, provenance, and security hardening
🔐 Enterprise Security: Non-root user, minimal attack surface, Alpine Linux base
🌍 Multi-Architecture: Supports amd64 and arm64 platforms (Intel, AMD, Apple Silicon)
🔄 Universal Compatibility: Works with Cursor, Windsurf, and other MCP clients
Node.js >= 20.8.1
npm >= 10.0.0
Docker (optional, for containerized deployment)
npm install -g @dolasoft/stdio-context7-mcp-server# Pull the official image
docker pull dolasoft/stdio-context7-mcp:latest--api-key <key>: Context7 API key for authentication (optional, get one at context7.com/dashboard for higher rate limits)
This server is built for Docker MCP Toolkit and integrates seamlessly with Claude Code. Using Docker provides the most reliable and secure deployment option.
For Docker Desktop MCP:
{
"mcpServers": {
"stdio-context7": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--stop-timeout",
"10",
"dolasoft/stdio-context7-mcp:latest"
]
}
}
}This server is optimized for Claude Code via Docker MCP Toolkit. Add to your MCP configuration:
{
"mcpServers": {
"stdio-context7": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--stop-timeout",
"10",
"dolasoft/stdio-context7-mcp:latest"
]
}
}
}With API Key (for higher rate limits):
{
"mcpServers": {
"stdio-context7": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--stop-timeout",
"10",
"dolasoft/stdio-context7-mcp:latest",
"--api-key",
"YOUR_CONTEXT7_API_KEY"
]
}
}
}Get your free API key at context7.com/dashboard
Pro tip: Add this to your CLAUDE.md for automatic Context7 usage:
## Context7 Integration
Use the stdio-context7 MCP server for library documentation and code examples.
Always use `resolve-library-id` first, then `get-library-docs`.For Claude Desktop, Cursor, Windsurf, or any MCP-compatible client:
{
"mcpServers": {
"stdio-context7": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--stop-timeout",
"10",
"dolasoft/stdio-context7-mcp:latest"
]
}
}
}With API Key:
{
"mcpServers": {
"stdio-context7": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--stop-timeout",
"10",
"dolasoft/stdio-context7-mcp:latest",
"--api-key",
"YOUR_CONTEXT7_API_KEY"
]
}
}
}Resolves a general library name into a Context7-compatible library ID.
Parameters:
libraryName (required): The name of the library to search for
Example:
{
"libraryName": "react"
}Response:
Found library: React
Library ID: /facebook/react
Description: A JavaScript library for building user interfacesFetches documentation for a library using a Context7-compatible library ID.
Parameters:
context7CompatibleLibraryID (required): Exact library ID (e.g., /mongodb/docs)
topic (optional): Focus docs on a specific topic (e.g., "routing", "hooks")
tokens (optional): Max tokens to return (default: 5000, minimum: 1000)
Example:
{
"context7CompatibleLibraryID": "/facebook/react",
"topic": "hooks",
"tokens": 3000
}Response:
# React Documentation
A JavaScript library for building user interfaces
## Topic: hooks
This section focuses on hooks in React.
## Getting Started
Here you would find comprehensive documentation and examples for React.Simply mention the library in your prompt and ask the AI to use context7:
Create a Next.js middleware that checks for a valid JWT. use context7Or reference a specific library ID:
Implement authentication with Supabase. use library /supabase/supabaseThis server uses the real Context7 API and supports all libraries available in the Context7 ecosystem. Simply use the resolve-library-id tool to find any library, including:
React (/facebook/react) - UI library
Next.js (/vercel/next.js) - React framework
Express (/expressjs/express) - Node.js web framework
MongoDB (/mongodb/docs) - Database documentation
Supabase (/supabase/supabase) - Backend platform
And thousands more...
The server fetches up-to-date documentation directly from Context7's live API.
The Docker image is built with enterprise-grade security:
Non-root user (UID 1001)
Multi-architecture: amd64, arm64
SBOMs & Provenance: Full supply chain transparency
Alpine Linux: Minimal attack surface
Regular updates: Automated security patches
Server not responding?
Verify Docker is running: docker ps
Check MCP client logs for connection errors
Ensure correct image: docker pull dolasoft/stdio-context7-mcp:latest
Library not found?
Always use resolve-library-id first to find the correct library ID
Ensure library ID format is correct (e.g., /org/repo)
MIT License - see LICENSE file for details
Powered by Context7 API by Upstash
Built with Model Context Protocol
Built for the MCP community and Docker MCP Toolkit
Fetches documentation for a library using a Context7-compatible library ID.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Focus the docs on a specific topic (e.g., "routing", "hooks") | |
| tokens | No | Max number of tokens to return. Values less than 1000 are automatically increased to 1000. | |
| context7CompatibleLibraryID | Yes | Exact Context7-compatible library ID (e.g., /mongodb/docs, /vercel/next.js) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses only that documentation is fetched, with no details about return format, error behavior, pagination, or possible side effects. For a read operation with no annotation safety signals, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the key constraint without any filler. It is appropriately sized for a simple fetch operation and contains no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema coverage, the description plus schema are mostly adequate. However, with no output schema, no annotations, and an unresolved sibling relationship, the description does not explain what the returned documentation looks like or how the ID should be obtained. This is a clear but not critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters clearly, including the required library ID format and token clamping behavior. The description itself adds no parameter-level meaning beyond the ID requirement, which matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') and resource ('documentation for a library'), and notes the required input is a 'Context7-compatible library ID'. It is clear about the core operation, though it does not explicitly differentiate itself from the sibling tool resolve-library-id beyond implying that this tool consumes an already-compatible ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus resolve-library-id, nor any mention of needing to resolve a library ID first. The sibling tool's existence makes this gap more significant; an agent is left to infer the relationship between the two tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves a general library name into a Context7-compatible library ID.
| Name | Required | Description | Default |
|---|---|---|---|
| libraryName | Yes | The name of the library to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as whether it performs network calls, may fail for unknown libraries, or returns null/throws errors. The description is minimal and leaves the agent guessing about failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action and output. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one parameter and no output schema, but the description lacks important context: error handling for unknown libraries, whether the ID is required for get-library-docs, and any input format nuances. Given the sibling tool exists, more guidance on the workflow would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter fully, but the description adds minimal value beyond what the schema says; it just says 'general library name' which slightly clarifies that the input is a general name, not a specific ID. With 100% coverage, a score of 3 is baseline, but the added context is marginal; the description does not explain what format the library name should be (e.g., exact case, version suffix), so it drops to 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a general library name into a Context7-compatible library ID, specifying the verb (resolve), resource (library name), and output (ID). It is specific but does not explicitly differentiate from the sibling 'get-library-docs', though the different output type (ID vs docs) implies a distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need the internal ID before fetching docs, but it does not explicitly state when to use it versus get-library-docs. It could be clearer by saying 'Use this before get-library-docs to obtain the required ID.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1get-library-docsresolve-library-idScored across 2 tools
The two tools have completely distinct purposes: one resolves a library name into an ID, the other fetches docs using that ID. There is no overlap or ambiguity between them.
Both tools follow the same verb_noun pattern with snake_case (resolve-library-id, get-library-docs). Naming is consistent and predictable.
With only 2 tools, the server feels thin for a general-purpose documentation service, especially as it may need more discovery tools. However, for a focused workflow (resolve then fetch), this count is borderline acceptable.
The core workflow of resolving a library ID and fetching its docs is covered without dead ends. A minor gap is lack of searching or listing libraries, but the stated purpose is fetch docs, so the surface is nearly complete.
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Find open-source libraries and fetch contextual code snippets by version to accelerate development…
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Versioned documentation registry and semantic search for AI tools and coding assistants.