Expose RAG knowledge bases for chat and document ingestion over MCP. Provides tools to list knowledge bases, chat with them using vector search, and add documents for retrieval-augmented generation.
The server has three well-documented tools with mostly complete schemas and clear descriptions. Tool names follow verb_noun conventions (list_*, chat_*, add_*). However, there are gaps in parameter validation, output schema documentation, and error handling guidance. The add_document tool description is incomplete in the provided source. Each tool has a description exceeding 100 characters and most parameters are described, placing this in the 'Fair' to 'Good' range. The server demonstrates thoughtful design (e.g., accepting api_key as parameter rather than relying on environment injection) but lacks formal output schema declarations and structured error recovery patterns.
Upload text content to a knowledge base (vector store). This tool ingests plain text content into a knowledge base's vector database. The text will be split into chunks based on the knowledge base's chunk_size and overlap settings, converted into vector embeddings, stored in the vector database (Qdrant), and made available for retrieval during chat queries.
Chat with a RAG knowledge base using natural language queries. This tool sends a query to a RAG knowledge base which will search through its documents and generate a contextual response using retrieved information. The model uses vector similarity search to find relevant document chunks and then generates an AI response based on those chunks and the system prompt.
List all RAG knowledge bases owned by the authenticated user. This tool retrieves all knowledge bases that belong to the user identified by the provided API key. Each knowledge base contains configuration for RAG (Retrieval-Augmented Generation) including system prompts, chunking parameters, and vector search settings.
Output schemas not formally documented. Tool descriptions mention return types (list, dict) but no JSON Schema definitions visible in source code. LLMs cannot reliably parse response structure.
Error responses lack recovery guidance. 'Authentication required for this knowledge base' and 'Invalid api_key' errors tell the LLM the request failed but not what to do next. Should follow pattern:recovery-guide.
add_document is a WRITE operation but lacks confirmation/dry-run pattern. Agents could accidentally overwrite knowledge bases. Should support confirm_before_execute or at minimum explicit state-change disclaimer.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Parameter 'history' in chat_with_knowledge_base documented as 'list | None' but internal structure (array of {role, content} objects) is only mentioned in description, not in schema. Should be explicit in schema definition.
No rate limits documented for tools that call external APIs (Qdrant, OpenAI). Agents in retry loops could overwhelm downstream services. Should specify max calls/min/user.
api_key passed as tool parameter. While this is intentional (validated at tool boundary), it increases risk that keys appear in logs/traces. Should document that api_keys must be handled with care and never echoed in responses.
No pagination parameters on list_knowledge_bases. If a user has hundreds of knowledge bases, returning all in one response wastes tokens and risks context window exhaustion. Should support limit and offset/cursor.
chat_with_knowledge_base response structure mentions 'sources' as optional but no schema defines what 'sources' contains (document IDs? chunks? scores?). Should be explicit.