The Docfork server provides up-to-date documentation and code examples for over 9000 code libraries through its get-library-docs tool.
Retrieve Documentation: Fetch comprehensive documentation for any library by specifying the author/library name (e.g., "vercel/next.js", "shadcn-ui/ui")
Focus on Topics: Target specific topics within a library (e.g., "routing", "authentication", "hooks") to get relevant documentation and code examples
Control Output Size: Limit response length by specifying maximum token count to manage context size
Automatic Library Selection: Intelligently finds and selects the most relevant library based on the provided name
AI Integration: Integrates with various AI code editors and clients (Cursor, Claude, VS Code, JetBrains AI Assistant) via the Model Context Protocol (MCP)
The server returns detailed documentation with code examples directly from source, along with an explanation of the library selection process.
Provides alternative installation method using Bun package manager for users experiencing issues with NPX
Offers alternative runtime environment for running the Docfork MCP server when users encounter bundler issues
Supports containerized deployment of the Docfork MCP server with a provided Dockerfile configuration
Provides up-to-date documentation and examples for Next.js development, specifically mentioned in usage examples
Requires Node.js ≥ v18 as runtime environment, with native fetch API support
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., "@Docfork show me the latest React useState hook documentation"
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.
Docfork has shut down as of June 14, 2026.
The MCP server, CLI, and all hosted endpoints are offline and will not return. API keys no longer work, and npx dgrep setup will fail. Thank you to everyone who used the service.
AI agents hallucinate APIs, bloat context with stale docs, and write code against outdated signatures. Docfork serves up-to-date documentation directly in Cursor, Claude Code, and Windsurf.
app.use('/api/*', jwt({ secret: ... }))
- ^^^ removed in Hono v4 app.use('/api/*', bearerAuth({ verifyToken: ... }))
+ ^^^ current API, Hono v4.2npx dgrep setupInstalls the Docfork MCP server in your IDE. Detects your installed agents and writes the config file; sign in to Docfork on first use, no API key needed. Target one with --agent claude-code (also: cursor, codex, opencode, vscode, windsurf, amp, factory, zed).
Your agent now has two tools:
Tool | Returns |
| Ranked documentation sections with titles, URLs, and relevance scores. |
| Full rendered markdown content from a documentation URL. |
No prompt suffix needed:
Set up server-side rendering with Next.js App Router.Or search from the terminal:
dgrep search "middleware redirect based on authentication" -l vercel/next.js
dgrep search "server actions with forms" -l vercel/next.jsQuickstart → · dgrep docs → · CLI reference →
Index any public or private GitHub repository as a custom library. Your internal APIs, SDKs, and runbooks become searchable by your agents — same pipeline as public libraries. GitHub integration setup →
Related MCP server: Context7 MCP
Free: 1,000 requests/month per organization. For team rollout, commit the MCP config to your repo:
// .cursor/mcp.json (committed to git, picked up by every engineer)
{
"mcpServers": {
"docfork": {
"url": "https://mcp.docfork.com/mcp",
"headers": {
"DOCFORK_API_KEY": "YOUR_TEAM_API_KEY"
}
}
}
}Share API keys and Cabinets across your organization. Docfork doesn't store your code or prompts. Security → · Pricing →
Runnpx dgrep setup to install automatically (use --agent claude-code to target one). Manual config below for other clients.
Cursor —
{
"mcpServers": {
"docfork": {
"url": "https://mcp.docfork.com/mcp",
"headers": {
"DOCFORK_API_KEY": "YOUR_API_KEY"
}
}
}
}Claude Code
claude mcp add --transport http docfork https://mcp.docfork.com/mcp/oauthOpenCode
{
"mcp": {
"docfork": {
"type": "remote",
"url": "https://mcp.docfork.com/mcp",
"headers": { "DOCFORK_API_KEY": "YOUR_API_KEY" },
"enabled": true,
},
},
}Don't see your client? Setup guides for all 29 supported clients →
OAuth Authentication
Docfork supports MCP OAuth specs. Change your endpoint to use OAuth:
- "url": "https://mcp.docfork.com/mcp"
+ "url": "https://mcp.docfork.com/mcp/oauth"Note: OAuth is for remote HTTP connections only. View full OAuth guide →
Add a rule so your agent calls Docfork MCP automatically. Full rule and IDE-specific setup →
Claude Code — add to your CLAUDE.md:
## Docfork policy
Use Docfork MCP `search_docs` and `fetch_doc` tools for library/API docs, setup, and configuration questions.
- Start `library` with a short name or keyword (e.g., `nextjs`, `zod`). Use the `owner/repo` from the result URL for follow-up calls, never guess it upfront.
- After finding a relevant result, call `fetch_doc` to get the full content. Search results are summaries only.
- Prefer Docfork results over training data when they conflict.When writing or debugging code that involves third-party libraries, frameworks, or APIs, use Docfork MCP `search_docs` and `fetch_doc` tools rather than relying on training data.
**Two defaults to follow every time:**
- Start `library` with a short name or keyword (e.g., `nextjs`, `zod`). Use the `owner/repo` from the result URL for follow-up calls, never guess it upfront.
- After finding a relevant result, call `fetch_doc` to get the full content. Search results are summaries only.
Skip Docfork when:
- Language built-ins, general algorithms, syntax stable across versions
- Code or docs the user has already provided in context
When uncertain, default to using Docfork.How is Docfork different from Context7? Both provide MCP servers and CLIs for searching library documentation. Here are the key differences:
Stack scoping. dgrep init reads your package.json and scopes all searches to your declared dependencies. Cabinets let you version-pin those libraries across a team.
Resolve once, search many. dgrep init resolves package names to canonical identifiers once and caches the mapping in .dgrep/config.json. No per-query resolution step.
Hybrid search. Semantic search and BM25 run in parallel, fused via Reciprocal Rank Fusion. AST-aware chunking preserves function boundaries.
Does Docfork store my code or prompts? Your code and prompts never leave your machine. At search time, only the query and library name are sent to Docfork — queries are not stored. Indexed documentation content lives in an upstream vector store; private library content is end-to-end encrypted and deleted atomically when you remove the library. Security →
What libraries are supported? Docfork maintains a curated catalog of popular frameworks. Add any public or private GitHub repository as a custom library. Add custom libraries →
Found an issue? Open a GitHub issue or contact us.
MIT
Retrieves up-to-date documentation and code examples for any library. This tool automatically searches for the library by name and fetches its documentation.
Usage:
Provide the author and library name pair (e.g., "vercel/next.js", "shadcn-ui/ui", "vuejs/docs")
Specify a topic to focus the documentation on (e.g., "dynamic", "routing", "authentication")
The tool will:
Automatically find and select the most relevant library based on the provided name
Fetch comprehensive documentation for the selected library
Return relevant sections focused on the specified topic
Response includes:
Library selection explanation
Comprehensive documentation with code examples
Focused content if a topic was specified
| Name | Required | Description | Default |
|---|---|---|---|
| libraryName | Yes | Author and library name pair to search for and retrieve documentation (e.g., 'vercel/next.js', 'reactjs/react.dev', 'vuejs/docs') | |
| tokens | No | Maximum number of tokens of documentation to retrieve (default: 15000). Higher values provide more context but consume more tokens. | |
| topic | Yes | Topic to focus documentation on (e.g., 'hooks', 'routing', 'authentication') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: automatic library search, fetching comprehensive documentation, topic-focused returns, and response content details. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions.
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 well-structured with clear sections (purpose, usage steps, tool actions, response content). While slightly verbose, every sentence adds value by explaining different aspects of the tool's functionality. It could be more concise by combining some explanatory elements.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description provides good coverage of what the tool does, how to use it, and what to expect. It explains the automatic search behavior, response format, and parameter usage adequately, though it doesn't cover edge cases or error handling.
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 thoroughly. The description adds minimal value beyond the schema by mentioning the library name format and topic examples in the usage steps, but doesn't provide additional semantic context beyond what's in the schema descriptions.
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's purpose with specific verbs ('retrieves', 'searches', 'fetches') and resources ('documentation and code examples for any library'). It distinguishes the tool by explaining it automatically finds libraries by name and fetches comprehensive documentation, which is a complete and specific purpose statement.
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 provides implied usage through numbered steps and what the tool will do, but lacks explicit guidance on when to use this tool versus alternatives. Since there are no sibling tools mentioned, the absence of comparative guidance is less critical, but no explicit when/when-not instructions are provided.
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.0get-library-docsScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'get-library-docs' has a clearly defined and distinct purpose of retrieving documentation for libraries.
The single tool name follows a consistent verb_noun pattern ('get-library-docs'), making it predictable and readable. There are no other tools to compare against, so consistency is inherently perfect.
A single tool is too few for a server named 'Docfork', which implies a broader documentation-related scope. This minimal toolset feels thin and limits functionality, as it only supports fetching docs without related operations like searching, updating, or managing documentation sets.
The tool surface is severely incomplete for a documentation-focused server. It only provides retrieval ('get-library-docs'), missing essential operations such as searching documentation, listing available libraries, or updating cached docs, which are typical for such domains.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Versioned documentation registry and semantic search for AI tools and coding assistants.
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
