A
licenseNot graded
qualityD
maintenanceProvides LLMs with up-to-date, version-specific documentation and code examples from library sources directly into prompts, eliminating outdated code generation and hallucinated APIs.
879,513
MIT
Context7
Server Details
Up-to-date code docs for any prompt
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- upstash/context7
- GitHub Stars
- 61,623
- Server Listing
- Context7 MCP
Available Tools
2 toolsquery-docsQuery DocumentationARead-onlyIdempotentInspect
Retrieves and queries up-to-date documentation and code examples from Context7 for any programming library or framework.
You must call 'Resolve Context7 Library ID' tool first to obtain the exact Context7-compatible library ID required to use this tool, UNLESS the user explicitly provides a library ID in the format '/org/project' or '/org/project/version' in their query.
Do not call this tool more than 3 times per question.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look up in the library's documentation, scoped to a single concept. Be specific and include relevant details, but keep each query to one topic — if the user's question spans multiple distinct concepts, make a separate call per concept instead of combining them, unless the question is about how the concepts interact. Good: 'How to set up authentication with JWT in Express.js' or 'React useEffect cleanup function examples'. Bad (too vague): 'auth' or 'hooks'. Bad (too broad): 'routing and auth and caching in Next.js'. The query is sent to the Context7 API for processing. Do not include any sensitive or confidential information such as API keys, passwords, credentials, personal data, or proprietary code in your query. | |
| libraryId | Yes | Exact Context7-compatible library ID (e.g., '/mongodb/docs', '/vercel/next.js', '/supabase/supabase', '/vercel/next.js/v14.3.0-canary.87') retrieved from 'resolve-library-id' or directly from user query in the format '/org/project' or '/org/project/version'. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral context beyond those annotations: results are 'up-to-date,' the prerequisite ID-resolution step is mandatory, calls are limited to 3 per question, and sensitive data must not be included in queries. Minor gaps like error handling or response shape are not disclosed, but the added operational context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core purpose in the first sentence. The following sentences add only high-value operational instructions: ID resolution prerequisite, the exception for user-provided IDs, and the call limit. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count, rich schema descriptions, and strong safety annotations, the description provides everything an agent needs to invoke the tool correctly: purpose, prerequisite flow, ID format source, call limit, and query hygiene guidance. No critical missing context is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have rich descriptions with examples, formatting guidance, and scoping rules. The tool description itself does not add much parameter-level detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Retrieves and queries') on a specific resource ('up-to-date documentation and code examples from Context7') and clarifies it applies to 'any programming library or framework.' This distinguishes it clearly from the sibling tool resolve-library-id, which resolves IDs rather than querying documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: call 'Resolve Context7 Library ID' first unless the user supplies a library ID in a recognized format. It also provides a hard usage constraint ('Do not call this tool more than 3 times per question'), leaving no ambiguity about the intended call flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve-library-idResolve Context7 Library IDARead-onlyIdempotentInspect
Resolves a package/product name to a Context7-compatible library ID and returns matching libraries.
You MUST call this function before 'Query Documentation' tool to obtain a valid Context7-compatible library ID UNLESS the user explicitly provides a library ID in the format '/org/project' or '/org/project/version' in their query.
Each result includes:
Library ID: Context7-compatible identifier (format: /org/project)
Name: Library or package name
Description: Short summary
Code Snippets: Number of available code examples
Source Reputation: Authority indicator (High, Medium, Low, or Unknown)
Benchmark Score: Quality indicator (100 is the highest score)
Versions: List of versions if available. Use one of those versions if the user provides a version in their query. The format of the version is /org/project/version.
For best results, select libraries based on name match, source reputation, snippet coverage, benchmark score, and relevance to your use case.
Selection Process:
Analyze the query to understand what library/package the user is looking for
Return the most relevant match based on:
Name similarity to the query (exact matches prioritized)
Description relevance to the query's intent
Documentation coverage (prioritize libraries with higher Code Snippet counts)
Source reputation (consider libraries with High or Medium reputation more authoritative)
Benchmark Score: Quality indicator (100 is the highest score)
Response Format:
Return the selected library ID in a clearly marked section
Provide a brief explanation for why this library was chosen
If multiple good matches exist, acknowledge this but proceed with the most relevant one
If no good matches exist, clearly state this and suggest query refinements
For ambiguous queries, request clarification before proceeding with a best-guess match.
IMPORTANT: Do not call this tool more than 3 times per question. If you cannot find what you need after 3 calls, use the best result you have.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look up in the library's documentation. This is used to rank library results by relevance to what the user is trying to accomplish. The query is sent to the Context7 API for processing. Do not include any sensitive or confidential information such as API keys, passwords, credentials, personal data, or proprietary code in your query. | |
| libraryName | Yes | Library name to search for and retrieve a Context7-compatible library ID. Use the official library name with proper punctuation — e.g., 'Next.js' instead of 'nextjs', 'Customer.io' instead of 'customerio', 'Three.js' instead of 'threejs'. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, openWorld, and idempotent behavior. The description adds meaningful behavioral context beyond that: it describes ranking criteria, the returned match fields, the selection process, the API-bound query warning, and a hard call limit. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose and mandatory usage. However, it is somewhat repetitive: source reputation and benchmark score appear in both the result-field list and the selection criteria, and the response-format section restates points already covered earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, and it does so thoroughly: it lists result fields, version handling, response format, ambiguous-query behavior, and call limits. Nothing essential for calling and using this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already explains both parameters thoroughly, including the sensitive-data warning and exact library-name formatting. The description adds selection-process guidance but does not add significant new parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Resolves a package/product name to a Context7-compatible library ID and returns matching libraries.' It also differentiates itself from the sibling 'Query Documentation' tool by explicitly stating it is a prerequisite unless the user already provided a library ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'You MUST call this function before Query Documentation' and provides the exception for user-supplied IDs. It also states when to stop ('Do not call this tool more than 3 times per question') and how to handle ambiguous queries, which is strong usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- First observed
query-docs - First observed
resolve-library-id
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Keyless docs search so coding agents wire up RoxyAPI: every endpoint, param and SDK call.
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides up-to-date, version-specific documentation and code examples for libraries and frameworks directly into AI prompts, eliminating outdated code generation and hallucinated APIs.2879,513MIT
- AlicenseNot gradedqualityDmaintenancePulls up-to-date, version-specific documentation and code examples for libraries directly into your prompt, preventing outdated or hallucinated APIs.MIT
- AlicenseAqualityCmaintenanceProvides LLMs with up-to-date, version-specific documentation and code examples directly from library sources, eliminating outdated training data and hallucinated APIs by fetching current documentation at prompt time.42879,513MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.5/5.0
Disambiguation5/5
The two tools have clearly distinct purposes: one resolves library names to IDs, the other queries documentation. There is no overlap; they operate in a sequential dependency, but each has a unique role.
Naming Consistency5/5
Both tool names follow a consistent verb_noun pattern in kebab-case: 'resolve-library-id' and 'query-docs'. The naming is uniform and predictable, making it easy for agents to understand their function.
Tool Count3/5
With only 2 tools, the server feels extremely minimal, which is borderline for a documentation query service. While the two tools cover the core workflow, the count is on the low end, making it feel slightly thin for a general-purpose documentation tool.
Completeness4/5
The workflow is complete for the stated purpose: resolve a library ID, then query docs. There are no obvious gaps in the lifecycle, though the server lacks features like listing all available libraries or direct version-specific queries without resolution, which are minor omissions.