WeKnora MCP Dispatch
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_AUTH_MODE | No | Authentication mode: 'weknora_api_key' for request-scoped mode; 'shared_secret' for compatibility mode. | |
| MCP_HTTP_PATH | No | HTTP path for the MCP endpoint. | /mcp |
| MCP_READ_ONLY | No | If 'true', only read-only tools are allowed. | false |
| WEKNORA_API_KEY | No | WeKnora API key used in compatibility mode; should be empty in request-scoped mode. | |
| WEKNORA_BASE_URL | No | WeKnora API base URL, e.g., http://app:8080/api/v1 | |
| WEKNORA_VERIFY_SSL | No | Whether to verify WeKnora's HTTPS certificate. | true |
| MCP_SERVER_AUTH_TOKEN | No | Shared secret for MCP server authentication in compatibility mode; should be empty in request-scoped mode. | |
| MCP_API_KEY_VALIDATION_TTL_SECONDS | No | TTL in seconds for API key validation cache. | 60 |
| MCP_API_KEY_VALIDATION_MAX_CONCURRENCY | No | Maximum number of concurrent API key validations. | 16 |
| MCP_API_KEY_VALIDATION_CACHE_MAX_ENTRIES | No | Maximum number of entries in the API key validation cache. | 2048 |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_tenantB | Create a new tenant in WeKnora |
| list_tenantsB | List all tenants |
| create_knowledge_baseC | Create a new knowledge base |
| list_knowledge_basesB | List all knowledge bases |
| get_knowledge_baseC | Get knowledge base details |
| delete_knowledge_baseC | Delete a knowledge base |
| hybrid_searchC | Perform hybrid search in knowledge base |
| create_knowledge_from_fileA | Create knowledge from a local file on the server filesystem |
| create_knowledge_from_urlD | Create knowledge from URL |
| list_knowledgeC | List knowledge in a knowledge base |
| get_knowledgeC | Get knowledge details |
| delete_knowledgeD | Delete knowledge |
| create_modelC | Create a new model |
| list_modelsA | List all models |
| get_modelC | Get model details |
| create_sessionC | Create a new chat session with conversation strategy for a knowledge base |
| get_sessionC | Get session details |
| list_sessionsC | List chat sessions |
| delete_sessionC | Delete a session |
| chatA | RAG pipeline chat: retrieve relevant chunks from knowledge bases, then summarise with LLM. ALWAYS provide knowledge_base_ids (names like 'my-knowledge-base' or UUIDs) so retrieval can run — without them the answer is based on LLM knowledge only. Use list_knowledge_bases to discover available knowledge bases. For multi-step reasoning or tool-calling use agent_chat instead. |
| agent_chatA | Agentic pipeline chat: the agent autonomously calls tools (knowledge_search, web_search, SQL, etc.) to answer the query. Use this for complex multi-step questions or comparative analysis. REQUIRED: agent_id (name or UUID) — use list_agents to discover agents. IMPORTANT: many agents have KBSelectionMode=none and NO built-in knowledge bases. In that case you MUST pass knowledge_base_ids, otherwise the agent will fail with 'no search targets available'. Use get_agent to inspect an agent's kb_selection_mode and knowledge_bases before calling. If kb_selection_mode is 'none' or 'selected' with an empty list, always provide knowledge_base_ids. |
| list_agentsA | List all custom agents available to the current tenant. Use this to discover agent IDs, names, and their KB selection mode before calling agent_chat. |
| get_agentA | Get full configuration of a single agent by UUID or name. Check kb_selection_mode and knowledge_bases fields: if kb_selection_mode is 'none' or 'selected' with an empty knowledge_bases list, you MUST pass knowledge_base_ids when calling agent_chat. |
| list_chunksC | List chunks of knowledge |
| delete_chunkC | Delete a chunk |
| wiki_searchA | Search wiki pages by full-text query. Returns matching wiki pages with title, slug, summary, and content snippets. |
| wiki_read_pageA | Read a wiki page by its slug. Returns full markdown content, metadata, inbound/outbound links, and source references. |
| wiki_index_viewA | Get a structured wiki index with per-type directory groups. Returns an overview of all wiki pages organized by type (entity, concept, summary, etc.). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 28 tools
Most tools target distinct resources (knowledge bases, knowledge items, sessions, agents, models, wiki). The only real overlap is list_knowledge vs list_chunks and possibly chat vs agent_chat, but the descriptions help differentiate these.
The majority follow a verb_noun snake_case pattern (get_, create_, delete_, list_). Minor deviations like chat, agent_chat, and wiki_index_view are still readable and do not break the overall consistency.
With 28 tools, the set exceeds the recommended 25-tool threshold and feels heavy. While the broader domain (knowledge, chat, agents, wiki, models, tenants) justifies some size, the number is still unwieldy for an agent to navigate efficiently.
The surface covers core CRUD for knowledge bases and knowledge items, but lacks update operations for most resources (e.g., update_knowledge, update_model, update_agent). Agent management includes only inspection, and wiki lacks editing capabilities, leaving notable gaps.