Loading ToolBench
Editor MCP has a single destructive tool (text_edit) with a well-formed schema and reasonable parameter descriptions. The tool name is clear and follows verb_noun convention. However, the description is generic, lacks context on when to use the tool vs alternatives, and does not adequately warn about the destructive nature or prerequisites. Error handling is present in the implementation but not surfaced in the tool description. The schema is complete with proper types and required fields, placing this server in the 'fair' range due to missing LLM-optimization in descriptive text and lack of guidance for recovery/confirmation patterns.
Tool for editing and creating files with text replacement capabilities
Tool description is too generic and lacks LLM-optimization. Current: 'Tool for editing and creating files with text replacement capabilities' (~70 chars). Does not explain WHEN to use, prerequisites, or destructive nature. LLMs need explicit guidance on when to invoke this vs a hypothetical alternative.
Missing confirmation/dry-run pattern for destructive operations. text_edit modifies the filesystem irreversibly (creates, replaces file content). No mechanism exists for the agent to preview changes or confirm before execution. Pattern:confirmation-request recommends a dry-run or explicit confirmation step for irreversible ops.
Parameter 'old_text' has inconsistent behavior documented only in code, not in schema description. When empty, it triggers file creation; when present, it triggers a replacement. The parameter description says 'Exact text to find and replace. If empty, creates a new file instead' but does not clarify the semantic overloading or warn about the risk of creating files when intending to edit.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Error messages in implementation are actionable (e.g., 'file already exists; use old_text to edit existing files', 'no matches found', 'multiple matches found'), but these recovery hints are not documented in the tool description. An LLM reading only the schema/description cannot anticipate these errors or plan recovery.
No parameter constraints on 'path'. Unbounded strings invite path traversal attacks (e.g., '../../etc/passwd'). The tool should validate paths are within an allowed directory or explicitly document the risk in the description.