Provides tools for reading documentation, searching code, and asking AI questions about GitHub repositories through the Zread.ai platform.
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., "@zread-mcp search documentation for 'MCP protocol' in the zread-mcp repository"
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.
连接 Zread.ai 文档平台的 MCP 服务器，让 AI 助手能够阅读 GitHub 仓库文档、搜索代码、与仓库 AI 对话。
💡 提示 AI：这是一个 MCP (Model Context Protocol) 服务器，提供 9 个工具用于代码仓库分析。支持 Python 和 Node.js 两种实现，可通过
npx或uvx一行命令运行。核心功能包括文档查询、仓库搜索、AI 问答。
文档查询 - 获取仓库文档页面、目录结构、搜索关键词
仓库发现 - 推荐仓库、热门榜单、搜索代码库
AI 问答 - 向仓库 AI 助手提问（需 Token）
文件获取 - 读取源代码文件内容（需 Token）
Related MCP server: GitBridge
uvx zread-mcp
npx zread-mcp# uvx (Python)
uvx --env ZREAD_TOKEN=your-token zread-mcp
# npx (Node.js) - Windows
set ZREAD_TOKEN=your-token && npx zread-mcp
# npx (Node.js) - macOS/Linux
ZREAD_TOKEN=your-token npx zread-mcpuvx zread-mcp --transport http --port 3000
npx zread-mcp --transport http --port 3000# uvx 从 PyPI 运行（推荐）
uvx zread-mcp
# uvx 从 GitHub 仓库运行
uvx --from git+https://github.com/ejfkdev/zread-mcp.git zread-mcp
# uv 运行远程脚本
uv run https://raw.githubusercontent.com/ejfkdev/zread-mcp/main/zread_mcp_server.py
# pipx 从 GitHub 运行
pipx run --spec git+https://github.com/ejfkdev/zread-mcp.git zread-mcp
# pipx 安装到本地
pipx install git+https://github.com/ejfkdev/zread-mcp.git
zread-mcp --transport http
# 本地运行
python zread_mcp_server.py# pnpm
pnpm dlx ejfkdev/zread-mcp
# bun
bunx ejfkdev/zread-mcp
# 全局安装
npm install -g ejfkdev/zread-mcp
zread-mcp-server --transport http{
"mcpServers": {
"zread": {
"command": "npx",
"args": ["-y", "zread-mcp-server"],
"env": {
"ZREAD_TOKEN": "your-token"
}
}
}
}{
"mcpServers": {
"zread": {
"command": "uvx",
"args": ["--env", "ZREAD_TOKEN=your-token", "zread-mcp"]
}
}
}部分高级功能（AI 问答、文件获取）需要 ZREAD_TOKEN：
访问 https://zread.ai 并登录
按 F12 打开控制台
粘贴运行：
prompt('复制token', JSON.parse(localStorage.getItem('CGX_AUTH_STORAGE')).state.token)复制弹窗中的 Token
--transport {stdio,http,sse} 传输协议 (默认: stdio, http/sse 等价)
--host HOST HTTP 模式主机 (默认: 127.0.0.1)
--port PORT HTTP 模式端口 (默认: 3000)
--token TOKEN ZREAD_TOKEN
--no-token 强制无 Token 模式
-h, --help 显示帮助工具 | 需要 Token | 说明 |
fetch_documentation_page | 否 | 获取文档页面 |
search_documentation | 否 | 搜索文档 |
get_documentation_outline | 否 | 获取文档大纲 |
discover_repositories | 否 | 发现推荐仓库 |
find_repositories | 否 | 搜索仓库 |
get_trending_repositories | 否 | 热门仓库榜单 |
check_repository_status | 否 | 检查仓库状态 |
ask_repo_ai | 是 | AI 智能问答 |
fetch_repository_file | 是 | 获取源代码文件 |
# 克隆仓库
git clone https://github.com/ejfkdev/zread-mcp.git
cd zread-mcp
# Python 测试
python zread_mcp_server.py --test
# Node.js 测试
node zread-mcp-server.js --testMIT License
向仓库 AI 助手提问（AI 调用 AI）。
此工具让当前的 AI 通过 MCP 协议调用另一个专门的仓库 AI 助手来回答问题。 被调用的 AI 助手基于仓库文档内容进行分析，并回答你的问题。
被调用的 AI 助手拥有的工具：
get_repo_structure: 分析并展示代码仓库的目录结构
view_file_schema: 查看文件大纲，使用 AST 解析提取文件结构
view_file_in_detail: 读取并显示文件的具体内容
web_search: 网络搜索，使用简洁的关键词检索相关信息
doc_search: 文档搜索，查找指南教程文档中的相关页面
如果需要分析特定文件或目录结构，可以在问题中显式要求 AI 使用上述工具进行回复。
对于仓库代码的复杂需求，应该优先使用此工具，如果有多个问题可并行调用。 适用于理解项目架构、使用方法、代码示例等复杂问题。 支持的 AI 模型: glm-4.7 (默认), claude-sonnet-4.5
返回的 Markdown 回答内容中可能包含两种链接格式：
仓库文件链接 - 格式: [文件名](文件路径#L开始行号-L结束行号)
例如: [index.ts](index.ts#L1-L28) [package.json](package.json#L1-L77)
这类链接指向仓库内的源代码文件，可提取文件路径和行号范围，
使用 fetch_repository_file(repo_path, file_path, start_line, end_line) 获取具体内容。
文档导航链接 - 格式: [标题](页面slug)
例如: [概述](1-overview) [快速开始](2-quick-start)
这类链接指向文档的其他页面，使用 fetch_documentation_page(repo_path, 页面slug)
获取该页文档内容。
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | 仓库路径，格式: owner/repo 或完整 URL | |
| question | Yes | 要向 AI 提问的问题，如 "这个项目是做什么的？" | |
| ai_model | No | AI 模型选择，默认 "glm-4.7"，可选 "claude-sonnet-4.5" | glm-4.7 |
| language | No | 对话语言，可选 "zh" 或 "en" | zh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that it delegates to another AI, lists the tools that AI uses, explains the response format with link syntax, and mentions supported models. No contradictions.
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?
Well-structured with sections for purpose, tools, usage tips, models, and output format. Every sentence adds value; no redundancy despite the length.
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?
No output schema, but description fully explains the Markdown response with two link types and how to use sibling tools to fetch linked content. Also covers model options and usage patterns, making it self-contained.
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?
Schema coverage is 100% with clear descriptions for all 4 parameters. The description adds no new parameter-specific meaning beyond the schema; the extensive context is about tool behavior and output handling.
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 that the tool asks a specialized repository AI assistant questions via MCP protocol, distinguishing it from sibling tools that perform direct repository actions like fetching files or checking status.
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?
Provides explicit guidance: use for complex code understanding, ask for specific file analysis within the question, and parallelize multiple questions. Implicitly contrasts with simpler sibling tools for direct file access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查仓库索引状态。
查询指定仓库在 Zread.ai 的索引状态和基本信息。 返回的 status 字段: "success"(已索引), "progress"(索引中)
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | 仓库路径，格式: owner/repo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals the return status field and hints at '基本信息', but lacks disclosure on error handling, authentication, or rate limits. Adequate for a simple read operation but could be more explicit.
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?
Extremely concise: three sentences with no filler. Front-loaded with the core purpose. Every sentence adds value.
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 tool's simplicity (one required param, no output schema), the description covers the main functionality and return status. Minor gap: no mention of error cases or what '基本信息' includes. Nearly complete.
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?
Input schema has 100% coverage with description for repo_path. Description confirms the parameter's role ('查询指定仓库') but adds no new meaning beyond the schema. Baseline score of 3 is appropriate.
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?
Description clearly states the verb (查询/检查), resource (仓库索引状态), and expected output (status field with values 'success' and 'progress'). It distinguishes this tool from siblings like ask_repo_ai or discover_repositories by focusing on index status.
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?
Description implies usage for checking if a repository is indexed, but does not provide explicit guidance on when to use vs. alternatives, or when not to use. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
发现推荐的代码仓库。
获取 Zread.ai 推荐的优质代码仓库，可按技术主题筛选。 适用于发现新工具、学习优秀项目。
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | 技术主题筛选，如 "ai", "python", "web"，空字符串表示全部 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as pagination, rate limits, or the definition of 'recommended'. The description does not contradict any annotations.
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 concise with three sentences, front-loaded with the main purpose. It is well-structured but could be more efficient by combining sentences.
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 simple input schema (one optional parameter) and no output schema, the description provides purpose and use cases but fails to explain the return format or any limitations, which is insufficient for a fully standalone description.
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?
Schema coverage is 100% with a single parameter (topic) already described. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 discovers recommended code repositories, with filtering by topic. It is a specific verb+resource, but does not differentiate from sibling tools like find_repositories or get_trending_repositories, which have similar purposes.
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 implies usage for discovering new tools and learning projects, but provides no explicit when-to-use or when-not-to-use guidance, nor does it contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取仓库文档的指定页面内容。
根据页面 slug（URL 标识符）获取该页面的完整 Markdown 文档内容。 适用于读取特定章节或页面的详细内容。
返回的 Markdown 页面内容中可能包含两种链接格式：
仓库文件链接 - 格式: [文件名](文件路径#L开始行号-L结束行号)
例如: [index.ts](index.ts#L1-L28) [package.json](package.json#L1-L77)
这类链接指向仓库内的源代码文件，可提取文件路径和行号范围，
使用 fetch_repository_file(repo_path, file_path, start_line, end_line) 获取具体内容。
文档导航链接 - 格式: [标题](页面slug)
例如: [概述](1-overview) [快速开始](2-quick-start)
这类链接指向文档的其他页面，使用 fetch_documentation_page(repo_path, 页面slug)
获取该页文档内容。
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | 仓库路径，格式: owner/repo 或完整 URL | |
| page_slug | Yes | 页面 slug，如 "1-overview", "quick-start" | |
| language | No | 文档语言，可选 "zh"(中文) 或 "en"(英文) | zh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that returned Markdown contains two types of links and explains how to process them, adding behavioral context beyond schema. However, it does not mention any potential limitations, rate limits, or error conditions.
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 well-structured with bullet points for the link types, making it easy to digest. It is slightly longer than necessary but every sentence adds value, either stating the purpose or explaining how to use the output. No fluff.
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 no output schema, the description effectively explains what the tool returns (Markdown content with link formats) and how to process it with other tools. It covers the main use case comprehensively, though it could mention potential errors or behavior when the page does not exist.
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?
Schema coverage is 100%, so the baseline is 3. The description adds no new information about parameters beyond what the schema already provides (e.g., page_slug examples are already in schema description). The description's value lies in usage context, not parameter details.
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 uses a specific verb ('获取') and resource ('仓库文档的指定页面内容'), clearly stating the tool fetches a documentation page by slug. It distinguishes itself from siblings like fetch_repository_file (source code) and search_documentation by explaining link formats and the intended use case.
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 explicitly states it is suitable for reading specific sections/pages, and provides detailed guidance on how to handle the two types of links, including which sibling tool to use for each. It does not explicitly state when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取仓库内的源代码文件内容。
读取指定仓库中的文件内容，支持按行号范围截取。 内部自动通过 repo_path 获取 repo_id。 适用于查看源代码、配置文件等。
示例:
获取完整文件: fetch_repository_file("owner/repo", "src/config.ts")
获取前 50 行: fetch_repository_file("owner/repo", "src/config.ts", 1, 51)
从第 100 行到末尾: fetch_repository_file("owner/repo", "src/config.ts", 100)
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | 仓库路径，格式: owner/repo 或完整 URL | |
| file_path | Yes | 文件在仓库中的路径，如 "src/config.ts", "README.md" | |
| start_line | No | 可选，开始行号（包含），从 1 开始计数 | |
| end_line | No | 可选，结束行号（不包含），不指定则到文件末尾 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the read-only nature (file content retrieval) and internal logic (auto-resolving repo_id). It does not mention authentication or rate limits, but for a straightforward read operation, this is acceptable.
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 concise (three sections: intro, detail, examples) with no filler. Every sentence adds information, and the example section is especially helpful for understanding parameter usage.
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?
With 4 parameters (2 required) and no output schema, the description covers input semantics well. It explains repo_path, file_path, and line ranges. However, it does not describe the output format (e.g., raw text, encoded), which would be helpful but not critical given the tool's simplicity.
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?
Schema description coverage is 100%, but the description adds significant value: it explains line numbering (1-indexed, end_line exclusive), provides examples, and clarifies that start_line and end_line are optional. This goes beyond the schema definitions.
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 fetches file contents from a repository, with a specific verb ('获取') and resource ('仓库内的源代码文件内容'). It distinguishes from siblings like ask_repo_ai (AI queries) and fetch_documentation_page (docs) by focusing on source code files.
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 concrete usage examples (full file, line ranges) and states its applicability ('适用于查看源代码、配置文件等'). However, it does not explicitly state when not to use it or mention alternative tools, though the sibling list implies distinct roles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索代码仓库。
根据关键词模糊搜索已索引的代码仓库。 支持仓库名称、描述、主题等字段的模糊匹配。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词，如 "react", "machine learning" | |
| language | No | 返回语言，可选 "zh" 或 "en" | zh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions fuzzy search and indexed repositories but omits behavioral traits like read-only nature, response format, pagination, or access requirements.
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?
Two sentences with no wasted words. The first sentence front-loads the core purpose, and the second adds necessary context. Efficient and direct.
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 2-parameter tool without output schema or annotations, the description should provide more context about return value format, pagination, or behavior. It fails to specify output structure, making it incomplete.
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?
Schema coverage is 100% with both parameters described in the schema. The tool description adds no extra meaning beyond what the parameter descriptions already provide, so baseline score of 3 applies.
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 searches code repositories using keywords with fuzzy matching on fields like name, description, and topics. The verb 'search' and resource 'code repositories' are specific, though it doesn't explicitly differentiate from sibling 'discover_repositories'.
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?
No guidance on when to use this tool versus alternatives (e.g., discover_repositories, search_documentation). It does not provide context for when not to use it or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取仓库文档的完整目录结构。
返回仓库的文档目录树，包含所有页面的标题、slug 和层级关系。 首次调用会自动提交索引请求，如果仓库未被索引会返回等待状态。
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | 仓库路径，格式: owner/repo 或完整 URL | |
| language | No | 文档语言，可选 "zh" 或 "en" | zh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool may automatically submit an indexing request and return a waiting state if the repository is not yet indexed. This is valuable behavioral context beyond the basic output, though it could mention rate limits or auth requirements.
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 concise, with two sentences that quickly convey the purpose and an important behavioral note about indexing. It is front-loaded and free of unnecessary words.
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?
While the description covers the main function and indexing behavior, it lacks details about the output format (e.g., structure of the tree, response fields). Since there is no output schema, more completeness would help the agent understand what to expect. However, it does mention titles, slugs, and hierarchy, providing partial guidance.
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 input schema already provides 100% coverage, describing both parameters (repo_path and language) with clear descriptions. The description adds no extra semantic detail beyond confirming the language parameter's purpose, so it meets the baseline.
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 retrieves the complete document directory tree of a repository, listing titles, slugs, and hierarchy. This distinguishes it from siblings like fetch_documentation_page (fetches a specific page) and search_documentation (searches content).
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 mentions automatic indexing behavior on first call, which is useful context, but does not explicitly state when to use this tool vs alternatives or when not to use it. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取本周热门仓库榜单。
获取 GitHub 本周最受欢迎的代码仓库列表，按热度排序。 适用于了解技术趋势和热门项目。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention that the tool is read-only, any rate limits, or data freshness, but the operation is inherently a safe read, which is implied by the purpose. For a simple fetch, this is minimally adequate.
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 three short sentences, but the first two essentially repeat the same information. It is concise but could be slightly more efficient. Still, it is front-loaded and easy to read.
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 tool has no parameters and no output schema, the description adequately explains the tool's purpose, sorting, and suitable use cases. It does not describe the output format or limitations, but for a simple trending list, this is sufficient.
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?
There are zero parameters, so the input schema is trivially complete. According to the guidelines, baseline 4 applies, and the description adds no additional parameter details, which is acceptable.
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 retrieves trending repositories for the current week, sorted by popularity. It explicitly mentions the verb 'get' and the resource 'trending repositories', distinguishing it from sibling tools like 'find_repositories' which likely handle general search.
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 explains it is suitable for understanding technology trends and popular projects, providing clear context for when to use it. While it doesn't explicitly mention when not to use or compare to alternatives, the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在仓库文档中搜索关键词。
全文搜索仓库文档，返回包含关键词的页面和相关内容片段。 适用于快速定位文档中的特定信息。
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | 仓库路径，格式: owner/repo 或完整 URL | |
| keyword | Yes | 搜索关键词，如 "installation", "API", "config" | |
| language | No | 搜索语言，可选 "zh" 或 "en" | zh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what is returned (pages and snippets) but lacks details on authentication needs, rate limits, result limits, or search behavior (e.g., case sensitivity, partial matching). This is minimal disclosure.
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 three short sentences in Chinese, front-loaded with the action, then result, then use case. Every sentence adds value. No redundant or vague phrasing.
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 no output schema and 3 parameters, the description covers the main purpose and basic behavior. However, it omits details like whether language affects search results, potential error cases, or any dependencies. Slightly above minimal but not fully comprehensive.
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?
Schema coverage is 100%, and the description adds value by giving examples for 'keyword' ('installation', 'API', 'config') and clarifying 'repo_path' format ('owner/repo or full URL'). The description also explains the search scope (full-text). This goes beyond the schema's basic descriptions.
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 does full-text search in repository documentation, returning pages and snippets. It includes a use case 'quickly locate specific information'. However, it does not explicitly distinguish from sibling tool 'ask_repo_ai', which may also perform search-like functions.
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 a usage hint: 'suitable for quickly locating specific information in documentation.' But no explicit when-not-to-use or comparison with alternatives like 'ask_repo_ai' or 'fetch_documentation_page'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1ask_repo_aicheck_repository_statusdiscover_repositoriesfetch_documentation_pagefetch_repository_filefind_repositoriesget_documentation_outlineget_trending_repositoriessearch_documentationEach tool has a clearly distinct purpose: meta-query, repo status, repo discovery (curated, keyword, trending), file access, doc outline, doc page, doc search. No overlap between tools.
All tool names follow a consistent verb_noun pattern (e.g., check_repository_status, fetch_repository_file) with uniform snake_case. The one exception (ask_repo_ai) still fits the pattern.
9 tools is well-scoped for a repository and documentation exploration MCP server. Each tool has a clear role and none feel extraneous or missing.
The tool set covers key operations for the domain: repo discovery, status check, file and documentation retrieval, outline, search, and a meta-AI query. Indexing is triggered automatically. No obvious gaps for the server's purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Ask any GitHub repository a question. Get source-backed answers.
Connect AI to Stelllink to organize, access, manage and share files, links, and digital workspaces.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ejfkdev/zread-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
