Loading ToolBench
MCP server for generating, validating, and rendering Mermaid diagrams with AI assistance. Supports natural language diagram creation, syntax validation with detailed error reporting, multiple output formats, and diagram storage.
Sailor MCP is a diagram tool with 9 well-intentioned tools covering Mermaid diagram creation, validation, and rendering. Most tools have descriptions and basic schemas, but several have incomplete parameter documentation, missing output schemas, and weak error handling guidance. Tool naming is verb-forward and clear, which is good. However, 5 of 9 tools lack comprehensive parameter type definitions for all inputs, and none document output schemas explicitly. The 'create_diagram' tool relies on AI enhancement (with nullable style object) but doesn't explain fallback behavior if enhancement fails. Error handling is minimal across all tools, no guidance on retries, rate limits, or recovery paths. Composition is reasonable (distinct operations) but the tool set lacks batch operations (e.g., bulk validate or multi-diagram render). Compared to the 194-char baseline for descriptions, most Sailor tools are in the 100 - 150-char range, which is adequate but could be more specific about when to use each tool vs. alternatives.
Create a Mermaid diagram from natural language description. This tool uses AI to generate appropriate Mermaid code based on your description. It automatically selects the best diagram type and creates well-structured diagrams.
Get diagram by ID.
Get supported diagram types with descriptions.
Get example Mermaid code for different diagram types to help with understanding syntax.
Get server performance and usage metrics including request counts, render statistics, and rate limiter status.
Get available diagram templates, optionally filtered by type.
Render a Mermaid diagram to an image. Supports multiple output formats and styling options. Returns base64-encoded image data.
Missing output schema documentation for all tools. Tools define inputs but not return types, forcing LLMs to guess what fields they'll receive. This violates baseline pattern:tool-description.
create_diagram has nullable 'style' object parameter with no description of what fields it accepts or defaults to. LLM cannot reason about this without documentation. Additionally, 'enhance' boolean defaults to true but tool description doesn't explain what enhancement does or what happens if it fails.
get_diagram_types and get_server_metrics have minimal descriptions (<50 chars) and empty input schemas. get_server_metrics especially lacks explanation of what metrics are returned or when to call it.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Request a diagram download. Returns a download URL that can be used once to retrieve the rendered diagram image.
Validate Mermaid diagram syntax with detailed error reporting. Returns comprehensive validation results including: Syntax errors with line numbers, Warnings for best practices, Diagram metadata (type, complexity, etc.), Suggestions for improvements
No error handling guidance in any tool description. render_diagram and request_download call external rendering services (Playwright) but don't explain what happens on timeout, rate limit, or rendering failure. No recovery guidance.
render_diagram accepts 7 optional style parameters (format, theme, style, width, height, background, scale) with sensible defaults. However, no validation constraints documented, what are valid theme values? What pixel range for width/height? LLM must infer or guess.
get_diagram requires 'diagram_id' but doesn't explain where diagram IDs come from. No hint that users must call create_diagram first or retrieve IDs from get_templates/list_diagrams. This breaks tool chaining guidance.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. request_download is marked WRITE but others lack explicit annotations. This violates current MCP spec practice for tool metadata.