Loading ToolBench
Deterministic MCP server for multi-agent project coordination
ContextHub has well-structured tool definitions with complete input schemas and descriptions across all 10 tools. Tool naming follows verb_noun patterns consistently (docs/list, docs/get, docs/create, relations/create, etc.). Descriptions are present and moderately detailed (average ~120 chars), explaining WHAT each tool does. However, critical gaps exist: (1) NO output schemas are documented anywhere, LLMs cannot see what fields to expect from responses, violating pattern:tool and pattern:response-shaper; (2) parameter descriptions are inconsistent, some are detailed ('Project ID', 'Document ID') while others are missing entirely (e.g., docs/list 'limit' and 'offset' parameters lack descriptions of their purpose or constraints); (3) error handling is minimal, no recovery guidance, no actionable error messages visible in the code; (4) no tool annotations (readOnlyHint, destructiveHint) despite clear risk classifications (READ_ONLY, WRITE, DESTRUCTIVE). The schemas themselves are valid JSON Schema with proper types and enums, but lack crucial UX details like minimum/maximum bounds on numeric params and format specs. Composition is excellent, tools are granular and properly chained (docs → relations). Overall, this is a COMPETENT tool definition layer that would benefit from output schema documentation and enhanced error messaging to reach production grade.
Create a new document with ETag generation
Get a specific document by ID
List documents with optional filtering by type, status, and tags
Apply RFC 6902 JSON Patch operations to a document
Update an existing document with ETag-based optimistic concurrency
Comprehensive document validation including schema, cross-doc checks, quality gates, and coverage metrics
Create a typed relation between documents
NO OUTPUT SCHEMAS DOCUMENTED. LLMs cannot determine what fields or structure to expect from any tool response. This violates pattern:tool and pattern:response-shaper, agents cannot plan downstream tool calls or extract required data without knowing response structure. For example, docs/list should declare it returns {documents: [{id, projectId, type, status, content, createdBy, tags, metadata, etag, ...}], total: number, hasMore: boolean}.
MISSING PARAMETER DESCRIPTIONS in docs/list (limit, offset). The 'limit' and 'offset' parameters have no description text explaining their purpose or constraints. LLMs infer meaning from names, but clarity is needed. E.g., limit should say 'Maximum number of documents to return (default 50, max 100)' and offset should say 'Number of documents to skip for pagination (default 0)'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | 0.5.0+ | v1 |
Remove a relation between documents
List relations for a document (incoming and/or outgoing)
Find all paths between documents using recursive graph traversal
NO TOOL ANNOTATIONS (readOnlyHint, destructiveHint). The code clearly marks tools with Risk classifications (READ_ONLY, WRITE, DESTRUCTIVE) but does NOT expose these as tool annotations. MCP spec allows tools to declare readOnlyHint=true for reads and destructiveHint=true for destructive ops. LLMs use these hints to reason about safety, missing annotations force LLMs to guess whether a call is reversible.
MISSING ERROR RECOVERY GUIDANCE. Error handling exists but is generic. When a tool fails (e.g., 'Document not found' or 'ETag mismatch'), LLMs need actionable next steps: 'Try docs/list() to find a valid document ID' or 'Get the current ETag with docs/get(). Retry docs/update() with the correct ifMatch value.' The code should return structured error responses with recovery hints.
MISSING NUMERIC BOUNDS in trace/paths. The 'maxDepth' parameter declares default=10 and maximum=20 but LACKS a minimum value and description of what depth means. Add 'minimum': 1 and clarify: 'Maximum traversal depth (default 10, range 1-20). Larger depths may timeout or exhaust memory.'
UNDERSPECIFIED RELATION KINDS in relations/create and relations/list. The 'kind' enum is extensive (14 values: supports, implements, updates, ...) but the descriptions do NOT explain when to use each. An LLM cannot disambiguate 'depends_on' vs 'implements' vs 'related_to' without semantic guidance. Add brief descriptions: kind=enum with per-value semantics, e.g., 'depends_on: target must be completed before source; implements: source realizes target requirement'.
NO PAGINATION GUIDANCE. docs/list accepts limit and offset but NO description states the maximum allowed limit (claimed as 100 in schema but not in text). Pattern:paginated-result requires stating limit ranges and total count in responses. Add to description: 'Returns paginated results with maximum limit of 100. Include total_count in response so client can iterate.'
ETAG MISMATCH HANDLING UNCLEAR. docs/update and docs/patch both require 'ifMatch' (ETag) but documentation does NOT explain what 'ETag mismatch' means to the user or how to recover. Add: 'If ETag does not match current document version (concurrent edit detected), call docs/get() to fetch the latest version and ETag, then retry.'