Loading ToolBench
A MCP server designed to bridge the gap between specialized knowledge domains and AI assistants. Tools to query multiple custom knowledge bases using similarity search and a ranked knowledge-graph.
Knowledge Base MCP has 6 tools with mostly complete schemas and descriptions. Tool names follow verb_noun conventions (retrieve, answer, list_*, query_*). Descriptions are present and reasonably detailed (ranging from 80-400+ characters), explaining WHAT each tool does and WHEN to use it. However, several critical gaps limit the score: (1) Parameters lack detailed constraints and validation guidance, e.g., 'mode' accepts 6 values but no enum is declared in schema, just mentioned in description; (2) Output schemas are not documented, callers cannot see what fields to expect from retrieve() or answer(); (3) Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or actionable recovery steps; (4) Some parameter descriptions are generic or incomplete (e.g., 'ids' array lacks detail on what document IDs format/structure looks like); (5) No tool annotations (readOnlyHint, idempotentHint) despite all 6 tools being read-only and idempotent; (6) Dependency hints are missing, e.g., answer() and retrieve() solve overlapping problems but no guidance on when to choose one over the other.
Returns an LLM-synthesised answer from the retrieval results. Good when you want a concise answer in one call. Uses the LLM of the mcp server to generate an answer from a knowledge base and return it with citations. Server AI must generate the answer and that increases token volume for this LLM.
List all available knowledge bases.
Simplified global mode query - Best for relationship discovery. Focuses on understanding relationships and connections between different aspects of your domains.
Simplified hybrid mode query - Best for cross-domain queries. Combines both entity-focused and relationship-focused retrieval, ideal for comprehensive coverage spanning multiple knowledge areas.
Simplified local mode query - Best for entity-specific queries. Focuses on finding specific concepts, tools, or entities within your domains.
Output schemas not documented. Tools retrieve(), answer(), query_local(), query_global(), query_hybrid() do not declare what fields/structure callers should expect. LLMs cannot plan downstream operations or extract required data without knowing response structure.
'mode' parameter accepts 6 values (mix, local, global, hybrid, naive, bypass) but no enum constraint is declared in the input schema. Values are only listed in the description text. This forces LLMs to parse description prose rather than respecting formal enum constraints, increasing hallucination risk.
No error handling guidance. Tools do not document retryability, user-fixable vs fatal errors, or recovery steps. If a query fails, the agent has no actionable error message to guide next steps (e.g., 'Knowledge base not found. Available bases: [...]').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Returns the retrieval results only. Good when the client AI needs evidence for its own chain-of-thought or wish to cross-check multiple modes/top-k values cheaply. Retrieves raw context passages from a knowledge base without synthesizing an LLM answer. Client AI must generate the answer and that increases token volume for the client AI. Faster response, good for multiple queries.
No tool annotations despite all 6 tools being read-only and idempotent. Adding readOnlyHint and idempotentHint would signal to agents that these tools are safe to retry and cannot modify state, enabling smarter error handling and caching.
Overlapping tool purpose without differentiation guidance. retrieve(), answer(), query_local(), query_global(), query_hybrid() all perform knowledge base queries with different modes/outputs but lack explicit guidance on when to choose one over another. LLMs may waste reasoning cycles or make wrong selections.
'ids' parameter (array of document IDs) lacks format/structure guidance. What does a valid document ID look like? How are they obtained? Should the array be empty or null to mean 'all documents'? Description gives no hints.
list_knowledgebases description is extremely brief ('List all available knowledge bases.'). Does not explain when to call it (e.g., 'Call this first to discover available knowledge bases before querying') or what structure is returned.