DocNav-MCP

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_documents enumerates loaded docs, load_document/remove_document manage the document lifecycle, get_outline provides structure, navigate_section gives context, read_section extracts content, search_document finds text, and get_document_stats offers metadata. An agent can easily differentiate them based on their specific actions and targets.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as list_documents, load_document, get_outline, and navigate_section. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions across the eight tools.
Tool Count5/5
With 8 tools, this server is well-scoped for document navigation and analysis, covering core operations like loading, listing, navigating, reading, searching, and removing documents, along with metadata and outline retrieval. Each tool earns its place without redundancy, making the count ideal for the domain.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for document navigation: load_document (create), list_documents (read), remove_document (delete), and operations for analysis (get_outline, navigate_section, read_section, search_document, get_document_stats). There are no obvious gaps, ensuring agents can perform all essential tasks without dead ends.
Average 3.3/5 across 8 of 8 tools scored.
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 is failing
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

Behavior2/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 states the tool retrieves 'statistics and structure info,' but lacks details on what specific statistics are included, whether it's a read-only operation, potential errors (e.g., if the document isn't loaded), or performance considerations. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 appropriately sized and front-loaded: the first sentence clearly states the purpose, followed by structured 'Args' and 'Returns' sections. While efficient, the 'Returns' section is vague ('Document statistics and structure info'), and the overall text could be more informative without sacrificing brevity.
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 low complexity (one parameter) and the presence of an output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks depth in usage guidelines and behavioral details. The output schema likely handles return values, so the description's vagueness there is acceptable, but overall completeness is limited.
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 description adds minimal meaning beyond the input schema: it defines 'doc_id' as 'Document identifier,' which is slightly more informative than the schema's 'Doc Id' title. However, with 0% schema description coverage and only one parameter, the baseline is high, and this small addition doesn't fully compensate for the lack of detail (e.g., format or source of the identifier).
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: 'Get statistics about a loaded document.' It specifies the verb ('Get') and resource ('loaded document'), making the function evident. However, it doesn't explicitly differentiate from siblings like 'get_outline' or 'list_documents,' which might provide overlapping or related information, so it falls short of a perfect score.
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?
The description provides minimal guidance: it implies usage when statistics about a loaded document are needed, but offers no explicit advice on when to use this tool versus alternatives like 'list_documents' or 'search_document.' There's no mention of prerequisites (e.g., the document must be loaded first) or exclusions, leaving the agent to infer context from the tool name alone.
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?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It implies a read-only operation ('Get') but doesn't disclose error handling (e.g., invalid IDs), performance traits (e.g., speed), authentication needs, or whether it modifies state. The return statement is vague about format.
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 appropriately sized and front-loaded, with the core purpose in the first sentence and parameter/return details in a structured format. Every sentence adds value, though the return statement could be more specific to enhance clarity without sacrificing brevity.
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 (2 required parameters) and the presence of an output schema (which handles return values), the description is minimally adequate. It covers purpose and parameters but lacks usage guidelines and behavioral details, making it incomplete for optimal agent use without additional context.
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%, but the description adds basic meaning: 'doc_id' is a 'Document identifier' and 'section_id' is a 'Section ID to navigate to'. This clarifies their roles beyond schema titles. However, it doesn't detail expected formats (e.g., string patterns) or constraints, leaving gaps in documentation.
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 with a specific verb ('Get') and resource ('navigation context for a section'), including what information it retrieves (parent, siblings, children). It distinguishes itself from siblings like 'read_section' (which reads content) or 'get_outline' (which provides document structure), though it doesn't explicitly name these alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid document/section IDs), compare to siblings like 'get_outline' for broader navigation, or specify use cases like exploring document hierarchy versus reading content.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Remove' implies a destructive operation, the description doesn't clarify if this is permanent deletion, reversible removal, or what happens to related data. No information about permissions, side effects, or error conditions beyond the generic 'error message' mention.
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 appropriately concise with clear sections (purpose, args, returns). The purpose statement is front-loaded, though the Args/Returns formatting could be more integrated. No wasted sentences, but the structure is somewhat mechanical rather than flowing naturally.
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 this is a destructive operation with no annotations, 0% schema coverage, but has an output schema, the description is minimally adequate. It explains what the tool does and the parameter format, but lacks crucial context about the removal's nature, permissions needed, or relationship to other document operations. The output schema existence reduces need to detail return values.
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 description adds minimal parameter semantics beyond the schema. It specifies 'doc_id' is a 'Document identifier (UUID)', which provides format information not in the schema (0% coverage). However, it doesn't explain where to obtain this ID, validate it, or provide examples. Baseline 3 is appropriate given schema coverage is 0% but description adds some value.
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 action ('Remove') and resource ('document from the navigator'), providing specific verb+resource pairing. However, it doesn't differentiate from potential siblings like 'delete_document' or explain what distinguishes 'remove' from other operations in this context.
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 is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, consequences, or relationships to sibling tools like 'list_documents' or 'load_document' that might be used before or after removal.
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?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions 'Formatted search results with context' which gives some output expectation, but doesn't disclose important behavioral traits like whether this is a read-only operation, performance characteristics, authentication needs, rate limits, or what happens with invalid inputs. The description doesn't contradict annotations (none exist).
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 appropriately sized and well-structured with clear sections (Args, Returns). The purpose is stated upfront, and each section adds value. However, the 'Args' and 'Returns' headings are somewhat redundant since the schema already defines parameters and there's an output schema, making the structure slightly less efficient than it could be.
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 2 parameters with 0% schema coverage but an output schema exists, the description provides basic parameter semantics and output expectations. However, for a search tool with no annotations, it should ideally explain more about search behavior (case sensitivity, partial matching, performance implications) and relationship to sibling tools. The existence of an output schema reduces the need to detail return values, but behavioral context remains sparse.
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%, but the description adds basic semantic meaning for both parameters: 'doc_id: Document identifier' and 'query: Search term or phrase'. This compensates somewhat for the lack of schema descriptions, though it doesn't provide format details, constraints, or examples. With 2 parameters and no schema descriptions, this provides baseline compensation.
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 with 'Search for specific content within a document' - a specific verb ('Search') and resource ('content within a document'). It distinguishes from siblings like 'list_documents' (which lists documents) and 'read_section' (which reads a specific section), but doesn't explicitly differentiate from all siblings like 'navigate_section' which might also involve document navigation.
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 is provided. The description doesn't mention when search is appropriate versus using 'read_section' for direct reading, 'navigate_section' for structural navigation, or 'list_documents' for finding documents. There's no context about prerequisites or limitations.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool loads a document and returns a success message with an auto-generated ID, which implies a write operation (creating/registering a document). However, it lacks critical details: whether this requires specific permissions, if the document becomes available for other tools, what happens on duplicate loads, or any rate limits. The return format is mentioned but not elaborated.
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 appropriately concise and structured: a purpose statement followed by 'Args' and 'Returns' sections. Every sentence adds value, with no redundant information. It could be slightly more front-loaded by integrating the return info into the main description, but it's efficient overall.
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 (a write operation with 1 parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. It covers purpose and basic parameter semantics but lacks behavioral details (e.g., side effects, error conditions) and usage guidelines, leaving gaps for the agent to navigate sibling tools effectively.
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 description adds meaningful context for the single parameter 'file_path' by specifying it's a 'Path to the document file,' which clarifies its role beyond the schema's generic 'File Path' title. With 0% schema description coverage, this compensates well, though it doesn't detail format constraints (e.g., absolute vs. relative paths, supported file types).
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: 'Load a document for navigation and analysis.' It specifies the verb 'load' and resource 'document' with the intended use cases. However, it doesn't explicitly differentiate from siblings like 'list_documents' or 'read_section', which would require more specific scope definition.
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?
The description provides minimal usage guidance. It mentions 'navigation and analysis' as contexts, but offers no explicit when-to-use rules, alternatives (e.g., vs. 'read_section' or 'list_documents'), or prerequisites. The agent must infer usage from the purpose statement alone.
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 of behavioral disclosure. It mentions that it returns 'List of loaded documents with their metadata', which adds some context about the output. However, it doesn't describe important behavioral aspects like whether this is a read-only operation, if it requires specific permissions, or if there are rate limits. The description provides basic output information but lacks comprehensive behavioral details.
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 extremely concise and well-structured. It uses just two sentences: one stating the purpose and one describing the return value. Every word earns its place with no wasted text, and the information is front-loaded with the core purpose stated first.
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 that the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is reasonably complete. It explains what the tool does and what it returns, which is sufficient for a simple list operation. However, it could benefit from more behavioral context (like whether it's safe to call frequently) since no annotations are provided.
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, and the input schema has 100% description coverage (though empty). The description doesn't need to explain any parameters, which is appropriate. Since there are no parameters to document, the description correctly focuses on the tool's function and output rather than parameter details.
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: 'List all currently loaded documents.' This specifies the verb ('List') and resource ('currently loaded documents'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_document_stats' or 'search_document', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_document_stats' (for statistics) and 'search_document' (for searching), there's no indication of when 'list_documents' is appropriate versus these other options. The description only states what it does, not when to use it.
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. It discloses that the tool reads content (implying a read-only operation) and returns section content with subsections, which adds useful behavioral context. However, it doesn't mention potential errors (e.g., invalid IDs), permissions, or rate limits, 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 and front-loaded, starting with the core purpose in the first sentence. The 'Args' and 'Returns' sections are structured efficiently, with each sentence adding clear value without unnecessary details or repetition.
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 (2 required parameters) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, parameters, and return behavior, but lacks details on error handling or usage constraints, which could be beneficial despite the output schema.
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?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'doc_id' is a 'Document identifier' and 'section_id' is a 'Section ID from outline' with examples (e.g., 'h1_0', 'h2_1'), clarifying the format and purpose of both parameters that the schema alone does not provide.
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 ('Read content') and resource ('specific document section'), distinguishing it from siblings like 'get_outline' (structure) and 'load_document' (full document). It precisely defines what the tool does without being vague or tautological.
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 by specifying it reads 'a specific document section', suggesting it should be used when you need content from a particular section rather than the whole document. However, it doesn't explicitly state when to use this tool versus alternatives like 'load_document' or 'navigate_section', nor does it mention prerequisites or exclusions.
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 full burden. It states this is a read operation ('Get'), which is clear, but lacks details on permissions, rate limits, or error handling. The 'Tips' section adds some context about typical workflow, but behavioral traits like response format or potential failures are not disclosed beyond the basic return statement.
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 well-structured and front-loaded with the core purpose, followed by tips and parameter details. Every sentence adds value: the first states the action, the second provides usage guidance, and the last two clarify parameters and returns. No redundant or verbose content is present.
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 (2 parameters, no annotations, but has output schema), the description is largely complete. It covers purpose, usage, parameters, and returns, though behavioral aspects like error cases or performance are omitted. The output schema exists, so the description needn't detail return values, but more transparency on operations would enhance completeness.
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 description coverage is 0%, so the description must compensate. It explains 'doc_id' as 'Document identifier' and 'max_depth' as 'Maximum heading depth to include, defaults to 3', adding meaningful context beyond the schema's bare titles. However, it doesn't specify format for 'doc_id' (e.g., string pattern) or constraints for 'max_depth' (e.g., valid range), leaving some gaps.
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 verb 'Get' and resource 'document outline/table of contents', making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'get_document_stats' or 'read_section' by focusing on structural metadata rather than content or statistics.
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 with 'Tips: First use this tool to understand document structure after you load a document.' This tells the agent when to use it (after loading) and implies it's for initial exploration rather than content reading, distinguishing it from alternatives like 'navigate_section' or 'read_section'.
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:

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

Score Badge

Copy to your README.md:

[![DocNav-MCP MCP server](https://glama.ai/mcp/servers/shenyimings/DocNav-MCP/badges/score.svg)](https://glama.ai/mcp/servers/shenyimings/DocNav-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/shenyimings/DocNav-MCP'

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