Internal Documentation Search
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RAG_ENABLED | No | Enables RAG (ChromaDB vector search) support. When enabled, search uses hybrid ranking (keyword scoring blended with vector similarity) and finds related documents via semantic similarity. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_internal_docsA | Search the internal knowledge base for standards, runbooks, and architecture decisions. Use this tool when an engineer asks about:
Args: query: Free-text search query describing what the engineer is looking for. category: Optional filter — one of "standard", "runbook", or "adr". tags: Optional list of tags to filter by (e.g. ["python", "security"]). Returns: JSON string with matching documents (summaries) or a not-found message. |
| get_documentA | Retrieve an internal document by its ID. Use this after search_internal_docs to get details of a specific document. Document IDs follow the format: STD-001, RUN-002, ADR-003, etc. Args: document_id: The document identifier (e.g., "STD-001", "RUN-002"). summary: When True, return only a summary (first 500 chars) instead of the full content. Useful for long documents to save context. Returns: JSON string with the document content (or summary), or an error if not found. |
| list_doc_categoriesA | List all available documentation categories with descriptions. Use this to understand what kinds of documents are available in the knowledge base before searching. Returns: JSON string with available categories and their descriptions. |
| list_doc_tagsA | List all available tags used across internal documents. Use this to discover what topics are covered and to refine searches with tag filters. Returns: JSON string with all available tags sorted alphabetically. |
| list_all_docsA | List all documents in the knowledge base, optionally filtered by category. Use this to get an overview of everything available. For specific questions, prefer search_internal_docs instead. Args: category: Optional filter — one of "standard", "runbook", or "adr". Returns: JSON string with document summaries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| investigate_incident | Help an engineer investigate an active incident using internal runbooks. Args: symptom: What the engineer is observing (e.g. "high CPU", "5xx errors"). service: Optional — the service name that appears to be affected. |
| check_code_standards | Retrieve the relevant coding standards and review code against them. Args: language: Programming language being reviewed (default: python). area: Optional focus area, e.g. "database", "api", "security". |
| explain_architecture_decision | Find and explain why a technology or architectural pattern was chosen. Args: technology: The technology or pattern to explain (e.g. "Kafka", "Kong", "PostgreSQL"). |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| resource_categories | Expose documentation categories as an MCP resource. |
TDQS
Scored across 5 tools
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.
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.
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.
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.