Loading ToolBench
A CLI chat client for Claude backed by a Model Context Protocol document server
DocumentMCP has clear tool names (read_doc_contents, edit_doc) with proper verb-noun structure. Both tools have descriptions and input schemas with typed parameters. However, parameter descriptions are minimal (10-30 chars), falling below the 72-char baseline for production tools. Output schemas are not documented. Error handling exists but lacks recovery guidance. The edit_doc tool lacks idempotency hints and confirmation patterns for a destructive operation. No tool annotations (readOnlyHint, destructiveHint) are present despite MCP support.
Edit a document by replacing a string in the documents content with a new string.
Read the contents of a document and return it as a string.
Parameter descriptions are too brief (10-30 chars vs 72-char baseline). 'The ID of the document to read' and 'The text to replace' lack context on format, constraints, or valid values.
edit_doc is a destructive operation (WRITE risk) but lacks confirmation pattern, dry-run option, or idempotency hint. No tool annotation (destructiveHint) present. Agents may apply edits without safeguards.
Output schemas are not documented. Callers cannot infer return types (string vs object vs array). LLMs must guess what fields are available for downstream tool chaining.
Error messages are generic ('Document with ID not found'). No recovery guidance or available alternatives offered. LLMs cannot self-correct without extra discovery calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
No tool annotations present. read_doc_contents should have readOnlyHint=true; edit_doc should have destructiveHint=true. These hints help agents reason about side effects.