Skip to main content
Glama

Resolve Context7 Library ID

resolve-library-id
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
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'.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

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.

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.