Click on "Install 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., "@context7-mcp show me the latest React documentation for useState hook"
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.
Context7 MCP 是一款为开发者提供最新代码文档和示例的服务，通过集成到开发环境中，确保LLM生成的代码基于最新的库文档。 Context7 MCP is a service that provides developers with the latest code documentation and examples. By integrating into the development environment, it ensures that the code generated by LLMS is based on the latest library documentation.## 工具列表 Tool List
本MCP服务封装下列工具，可让模型通过标准化接口调用以下功能。 本MCP服务封装下列工具，可让模型通过标准化接口调用以下功能。
工具 Tool | 描述 Description |
resolve-library-id | Resolves a package/product name to a Context7-compatible library ID and returns a list of matching libraries. You MUST call this function before 'get-library-docs' 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. 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. |
get-library-docs | Fetches up-to-date documentation for a library. You must call 'resolve-library-id' 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. Use mode='code' (default) for API references and code examples, or mode='info' for conceptual guides, narrative information, and architectural questions. |
工具在线测试： https://mcp.xiaobenyang.com/inspector/1777316659576835
Online Tool test https://mcp.xiaobenyang.com/inspector/1777316659576835
Related MCP server: PAELLADOC
如何获取 XBY-APIKEY ？ How to get XBY-APIKEY ?
访问小笨羊科技网站 https://xiaobenyang.com，注册用户即可获得APIKEY Visit XiaoBenYang website https://xiaobenyang.com, register and get the APIKEY.
{
"mcpServers": {
"代码文档更新服务": {
"headers": {
"XBY-APIKEY": "<YOUR_XBY_APIKEY>"
},
"type": "sse",
"url": "https://mcp.xiaobenyang.com/1777316659576835/sse"
}
}
}{
"mcpServers": {
"代码文档更新服务": {
"headers": {
"XBY-APIKEY": "<YOUR_XBY_APIKEY>"
},
"type": "streamable_http",
"url": "https://mcp.xiaobenyang.com/1777316659576835/mcp"
}
}
}{
"mcpServers": {
"代码文档更新服务": {
"command": "npx",
"args": [
"-y",
"xiaobenyang-mcp"
],
"env": {
"XBY_APIKEY": "<YOUR_XBY_APIKEY>",
"mcpId": "1777316659576835",
},
"transport": "stdio"
}
}
}
Fetches up-to-date documentation for a library. You must call 'resolve-library-id' 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. Use mode='code' (default) for API references and code examples, or mode='info' for conceptual guides, narrative information, and architectural questions.
| Name | Required | Description | Default |
|---|---|---|---|
| context7CompatibleLibraryID | Yes | ||
| mode | No | ||
| topic | No | ||
| page | No |
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 key behavioral traits: the prerequisite of calling 'resolve-library-id' first (unless specific ID format is provided), the two operational modes with their distinct purposes, and the fact that documentation is 'up-to-date.' It doesn't mention error handling, rate limits, or authentication requirements, but provides substantial operational context.
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 efficiently structured with two sentences that each serve distinct purposes: the first establishes the core functionality and prerequisites, the second explains the mode parameter usage. Every word contributes necessary information with zero wasted content.
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?
For a tool with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description does an excellent job covering the most critical aspects: purpose, prerequisites, and key parameter usage. It doesn't explain the 'topic' or 'page' parameters or describe the return format, but provides sufficient context for basic usage given the complexity.
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?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It provides meaningful context for two parameters: it explains the 'context7CompatibleLibraryID' parameter's relationship with the sibling tool and acceptable formats, and details the two possible values for 'mode' parameter and when to use each. It doesn't mention 'topic' or 'page' parameters, leaving some gaps.
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 ('fetches up-to-date documentation for a library') and distinguishes it from its sibling 'resolve-library-id' by explaining the relationship between them. It specifies the exact resource being accessed.
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 explicit guidance on when to use this tool versus alternatives: it instructs to call 'resolve-library-id' first unless the user provides a specific library ID format, and distinguishes between two modes ('code' vs 'info') for different types of documentation needs. It clearly defines the prerequisites and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves a package/product name to a Context7-compatible library ID and returns a list of matching libraries.
You MUST call this function before 'get-library-docs' 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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| libraryName | Yes |
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: it returns a list of matching libraries, explains the selection process with prioritization criteria (name similarity, description relevance, etc.), specifies the response format (including error handling for no matches), and outlines how to handle ambiguous queries. This covers most behavioral aspects, though it could mention performance characteristics like rate limits or authentication needs.
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 appropriately sized but not optimally structured. The first paragraph clearly states the purpose and usage guidelines, but the subsequent 'Selection Process' and 'Response Format' sections, while informative, could be more integrated. Some sentences (e.g., about benchmark scores) add value but slightly reduce conciseness. Overall, it's front-loaded with key information but includes some elaboration that, while useful, affects efficiency.
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 complexity (a resolution tool with a multi-criteria selection process), no annotations, and no output schema, the description does a good job of covering context. It explains the tool's role in the workflow, the selection logic, and the response handling. However, it lacks details on output structure (beyond high-level format) and doesn't address potential errors or edge cases beyond 'no good matches,' leaving minor gaps in completeness.
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?
The schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the bare schema by explaining that the 'libraryName' parameter is a 'package/product name' to be resolved, and it implicitly defines the expected input as a query string rather than a pre-formatted ID. However, it doesn't provide examples or format details for the parameter, leaving some ambiguity.
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 specific action ('resolves a package/product name to a Context7-compatible library ID') and resource ('returns a list of matching libraries'), distinguishing it from its sibling 'get-library-docs' by explaining this is a prerequisite step for obtaining valid IDs. The verb 'resolves' is precise and the scope is well-defined.
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?
Explicitly states when to use this tool ('before get-library-docs to obtain a valid Context7-compatible library ID') and when not to use it ('UNLESS the user explicitly provides a library ID in the format...'). It names the alternative tool ('get-library-docs') and provides clear conditions for bypassing this tool, offering comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: 'resolve-library-id' handles library identification and matching, while 'get-library-docs' retrieves documentation for a specific library. There is no overlap in functionality, and the descriptions explicitly define their separate roles in the workflow.
Both tools follow a consistent verb-object naming pattern with hyphens ('resolve-library-id', 'get-library-docs'), which is clear and readable. The minor deviation is that 'resolve' and 'get' are different verbs, but this reflects their distinct actions appropriately within the domain.
With only 2 tools, the server feels thin for its apparent domain of library documentation retrieval. A more complete surface might include tools for browsing libraries, searching documentation, or managing queries, but the current set is minimal and may limit agent capabilities.
The tool surface is severely incomplete for library documentation workflows. While it covers resolution and fetching, it lacks tools for operations like searching across libraries, listing available libraries, or handling documentation updates, which are common needs in this domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
The AWS Knowledge MCP server is a fully managed remote Model Context Protocol server that provides real-time access to official AWS content in an LLM-compatible format. It offers structured access to AWS documentation, code samples, blog posts, What's New announcements, Well-Architected best practices, and regional availability information for AWS APIs and CloudFormation resources. Key capabilities include searching and reading documentation in markdown format, getting content recommendations, listing AWS regions, and checking regional availability for services and features.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaobenyang-com/1777316659576835'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
