Loading ToolBench
MCP server for multi-agent harness systems providing specification management, task tracking, and action logging tools
Server defines 20 tools with complete input schemas and descriptions. Naming follows verb_noun convention (specs.*, actions.*). Descriptions are present but often terse (avg ~80 chars, below 194-char baseline). Parameter descriptions exist but lack detail on constraints, formats, and dependencies. Output schemas are not documented in the provided code. Error handling and recovery guidance are absent. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. Composition is reasonable, tools are single-purpose and chainable via IDs, but descriptions do not guide LLM selection between similar tools (e.g., specs.list vs specs.search).
Close an action with a one-line summary.
Full task action history, including every action and section. Potentially large; use only for audit or diagnosis.
Get one action and a compact index of its sections; section contents are not included.
Write a validated, recipient-directed, bounded handoff for a completed action to resume work without loading the full history.
Compact newest-first action index. Use to discover actions before reading a specific action or section.
Read one section content with an explicit character range. This is the only generic action reader that returns long text.
Output schemas not documented. Tools return data but LLMs cannot infer response structure, forcing them to guess field names and types for downstream tool calls.
Parameter descriptions lack constraint details. 'offset' and 'limit' parameters have no min/max bounds; 'status' and 'specKind' enums are not explained in descriptions; 'content' has no length guidance despite 'no length limit' claim in actions.write.
No tool annotations despite clear risk classifications. specs.create, specs.update_*, specs.link, specs.unlink, actions.* are marked WRITE but lack destructiveHint or idempotentHint annotations. LLMs cannot determine retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Compact newest-first section index for one action. Filter by section types without loading content.
Start a new action for a task. Returns an actionId.
Record a free-form section in an action.
Create a validated specification in docs/specs from structured fields.
Read one specification body by slug with an explicit offset and limit.
Create a bidirectional validated relationship between two specifications.
List specification headers from docs/specs without loading bodies.
List related specification headers and edges without their bodies.
Search specification metadata and body content with bounded excerpts.
Change a specification status while enforcing source approval rules.
Remove a relationship and its inverse from two specifications.
Replace a specification body while preserving its validated frontmatter.
Update validated metadata fields without hand-editing frontmatter.
Validate all docs/specs frontmatter, links, and source references.
Descriptions do not guide LLM selection. specs.list, specs.get, specs.search, and specs.related all operate on specs but lack clear guidance on when to use each. 'List specification headers' vs 'Search specification metadata' is ambiguous without examples or use-case hints.
No error handling or recovery guidance. Tools do not document what errors are possible, whether they are retryable, or what the LLM should do next (e.g., 'slug not found, try specs.search() first').