Loading ToolBench
Collection of MCP servers for various utilities: DOCX template processing, Mermaid diagram rendering, PlantUML diagram rendering, RSS feed to Markdown conversion, and YouTube download tools
This multi-tool MCP server exhibits inconsistent definition quality across 8 tools. Most tools lack detailed parameter descriptions and comprehensive schemas. The server spans four separate tool domains (Mermaid, PlantUML, RSS, DOCX) with varying levels of polish. Only 1 of 8 tools has fully documented parameters with descriptions for every field. Error handling is minimal, most tools lack recovery guidance. The codebase shows logging setup and error handling patterns in the Mermaid module (seen in source), but this is not consistently applied across all tools. Naming is generally acceptable (verb_noun structure), but descriptions are often generic. No tool annotations (readOnlyHint, destructiveHint) are present.
Verify Docker is running for PlantUML server
Convert PlantUML output between formats (PNG/SVG/PDF)
Convert a Word document (docx) to PDF format
Fetches an RSS feed, filters articles by date, and returns matching articles formatted as a Markdown list.
Extract all replacement keys from a Word document template
Process a Word document template by replacing placeholders and managing blocks
Render PlantUML text to image/PDF
Most tools lack parameter descriptions. render_diagram, check_docker, and convert_format have minimal or no per-parameter documentation. LLMs cannot infer when to pass 'input' vs what format is expected.
Input schemas for render_diagram, check_docker, and convert_format are skeletal, only property names, no format constraints, no enums where applicable, no min/max bounds. For example, 'format' in convert_format should be an enum ('PNG'|'SVG'|'PDF'), not a free-form string.
No error handling guidance. Tools do not document recovery steps (e.g., 'If Docker is not running, install Docker Desktop and start it' for check_docker). Agents receive raw errors with no actionable next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Render Mermaid diagram code to PNG image, optionally updating existing diagrams
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). render_diagram, process_template, and convert_to_pdf are write/destructive operations but are not marked as such. Agents cannot infer side effects.
Output schemas are not documented for any tool. LLMs cannot know what fields to expect in responses. For example, render_mermaid_chart likely returns a document_id and file path, but this is not specified.
Tool descriptions are generic for several tools. 'Render PlantUML text to image/PDF' (render_diagram) does not clarify when to use this vs render_mermaid_chart, what input format is expected, or what output is produced. Descriptions should be 50 - 200 characters and answer: What? When? Prerequisites?
fetch_rss_to_markdown has two mutually exclusive filtering parameters (filter_since_date and filter_last_days) but does not explicitly document this. If both are provided, behavior is undefined. Parameters should state: 'Provide exactly one of filter_since_date or filter_last_days; if both are provided, filter_last_days takes precedence.'
process_template 'replacements' and 'blocks' parameters are untyped objects without internal field descriptions. The schema shows {"type":"object"} with no properties defined. LLMs have no way to know what keys are valid or what values should be.
Path traversal and injection risks not mitigated in tool descriptions. Tools accept file paths (output_path, template_file, docx_file, pdf_output) but do not document allowed directories or validation. LLMs could be tricked into writing to arbitrary locations.