Loading ToolBench
LLM-maintained knowledge base for your projects, exposed over the Model Context Protocol
Four well-named, read-only tools with clear descriptions (avg 156 chars) and complete input schemas. All parameters are typed and described. Output schemas are documented via Go struct tags. Naming follows verb_noun pattern (search_*, get_*). No critical security issues detected, all tools are read-only with no state mutation. Main gaps: no error handling guidance (recovery hints, actionable error messages), no pagination support despite potential for large result sets, and no tool annotations (readOnlyHint present in risk metadata but not in MCP schema). Composition is sound, tools chain naturally (search → get). Descriptions are functional but could be more LLM-optimized (e.g., 'when to use' guidance missing).
Fetch the full content of a single knowledge entry by topic. Omit the layer to search every layer for that topic.
Fetch the full extracted wiki content for a single project, or for a specific service within a multi-service project.
Search the knowledge layers — org-wide, department or client knowledge that is not tied to a single project (standards, decisions, processes, glossaries). Filter by query and/or layer (both optional). Every result names the layer it came from. Call with no arguments to list all entries and discover which layers exist.
Search the llmwiki knowledge base for projects. Filter by client and/or project name (both optional). Returns project metadata, tags and a short domain summary for each match.
No error handling guidance. Tools lack recovery hints (e.g., 'If project not found, try search_projects() first'). Error responses will not guide LLM on next steps.
No pagination support. search_projects and search_knowledge may return unbounded result sets. Large knowledge bases risk context window exhaustion. Missing limit/offset parameters and total count in responses.
Tool annotations missing from MCP schema. Risk metadata (READ_ONLY) exists in source but not exposed via readOnlyHint in tool definition. LLM cannot infer tool safety from schema alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Descriptions lack 'when to use' guidance. Descriptions state WHAT tools do but not WHEN to call them vs. similar tools or how they fit into multi-step workflows.
No validation constraints in parameter descriptions. E.g., 'project' param accepts 'case-insensitive substring match' but no guidance on min/max length, special characters, or failure modes if multiple projects match.