Loading ToolBench
MCP server providing knowledge base access through hybrid search (FTS5 + semantic), knowledge graph queries (KAG), document retrieval, and statistics. Supports RAG workloads with context-aware search.
The Conduit KB MCP server provides 6 well-defined read-only tools for knowledge base and knowledge graph operations. Naming follows verb_noun conventions (kb_search, kb_list_sources, kb_get_document, kb_stats, kb_search_with_context, kag_query). All tools have non-empty descriptions (118-194 chars, within baseline of 34-392). All input parameters have type definitions and descriptions. However, output schemas are not visible in the source code, only input schemas are documented. Error handling guidance is absent; no recovery hints or categorization. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all being read-only operations. Parameter descriptions lack actionable constraints (e.g., recall_mode enum values are documented but no guidance on when to use each). Composition is strong: tools chain well (kb_search returns document_ids that kb_get_document accepts). All tools are idempotent and safe to retry.
Query the knowledge graph for entities and their relationships. Use for multi-hop reasoning, aggregation queries, or finding connections between concepts. Complements RAG search with structured entity lookups.
Retrieve the full content of a specific document by its ID. Use document IDs from search results.
List all knowledge base sources with their IDs, paths, document counts, and sync status. Use this to discover available sources before searching or filtering.
Search the knowledge base for relevant documents using hybrid search (FTS5 keyword matching + semantic similarity when available). Use short keyword phrases for best results.
Search with processed, prompt-ready results. Returns merged chunks from same documents, filters boilerplate, and provides citation-ready source information. Best for RAG use cases.
Get knowledge base statistics including source counts, document counts, chunk counts, and search capability status.
Output schemas are not documented in source code. Only input schemas are visible. LLMs cannot plan downstream calls or extract structured data without knowing what fields to expect from responses.
No error handling guidance or recovery hints. Tools lack descriptions of failure modes and what the agent should do when a search returns empty results or a document_id is invalid. Bare error codes provide no actionable next steps.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent. All 6 tools are read-only and idempotent, which should be explicitly declared for agent safety and optimization.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Parameter constraints are documented in descriptions but not formalized. E.g., 'limit' accepts 1-50 for kb_search but description does not explicitly state minimum/maximum bounds. Validation must occur server-side with actionable error messages.
kb_list_sources has an empty properties object in input schema (no parameters documented). Description says 'Use this to discover available sources' but does not clarify if filters (e.g., by source name, status) are supported. Input schema should reflect supported parameters or be explicitly documented as accepting no input.