zread-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.8/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![zread-mcp MCP server](https://glama.ai/mcp/servers/ejfkdev/zread-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ejfkdev/zread-mcp)

Score Badge

Copy to your README.md:

[![zread-mcp MCP server](https://glama.ai/mcp/servers/ejfkdev/zread-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ejfkdev/zread-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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