Loading ToolBench
MCP server for structured, semantic editing of Markdown files
This MCP server provides 15 tools for markdown editing with reasonable naming and schema structure, but suffers from significant issues in parameter documentation, output schema clarity, and error handling guidance. Tool names follow verb_noun conventions well (search_tools, get_document_structure, replace_content, delete_element), which is good. However, descriptions vary wildly in quality, some are too generic ('Scalability feature: find the right tool...'), while parameter descriptions are often missing or incomplete. Input schemas are present for all tools but lack description text on several parameters. Output schemas are not documented at all, making it unclear what fields agents should expect. Error handling is minimal, no recovery guidance, no error categorization, and no actionable error messages. The server implements file locking and atomic writes (good), but these safety measures are not reflected in tool documentation. Security-sensitive operations (delete_item, delete_element) lack confirmation patterns or permission checks.
Creates a new directory at the specified path.
Creates a new Markdown file with optional initial content.
Deletes a block from the document.
Deletes a file or directory.
Returns the target element along with its immediate neighbors (before and after).
Parses the Markdown file and returns a tree of headings and elements. Use this first to navigate.
Inserts a new block (heading, paragraph, etc.) relative to an existing one.
search_tools has generic, uninformative description ('Scalability feature: find the right tool for your complex task among all available tools'). This doesn't explain when to use it or what it returns. An LLM cannot determine if this is a meta-discovery tool, a search-within-tools tool, or something else.
Output schemas are completely undocumented. No tools define what fields or structure their responses contain. Agents cannot plan downstream calls, extract IDs for chaining, or understand what data to expect. For example, 'search_text' returns 'structural paths' but the format is unknown.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Lists files and directories in a specified path.
Moves an element from one location to another.
Fetches the full content of a specific block by its path.
Overwrites the content of a specific block. Maintains document structure.
Performs a semantic search for text strings and returns their structural paths.
Scalability feature: find the right tool for your complex task among all available tools.
Undoes the last N changes made to the document.
Updates YAML frontmatter metadata in the document.
Destructive operations (delete_element, delete_item) lack confirmation, dry-run, or permission checks. There is no pattern to prevent accidental data loss. An LLM can irrevocably delete a document section with a single misguided call.
Error handling is minimal. No tools document error cases, recovery steps, or how to interpret failure responses. Responses reference internal field names ('_pending_entry') that should be hidden. No guidance for retryable vs fatal errors.
Parameter descriptions are missing or trivial in several tools. E.g., 'depth' in get_document_structure has no description explaining that it limits heading nesting. 'path' in many tools is described only as 'Path to the element (e.g., ...)' without explaining format or constraints.
File path parameters accept both relative and absolute paths without clear documentation of expected behavior. LLMs may pass '.' or '/' expecting different results. No validation guidance is given.
Tool descriptions mention internal implementation details ('Maintains document structure', 'with cache invalidation support') rather than user-facing benefits. LLMs care about what the tool does for the user, not how it works internally.
delete_item has an ambiguous description ('Deletes a file or directory') and no differentiation in parameter handling. It does not clarify whether deleting a directory is recursive, whether confirmation is needed, or what happens to nested files.
No tool documents permission requirements or scope declarations. An agent cannot know if it is allowed to delete files, and a user cannot configure minimal permissions for the agent.
'where' parameter in insert_element and move_element uses enum values 'before' and 'after' with no description of what they mean relative to the reference element. Unclear whether 'after Introduction' inserts after the heading or after all content under that heading.