Atlas-Docs

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: list_docs discovers documentation sets, get_docs_index provides an overview, get_docs_page retrieves specific content, get_docs_full gets everything, and search_docs finds keywords. The descriptions explicitly guide usage, making misselection unlikely.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case: list_docs, get_docs_index, get_docs_page, get_docs_full, and search_docs. The naming is predictable and readable, using clear verbs like 'get', 'list', and 'search' paired with descriptive nouns.
Tool Count5/5
With 5 tools, the count is well-scoped for a documentation server, covering discovery, navigation, retrieval, and search without being overwhelming. Each tool earns its place by addressing a specific need in the documentation workflow, from initial exploration to detailed content access.
Completeness5/5
The tool set provides complete coverage for documentation access: list_docs for discovery, get_docs_index for navigation, get_docs_page for targeted retrieval, get_docs_full for comprehensive content, and search_docs for keyword-based finding. There are no obvious gaps, and the descriptions guide agents through a logical workflow.
Average 4.1/5 across 5 of 5 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns 'matching pages ranked by relevance with their paths and descriptions,' which adds value beyond the input schema. However, it lacks details on permissions, rate limits, error handling, or pagination, leaving gaps for a search tool.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by usage guidance and behavioral details. Every sentence earns its place with no wasted words, making it efficient and well-structured.
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 tool's moderate complexity (search with ranking), no annotations, no output schema, and low schema coverage, the description is partially complete. It covers purpose, usage, and return format but misses details on parameters, error cases, and full behavioral context, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It implies 'docName' refers to a 'documentation set' and 'query' is for 'keywords, concepts, or topics,' but doesn't explain their formats, constraints, or examples. This adds minimal meaning beyond the bare schema.
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's purpose: 'Searches a documentation set for specific content' with specific verbs (search, find) and resources (documentation set, pages). It distinguishes from siblings by mentioning 'Follow up with get_docs_page to get full content,' though it doesn't explicitly differentiate from all siblings like get_docs_full or get_docs_index.
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 clear context on when to use it: 'Use this to find pages containing particular keywords, concepts, or topics' and suggests an alternative for follow-up: 'Follow up with get_docs_page to get full content.' However, it doesn't explicitly state when not to use it or compare to all sibling tools like get_docs_full or list_docs.
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 the tool 'Retrieves' content (implying read-only) and returns 'complete content of a single documentation page', which adds useful context about behavior. However, it lacks details on error handling, rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.
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 appropriately sized with three sentences, each earning its place: first states the purpose, second provides usage guidelines, third explains return behavior. It is front-loaded with the core function and avoids unnecessary details.
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 annotations, no output schema, and low schema coverage, the description does a decent job covering purpose and usage. However, it lacks details on return format (beyond 'complete content'), error cases, or parameter semantics, making it incomplete for a tool with such minimal structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'relative path' which relates to 'pagePath', but does not explain 'docName' or provide any details on parameter formats, constraints, or examples. The description adds minimal value beyond the bare schema, failing to adequately cover the two undocumented parameters.
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's purpose with specific verbs ('Retrieves', 'get detailed information') and resources ('documentation page's content', 'relative path'). It distinguishes from siblings by specifying it's for a 'specific' page after using get_docs_index or search_docs, unlike get_docs_full or list_docs which likely handle broader scopes.
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 explicitly states when to use this tool ('after identifying the relevant page through get_docs_index or search_docs') and provides alternatives by naming sibling tools (get_docs_index, search_docs). It clearly defines the context for usage versus other tools.
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?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that the tool returns 'a large volume of text' (output characteristic) and implies it's a read operation ('retrieves'). However, it doesn't mention potential performance impacts, rate limits, or authentication requirements that would be helpful for a tool returning large volumes.
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 perfectly concise with three sentences that each earn their place: first states purpose, second provides usage guidelines, third warns about volume and suggests alternatives. It's front-loaded with the core functionality and wastes no words.
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 moderate complexity (single parameter, no output schema, no annotations), the description is mostly complete: it explains purpose, usage context, and output characteristics. The main gap is the undocumented parameter, but otherwise it provides good context for agent decision-making.
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 0%, so the description must compensate. It doesn't mention the single parameter 'docName' at all, leaving its meaning undocumented. The baseline would be lower, but the description's strong guidance on usage provides some indirect context about what documentation is being retrieved.
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's purpose with specific verbs ('retrieves', 'consolidated') and resource ('complete documentation content'), distinguishing it from siblings by emphasizing comprehensive vs. targeted retrieval. It explicitly contrasts with get_docs_page and search_docs for targeted information.
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 provides explicit guidance on when to use this tool ('when you need comprehensive knowledge or need to analyze the full documentation context') and when not to ('consider using get_docs_page or search_docs for targeted information'), naming specific alternatives. This gives clear context for selection among siblings.
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 the return format ('Returns a markdown page with a list of available pages'), which is useful behavioral context. However, it lacks details on error handling, rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.
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 front-loaded with the core purpose, followed by usage guidance and return details in three concise sentences. Each sentence adds value without redundancy, making it efficient and well-structured.
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 low complexity (1 parameter, no output schema, no annotations), the description is mostly complete: it covers purpose, usage, return format, and sibling differentiation. However, it lacks details on parameter semantics and behavioral aspects like errors, which prevents a perfect score.
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?
The schema has 1 parameter with 0% description coverage, so the description must compensate. It implies the parameter is used to specify the documentation set ('pages in a documentation set'), adding meaning beyond the bare schema. However, it doesn't detail what 'docName' represents (e.g., format, examples), keeping it from a perfect score.
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 specific action ('Retrieves'), resource ('condensed, LLM-friendly index of the pages in a documentation set'), and distinguishes it from siblings by mentioning 'initial exploration' and contrasting with 'get_docs_page' for full content. It goes beyond just restating the name/title.
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?
It explicitly states when to use this tool ('for initial exploration to understand what's covered and identify relevant pages') and provides a clear alternative ('Follow up with get_docs_page to get full content'), which helps differentiate it from sibling tools like get_docs_full, list_docs, and search_docs.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool returns ('name, description and source url for each documentation set') and its prerequisite role, but doesn't mention potential limitations like pagination, rate limits, authentication requirements, or error conditions. For a tool with zero annotation coverage, this represents adequate but incomplete behavioral transparency.
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 perfectly concise with three sentences that each earn their place: first states the purpose, second provides usage guidance, third explains the return format and prerequisite nature. No wasted words, front-loaded with the core purpose, and appropriately sized for the tool's complexity.
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 (0 parameters, no output schema, no annotations), the description provides excellent context about purpose, usage sequencing, and return format. The only minor gap is the lack of output schema means the description doesn't fully specify the return structure, but for a discovery/list tool, the described return fields (name, description, source url) are sufficient for most use cases.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the description focuses on purpose and usage rather than parameter documentation.
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 specific verb ('Lists') and resource ('all available documentation libraries and frameworks'), and distinguishes it from siblings by explaining it's a discovery tool that must be used first to get docName values needed for other documentation tools. This provides excellent differentiation from sibling tools like get_docs_full, get_docs_index, get_docs_page, and search_docs.
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 explicitly states when to use this tool ('as your first step to discover available documentation sets') and provides clear prerequisites ('Required before using other documentation tools since you need the docName'). This gives perfect guidance on when this tool should be used versus its alternatives.
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:

[![1777316659387395 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659387395/badges/card.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659387395)

Score Badge

Copy to your README.md:

[![1777316659387395 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659387395/badges/score.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659387395)

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/xiaobenyang-com/1777316659387395'

If you have feedback or need assistance with the MCP directory API, please join our Discord server