Internal Documentation Search

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: get_document retrieves a specific document, list_all_docs lists all documents, list_doc_categories lists categories, list_doc_tags lists tags, and search_internal_docs searches documents. The descriptions explicitly differentiate them, such as noting to use search_internal_docs for specific questions instead of list_all_docs.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case: get_document, list_all_docs, list_doc_categories, list_doc_tags, and search_internal_docs. The verbs (get, list, search) are used appropriately and predictably across the set.
Tool Count5/5
With 5 tools, this server is well-scoped for internal documentation search, covering core operations like retrieval, listing, categorization, tagging, and searching. Each tool earns its place without redundancy or bloat, fitting typical needs for a knowledge base interface.
Completeness5/5
The tool surface is complete for the domain of internal documentation search, covering all essential CRUD-like operations: listing (list_all_docs, list_doc_categories, list_doc_tags), retrieving (get_document), and searching (search_internal_docs). There are no obvious gaps, and the tools support filtering and summarization for efficient agent workflows.
Average 4.5/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries full burden. It describes the tool's behavior (listing with optional filtering) and output format (JSON string with document summaries), but lacks details on permissions, rate limits, pagination, or error handling. It adds some context beyond basic functionality but not comprehensive behavioral traits.
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 purpose first, usage guidelines second, and parameter/return details in labeled sections. Every sentence adds value: the first states purpose, the second provides usage context, and the Args/Returns sections clarify inputs/outputs without redundancy.
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 1 parameter with no schema descriptions and an output schema exists, the description provides good coverage: purpose, usage guidelines, parameter semantics, and return format. It doesn't need to detail return values due to the output schema. Minor gaps include lack of behavioral details like pagination or error 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 input schema has 0% description coverage, so the description must compensate. It explains the 'category' parameter's purpose ('Optional filter'), provides allowed values ('standard', 'runbook', or 'adr'), and clarifies it's optional. This adds meaningful semantics beyond the schema's basic type information.
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 ('List') and resource ('all documents in the knowledge base'), and distinguishes it from siblings by mentioning 'search_internal_docs' as an alternative for specific questions. It specifies the scope ('everything available') and optional filtering capability.
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?
Explicitly states when to use ('to get an overview of everything available') and when not to use ('For specific questions, prefer search_internal_docs instead'). It names the alternative tool, providing clear guidance on tool selection.
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 returns 'all available tags sorted alphabetically' and is used for discovery, but it does not mention behavioral traits like rate limits, authentication needs, or whether it's read-only (though implied by 'List'). The description adds some context but lacks details on performance or constraints.
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 purpose, followed by usage guidelines and return details. Every sentence earns its place: the first states what it does, the second explains why to use it, and the third specifies the output format. It is efficiently structured with zero waste.
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 (0 parameters, output schema exists), the description is mostly complete. It explains the purpose, usage, and output format. However, with no annotations, it could benefit from mentioning that it's a read-only operation or any limitations, but the output schema reduces the need for return value details.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate. A baseline of 4 is applied as it compensates for the lack of parameters by focusing on usage and output.
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: 'List all available tags used across internal documents.' It specifies the verb ('List'), resource ('tags'), and scope ('used across internal documents'), and distinguishes it from siblings like list_all_docs (which lists documents) or list_doc_categories (which lists categories).
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 usage guidance: 'Use this to discover what topics are covered and to refine searches with tag filters.' It explains when to use the tool (for discovering topics and refining searches) and implies an alternative (using tag filters in searches, possibly with search_internal_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 describes the search behavior and return format (JSON string with matching documents or not-found message), which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, if there are rate limits, authentication requirements, or how results are ranked/limited.
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 appropriately sized. It starts with the core purpose, provides usage guidelines with bullet points, then documents parameters clearly, and ends with return information. Every sentence earns its place with no wasted 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 (3 parameters, search functionality) and the presence of an output schema (which handles return values), the description is quite complete. It covers purpose, usage guidelines, and parameter semantics effectively. The main gap is the lack of behavioral transparency details that would be important for a search tool (like rate limits or result limits).
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?
With 0% schema description coverage, the description must compensate for the lack of schema documentation. It successfully explains all three parameters: query (free-text search), category (optional filter with valid values), and tags (optional list filter with examples). This adds substantial meaning beyond the bare schema, though it doesn't specify exact format requirements for tags.
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 searches an internal knowledge base for specific document types (standards, runbooks, architecture decisions). It uses the specific verb 'search' with the resource 'internal knowledge base' and distinguishes itself from siblings by focusing on search functionality rather than retrieval or listing operations.
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 with three concrete examples (engineer asks about how something should be done, incident response, or architectural choices). It distinguishes this search tool from siblings like get_document (likely for retrieving specific documents) and list_all_docs (likely for listing without search).
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 discloses that the tool retrieves content or summaries and returns JSON or errors, which covers basic behavior. However, it lacks details on permissions, rate limits, or side effects, leaving gaps for a retrieval tool with no annotation support.
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, parameter details, and return info. Each sentence adds value without redundancy, and it's structured with clear sections (Args, Returns) for readability.
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 annotations, 0% schema coverage, and an output schema present, the description is mostly complete. It covers purpose, usage, parameters, and returns adequately. However, it could improve by mentioning error handling specifics or output structure details, though the output schema mitigates this gap.
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 0%, so the description must compensate fully. It adds significant meaning beyond the schema: it explains the document_id format (e.g., 'STD-001'), clarifies the summary parameter's effect (returns first 500 chars when True to save context), and provides examples, making parameters well-understood.
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 'retrieve' and resource 'internal document by its ID', making the purpose specific. It distinguishes from siblings by focusing on single-document retrieval rather than listing, categorizing, tagging, or searching multiple documents, which is explicitly mentioned in the usage guidance.
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 'Use this after search_internal_docs to get details of a specific document', providing clear when-to-use guidance. It differentiates from siblings by implying this tool is for detailed retrieval post-search, while others handle listing or broader searches, though it doesn't explicitly name alternatives or exclusions.
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 the full burden of behavioral disclosure. It effectively describes the tool's behavior by stating it 'List all available documentation categories with descriptions' and specifies the return format ('JSON string with available categories and their descriptions'), which covers key aspects like output structure. However, it lacks details on potential limitations (e.g., pagination, error cases), keeping it from a perfect score.
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 in the first sentence, followed by usage guidance and return details. Every sentence adds value without redundancy, and the structure is logical and efficient, making it easy for an agent to parse quickly.
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?
Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is complete. It explains what the tool does, when to use it, and the return format, which is sufficient for an agent to invoke it correctly. The presence of an output schema means the description doesn't need to detail return values further.
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 schema description coverage is 100% (as there are no parameters to describe). The description does not add parameter-specific information, which is unnecessary here. A baseline of 4 is appropriate since no parameters exist, and the description compensates by clearly explaining the tool's purpose and output.
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 ('List all available documentation categories with descriptions') and distinguishes it from siblings like 'list_all_docs' (which lists documents) and 'list_doc_tags' (which lists tags). It identifies both the verb ('List') and resource ('documentation categories'), making the purpose unambiguous.
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 ('Use this to understand what kinds of documents are available in the knowledge base before searching'), providing clear context and distinguishing it from alternatives like 'search_internal_docs' (for searching) and 'list_all_docs' (for listing documents). It effectively guides the agent on the tool's role in the workflow.
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:

[![mcp1 MCP server](https://glama.ai/mcp/servers/aklianeva/mcp1/badges/card.svg)](https://glama.ai/mcp/servers/aklianeva/mcp1)

Score Badge

Copy to your README.md:

[![mcp1 MCP server](https://glama.ai/mcp/servers/aklianeva/mcp1/badges/score.svg)](https://glama.ai/mcp/servers/aklianeva/mcp1)

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/aklianeva/mcp1'

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