If you have ever asked an AI coding assistant about a library's API and received code that looked plausible but simply did not exist, you already understand the core problem. LLMs hallucinate method signatures, invent deprecated patterns, and confidently reference versions they were never trained on. The context7 MCP server is a direct response to that frustration.
Context7 integrates into your AI toolchain as a Model Context Protocol server, pulling version-specific documentation and live code examples from a curated index of popular libraries including Next.js, React, and Supabase, directly into the model's active context window. The result is grounded, accurate completions instead of confident guesswork.
In this tutorial, you will learn exactly what Context7 solves and why it matters, how its two core tools work under the hood, the difference between local and remote connection modes, and how to wire it into common MCP clients using ready-to-use config snippets. You will also get a realistic picture of library coverage, how Context7 stacks up against general web-fetch MCP alternatives, and the known limits you should plan around before shipping it into a production workflow.
The Problem Context7 Solves
Every LLM has a training cutoff date. Libraries do not stop shipping after that date. As frameworks evolve, the model generating your code has no knowledge of recent changes. The result is hallucinated API calls, code that references functions that no longer exist, written with complete syntactic confidence.
The failure mode is subtle. The code often compiles and may pass static analysis. The error surfaces at runtime, when the installed library responds to a method that has been renamed, moved, or removed. Debugging is slow because nothing in the code itself signals the mismatch.
General-purpose web-fetch MCP servers partially address this by retrieving live documentation from arbitrary URLs. The problem is filtering. A raw page fetch returns navigation chrome, versioning notices, community comments, and related-links noise alongside the actual API reference. The agent must extract the relevant signal from that full payload. A flooded catalog is not a curated one, and the same principle applies to documentation context.
Context7 takes a different approach. Rather than fetching arbitrary URLs, it maintains a curated index of library documentation keyed by library identifier and version. When an agent calls it, Context7 retrieves documentation and code examples matched to the specific library version in scope and injects that content into the LLM context before code generation runs. The model generates against current, version-matched documentation rather than its training data.
The project has 52,568 GitHub stars as of mid-2026, a reasonable signal that stale-docs failures are not an edge case. Context engineering is the discipline that addresses this problem systematically.
Two Tools, One Job
Context7 delivers its fix through exactly two tools. The order they run in is not optional.
resolve-library-id takes a plain-language library name, such as next.js or supabase, and returns a stable Context7 library identifier in a format such as /vercel/next.js or /mongodb/docs. That identifier is the required input for the second tool, so this call always runs first. Pass a recognizable name; the tool ranks candidates by name similarity, documentation coverage, and source reputation before returning a match.
query-docs accepts the identifier from the previous call plus two optional parameters: a topic string (e.g., hooks or routing) and a token limit that controls how much documentation the response includes. It returns documentation snippets and code examples pulled from Context7's curated source index, scoped to the library and version you specified.
Retrieval is bounded to what Context7 has indexed. This is an intentional design choice; bounded sources produce consistent, filterable signal rather than raw page content that the agent has to parse. If you are evaluating which libraries in your stack are reachable this way, the Moltline server directory includes an agent-readiness checker that can help surface coverage gaps alongside other tooling gaps in your setup.
Both tools are stateless per call. No session persists between invocations, and no conversation context carries over. Each call is self-contained: provide the right input, get the right output. That makes the integration predictable and straightforward to wire into any MCP-compatible client.
Local vs. Remote: Two Ways to Connect
With the two tools understood, the next decision is how to run them. Context7 ships as two distinct variants, and the choice affects your dependencies, auth flow, and throughput ceiling.
Local variant (context7) runs over stdio transport. It is available through Stacklok's ToolHive registry with the container image ghcr.io/stacklok/dockyard/npx/context7:4.0.4. This path requires a container runtime on the host machine. ToolHive manages the process lifecycle, so you do not wire up port binding manually. Suitable for local development where you control the environment.
Remote variant (context7-remote) exposes a network endpoint at context7.com. Authenticated users go through a dynamic OAuth handshake on first connection. This is the path for persistent, higher-throughput usage where you do not want a container dependency in the loop.
Authentication and rate limits work in tiers. Unauthenticated access functions for basic calls but hits rate limits. Context7 does not publish specific numeric thresholds. Treat unauthenticated use as appropriate for development and testing only, not production pipelines where an agent loop calls query-docs repeatedly. Registering at context7.com/dashboard provides higher rate limits and priority access.
For Claude Desktop or Cursor, the remote endpoint is the simpler starting point. Add the server URL to your MCP client config, and OAuth handles the auth handshake on first run. You skip the container runtime dependency entirely. See the Frequently Asked Questions on production MCP infrastructure if you are unsure how Streamable HTTP clients handle OAuth in headless environments.
Quick Setup: Config Snippets for Common Clients
Here are the configs for each client. No preamble needed after the previous section covered the transport trade-offs.
Claude Desktop (stdio via npx)
Add this block to claude_desktop_config.json under mcpServers:
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"]
}
Check the upstash/context7 README for the current package name before pasting. No API key required for basic use. Restart Claude Desktop after saving.
Streamable HTTP Clients (remote variant)
Set the server URL to the context7-remote endpoint in your client's MCP config. On first connection, the OAuth flow opens in a browser tab. Complete it once; the client caches the token.
ToolHive-Managed Deployments
Register the container directly. Consult ToolHive's documentation for the exact CLI syntax and the current container image tag.
ToolHive binds the port and manages the process lifecycle. You do not configure a transport manually. The same container image works for teams standardizing deployments across machines.
Cursor and Codex CLI
Both accept MCP server configs in their respective settings files. The JSON block above (command + args) transfers directly. Adjust the file path to match where each client expects its config; the structure does not change.
Verify Before You Build
Before wiring any agent workflow around query-docs, call resolve-library-id with a known library name. A valid identifier in the response confirms the connection is live and the library is indexed. If it returns nothing, debug the connection before building further. The same verification step applies regardless of client, as covered in Wiring an Image MCP Server into Claude Desktop or Cursor for similar MCP setups.
Library Coverage: What Is In, What Might Not Be
Once your connection is verified, knowing what the index actually contains determines whether Context7 is the right tool for a given project.
Coverage is broad for mainstream stacks. A curated index of popular libraries including Next.js, React, and Supabase is available, spanning web, data, and backend ecosystems. If your project uses widely adopted open-source packages, the index likely has them.
The index is curated, not crawled. That distinction matters: niche libraries, internal packages, and very recently released projects are unlikely to appear. Curation improves signal quality but creates blind spots that arbitrary web fetching would not have.
There is no public catalog of covered libraries. Call resolve-library-id before building any workflow that depends on query-docs; there is no public index to consult.
Version specificity is worth highlighting. query-docs accepts a version string, so you can request documentation scoped to the version your codebase pins rather than the latest release. This is particularly useful when a library has shipped breaking changes since your last dependency update and the current docs no longer match your code.
If resolve-library-id returns no result, two fallback options exist:
Use the Fetch server available through ToolHive or a comparable general-fetch MCP server to retrieve documentation from an arbitrary URL directly.
Maintain your own documentation context by pasting relevant sections into your prompt or a project-level context file.
Neither fallback matches Context7's version-matched precision, but both keep the workflow functional when a library falls outside the index.
Context7 vs. General Web-Fetch MCP Servers
When a library falls outside Context7's index, the natural fallback is a general-fetch server. Understanding the difference clarifies when to use each.
Context7's curated retrieval trades URL flexibility for per-token relevance; a fetch server covers what falls outside the index.
The two are not mutually exclusive. A practical configuration registers both: Context7 handles documented library lookups; a fetch server covers one-off URL retrieval. The agent calls whichever tool fits the task.
Where Moltline's free-tier endpoints fit is a separate layer entirely. The 110 free tools at mcp.moltlinestudio.com cover runtime operations: data transformation, API calls, utilities. Context7 operates before generation, injecting documentation into context. Moltline's tools operate after, executing the result. No signup is required; paste any endpoint directly into Claude, Cursor, or Codex CLI.
SKILL.md agent skills from GarphenGate/moltline-oss can wire both layers together. A skill calls resolve-library-id and query-docs to ground a code-generation step, then invokes a Moltline runtime tool to execute the output.
Known Limits to Account For
Knowing where Context7 falls short helps you design around the gaps rather than discover them mid-run.
Rate limits are real but undocumented. Unauthenticated requests hit a threshold; the exact number is not published. When a workflow crosses it, the symptom is typically a failed tool call or an empty response, not a clean error message. Some MCP clients will surface nothing at all, making the failure look like a coverage gap rather than throttling. If you see intermittent empty results in a loop calling query-docs repeatedly, rate limiting is the first thing to check.
Coverage gaps cannot be predicted. Call resolve-library-id before building any workflow that depends on query-docs; there is no public index to consult.
The context7-remote OAuth flow requires a browser; plan for manual intervention on first connection in headless CI environments.
Index freshness is per-library, not global. Stacklok's documentation notes a last-updated date of July 31, 2026, but that reflects the server record, not every library's documentation age. Individual sources are re-indexed on their own cadence, which is not published. Monitor this if your project targets a fast-moving library. What to Expect in Licensing as Agentic Stacks Mature covers how licensing models around tools like this evolve.
Design for graceful degradation. Treat Context7 as best-effort. If a tool call returns nothing, the pipeline should continue with reduced context rather than halt. Hard dependencies on query-docs returning results will produce brittle workflows.
Next Steps
Given the limits covered above, here is a concrete sequence for moving from validation to production.
Start local. Run the stdio setup via npx and call resolve-library-id against every library your project depends on before writing a single agent workflow that relies on query-docs. Coverage gaps surface immediately, and it costs nothing to find them now rather than in a broken pipeline later.
Add an API key before production; unauthenticated limits produce silent failures.
Pair Context7 with Moltline's free endpoints at mcp.moltlinestudio.com for runtime tooling -- no signup needed.
Browse the 138 open SKILL.md agent skills at GarphenGate/moltline-oss on GitHub. The skills show concrete patterns for chaining documentation retrieval with runtime tool calls inside a single agent skill. The Codex and GitHub integration walkthrough is a useful starting point if you are wiring Context7 into a Codex CLI workflow.
If a library is not covered by Context7, run the free agent-readiness checker at moltlinestudio.com. It audits your overall agent configuration and flags coverage gaps worth addressing before you commit to a production setup.
Conclusion
Context7 solves a real problem: AI coding assistants hallucinate outdated APIs because they lack access to current documentation. Two tools, resolve-library-id and query-docs, handle that gap cleanly. Connection takes minutes whether you choose local or remote, and most major libraries are already covered.
Start small: verify your target libraries with resolve-library-id, add an API key before any production loop, and pair with a fetch server or Moltline runtime tools for what falls outside the index.