Skip to main content
Glama

Context7

by io.github.upstash
OverviewDiscussionsAdmin

Server Details

Up-to-date docs for AI agents

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 59 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
upstash/context7
GitHub Stars
63,736
Server Listing
Context7 MCP

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct roles: resolve-library-id maps a package name to a Context7 ID, while query-docs fetches documentation and code examples. The descriptions explicitly define the ordering relationship, leaving no room for misselection.

Naming Consistency5/5

Both names use kebab-case with a verb_noun structure (query-docs, resolve-library-id). The pattern is fully consistent across the set.

Tool Count4/5

Two tools is minimal, but the server's scope is narrow documentation retrieval, and each tool earns its place as a distinct step in the workflow. It is slightly thin rather than padded.

Completeness4/5

The pair covers the core lifecycle: resolve an identifier, then query docs against it. Coverage is functional, with only minor gaps such as standalone library browsing or version listing beyond what resolution returns.

Available Tools

2 tools
query-docsQuery DocumentationA
Read-onlyIdempotent
Inspect

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.

If you know the programming language the user is working in, pass it as language so the results match their setup.

NameRequiredDescriptionDefault
queryYesWhat 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.
languageNoProgramming language the user is writing code in, such as 'Python', 'TypeScript', 'Go', or 'C#'. Ranks code examples in that language first. Leave it out when the language is unknown or does not apply.
libraryIdYesExact Context7-compatible library ID (e.g., '/mongodb/docs', '/vercel/next.js', '/supabase/supabase', '/vercel/next.js/v16.2.9') retrieved from 'resolve-library-id' or directly from user query in the format '/org/project' or '/org/project/version'.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds behavior not in annotations: the mandatory prerequisite call, the call-count limit, and the external API transmission note in the query param. Minor gap: doesn't describe return shape or what happens on failure, but annotations plus these constraints give strong transparency.

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?

Front-loaded purpose followed by prerequisites, limits, and tips in a logical order. Slightly verbose (the two prerequisite paragraphs could merge), but every sentence conveys actionable constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only fetch tool with full schema coverage, the description covers prerequisites, limits, and param guidance. No output schema, but the read/fetch nature makes return shape inferable. A brief note on result format would push it higher.

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 coverage is 100% and the schema descriptions already cover per-param intent, examples, and the sensitive-data warning. The description adds marginal value: the libraryId format reminder and the language rationale, but largely echoes schema content. Baseline 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?

States a specific verb ('retrieves and queries') and resource ('up-to-date documentation and code examples'), scopes it to Context7, and distinguishes it from the sibling resolve-library-id by making clear this fetches content while that one resolves IDs.

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?

Explicitly names the required predecessor ('you must call Resolve Context7 Library ID first') with the exception condition (user provides '/org/project' format), and imposes a rate limit ('no more than 3 times per question'). Includes a usage tip about passing `language`. This is unusually complete routing guidance.

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 IDA
Read-onlyIdempotent
Inspect

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:

  1. Analyze the query to understand what library/package the user is looking for

  2. 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.

NameRequiredDescriptionDefault
queryYesWhat 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.
libraryNameYesLibrary 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.

  1. 1 tool update
    • Changedquery-docs1 field changed
      • changedInput schema / properties / libraryId / description
        Previous value: -"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'."New value: +"Exact Context7-compatible library ID (e.g., '/mongodb/docs', '/vercel/next.js', '/supabase/supabase', '/vercel/next.js/v16.2.9') retrieved from 'resolve-library-id' or directly from user query in the format '/org/project' or '/org/project/version'."
  2. 1 tool update
    • Changedquery-docs1 field changed
      • addedInput schema / properties / language
        Added value: +{
+  "description": "Programming language the user is writing code in, such as 'Python', 'TypeScript', 'Go', or 'C#'. Ranks code examples in that language first. Leave it out when the language is unknown or does not apply.",
+  "type": "string"
+}
  3. 2 tool updates
    • First observedquery-docs
    • First observedresolve-library-id

Related MCP Connectors

Related MCP Servers

Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources