Loading ToolBench
MCP server for document management with read, edit, and formatting capabilities
DocumentMCP has 2 tools with basic but incomplete definitions. Tool names are adequate (verb_noun format: read_document, edit_document), and input schemas are present with typed parameters. However, parameter descriptions are minimal (1-2 sentences), output schemas are completely undocumented, and error handling provides no recovery guidance. The edit_document tool lacks critical safety features (no dry-run, no confirmation mechanism for destructive operations). Descriptions are present but generic and under the rubric baseline of 50-200 chars for LLM-optimized tools. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite one tool being write-heavy. The server also exposes an in-memory document store with no persistence layer, audit trail, or permission checks, concerning for a document editing system.
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.
Output schemas completely undocumented. LLMs cannot plan downstream tool calls or extract fields without knowing what read_doc_contents or edit_document returns. Return types should be explicitly documented (string for read_doc_contents, object with success/error status for edit_document).
edit_document lacks safety features. No dry-run mode, no confirmation step, and no idempotency guarantee. This is a destructive operation (WRITE risk), agents can corrupt documents without preview. Pattern: confirmation-request should wrap edit operations.
No tool annotations despite clear risk profiles. edit_document should carry destructiveHint=true; read_doc_contents should carry readOnlyHint=true. These annotations guide agent behavior and safety filters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Error handling provides no recovery guidance. ValueError('Doc with id {doc_id} not found') tells the agent nothing actionable. Should return: 'Document not found. Available documents: [list]. Did you mean one of these?'
Parameter descriptions are minimal. 'Id of the document to read' (26 chars) and 'The text to replace. Must match exactly, including whitespace' (60 chars) fall below the rubric baseline of 50-200 chars for LLM-optimized parameters. No context on when to use each tool or dependencies between them.
No idempotency guarantees for edit_document. If the agent retries after a network failure, the same old_str→new_str replacement happens twice, corrupting the document. edit_document should either be idempotent or provide a way to check if a replacement was already applied.
No permission checks or audit trail. Any caller can read or modify any document. In production, tools editing documents must verify caller authority and log who changed what, when, and why.
In-memory document store ({'deposition.md': '...', ...}) is lost on restart. No persistence layer. For a document editing tool, this is a critical gap, edits disappear.