Loading ToolBench
Knowledge management system with role-casting and usage-aware retrieval. Exposes the knowledge harness as MCP tools for Claude Code integration.
Knowledge Harness has well-structured tool definitions with clear naming (verb_noun pattern: kb_search, kb_ingest, kb_record, kb_reflect, kb_quick_insights) and comprehensive descriptions (194 - 350 chars, well above 10-char minimum). All 6 tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling guidance is absent; tools do not indicate what to do on failure. Task-type enum in kb_search is well-designed (7 values), but kb_record lacks output documentation and kb_reflect/kb_quick_insights have empty input schemas with no description of what they return. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (kb_ingest and kb_record are WRITE operations).
Add content to the knowledge base. Content is chunked, summarized, and embedded automatically. Use this to store useful information for future retrieval.
Quick health check of the knowledge base. Returns summary statistics: total chunks, documents, sources, recent usage patterns, and any critical issues.
Record usage outcome for retrieved knowledge. Call this after using knowledge to help the system learn what works. This is how the knowledge base learns which content is good for which tasks.
Analyze knowledge base health and learning patterns. Runs consolidation to generate functional profiles, identify gaps, surface contradictions, and discover co-retrieval patterns.
Search the knowledge base using multi-strategy retrieval (keyword, semantic, concept, usage history). Returns ranked chunks with rich context for LLM reasoning: - Individual usage traces with dates, task types, outcomes, and notes - Task-type breakdown (success rates per task type) - Functional profiles (consolidated learning about what content is good for) - Source profiles (what this source is generally good for) The usage history lets you reason about whether a chunk is likely to help with your current task. Optionally provide task_type to boost chunks that have worked well for similar tasks.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). kb_reflect and kb_quick_insights have empty input schemas with no description of return values.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). kb_ingest and kb_record are WRITE operations that modify state; LLMs need explicit hints to understand retry safety and side effects.
No error handling guidance. Tools do not indicate what to do on failure (retryable vs fatal), what invalid inputs look like, or recovery steps. Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Direct semantic similarity search (embedding-based only). Use this when you want pure meaning-based matching without keyword or usage weighting.
kb_record lacks output documentation. Does it return chunk IDs, confirmation, or usage stats? LLM cannot chain results to downstream tools.
kb_reflect and kb_quick_insights have empty input schemas (no properties). Descriptions mention 'consolidation' and 'health check' but do not explain what parameters control behavior or what output structure to expect.