Loading ToolBench
MCP server for rendering infographics using @antv/infographic DSL syntax to PNG images
Single tool server with good foundational structure but gaps in error handling and output schema clarity. Tool name is clear and action-oriented (render_infographic). Description is comprehensive (352 chars, well within 10-1024 baseline) and includes DSL syntax examples, template list, and context on usage. Input schema is fully defined with Zod types and descriptions for all parameters (syntax, width, height, background). However, output schema is not formally documented, responses vary by config (base64 image vs URL text), and this conditional behavior should be explicitly stated. Error handling returns structured error messages but lacks recovery guidance or categorization (retryable vs permanent). Parameters lack minimum/maximum bounds for numeric types (width, height could be absurdly large). No parameter enums or regex patterns despite syntax being domain-specific.
Render an infographic from DSL syntax and return as PNG image. DSL syntax format (space-separated key-value, NOT YAML colon format): ``` infographic <template-name> data title My Title desc My Description items - label Item 1 desc Description 1 value 100 icon mdi/icon-name - label Item 2 desc Description 2 theme palette #3b82f6 #8b5cf6 #f97316 ``` Available templates include: - list-row-horizontal-icon-arrow - sequence-zigzag-steps-underline-text - compare-binary-horizontal-simple-fold - chart-pie-plain-text - hierarchy-tree-curved-line-rounded-rect-node - And more (~200 templates available)
Output schema not formally documented. Responses are conditional (base64 image if URL mode disabled, text URL if enabled), but this behavior is not declared in the tool description or a structured output schema document. LLMs cannot predict which format will be returned or parse responses reliably.
Numeric parameters lack bounds. width and height accept any number but should specify min/max (e.g., 1-4000). Unbounded parameters invite LLM-generated absurd values that cause performance degradation or failures.
Error messages lack recovery guidance. When DSL parsing fails or rendering times out, the response returns a plain error text but does not suggest what to do next (e.g., 'Check DSL syntax format' or 'Reduce image dimensions'). Per pattern:recovery-guide, errors should tell the LLM what action to take.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | <=2025-11-25 | v2 |
No error categorization. The tool returns isError: true but does not classify whether the error is retryable (network timeout), user-fixable (invalid DSL), or permanent (unsupported template). LLMs cannot determine appropriate recovery strategy.
Syntax parameter documentation lacks constraint clarity. The DSL format is described in the tool description but the syntax parameter itself only says 'Infographic DSL syntax string' without stating that malformed DSL will fail, or what happens if required fields are missing. Per pattern:tool-description, parameter descriptions should be complete and actionable.