Knowledge Assistant MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RAG_TOP_K | No | Number of chunks to retrieve (default: 5) | 5 |
| MODEL_NAME | No | Gemini model (default: gemini-2.0-flash) | gemini-2.0-flash |
| OPIK_API_KEY | No | Opik API key for observability – optional. | |
| GOOGLE_API_KEY | Yes | Google AI (Gemini) API key – required. Get from Google AI Studio. | |
| EMBEDDING_MODEL | No | Google embedding model for RAG (default: models/gemini-embedding-001) | models/gemini-embedding-001 |
| CHROMA_COLLECTION | No | ChromaDB collection name (default: knowledge_base) | knowledge_base |
| OPIK_PROJECT_NAME | No | Opik project name (default: knowledge-assistant) | knowledge-assistant |
| CHROMA_PERSIST_DIR | No | ChromaDB persistence directory (default: ./chroma_data) | ./chroma_data |
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 |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_knowledge_baseA | Ask the knowledge assistant a question. Runs a multi-agent pipeline: coordinator -> retriever (RAG) -> synthesizer. Returns a proposed answer for your review. After reviewing, call approve_or_edit_answer to approve or request edits (human-in-the-loop). |
| approve_or_edit_answerA | Human-in-the-loop: approve the proposed answer from query_knowledge_base, or request edits. Set approved=True to accept, or approved=False and provide user_feedback for changes. |
| add_documentsA | Add a document (text) to the knowledge base. Use source to label where it came from. |
| search_knowledge_baseA | Search the knowledge base only (retriever); returns chunks without generating an answer. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| knowledge_assistant_workflow | Multi-agent RAG workflow with human-in-the-loop: query → review proposal → approve or edit. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| server_info | Server and knowledge base configuration (name, version, collection, RAG settings). |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: query_knowledge_base runs the full RAG pipeline and returns a proposed answer, search_knowledge_base performs raw retrieval only, approve_or_edit_answer handles the human-in-the-loop review step, and add_documents ingests new content. Although query and search both access the knowledge base, their outputs and workflows are fundamentally different and clearly described.
All tool names follow a consistent verb_noun pattern in snake_case: query_knowledge_base, approve_or_edit_answer, add_documents, search_knowledge_base. The naming is uniform and predictable, with no mixed conventions or ambiguous verbs.
With exactly 4 tools, the server is well-scoped for its purpose. Each tool addresses a distinct stage of the knowledge assistant workflow (ingestion, retrieval, synthesis, and review), and the count feels neither sparse nor bloated for the domain.
The core workflow is covered: add documents, search raw chunks, generate a proposed answer, and approve/request edits. However, there are minor gaps in document lifecycle management—no tools for deleting, updating, or listing documents—which could force workarounds in some use cases.