Loading ToolBench
Model Context Protocol server for Markdy diagram validation, transpilation, and generation.
The Markdy MCP server provides 12 tools with consistent naming conventions (verb-first: validate_, explain_, repair_, suggest_, transpile_, render_, complete_, get_). All tools have descriptions (avg 120 chars, within baseline 34-392), and input schemas are visible with type definitions. However, critical gaps exist: (1) Output schemas are completely undocumented, no response structures are specified for any tool, preventing LLMs from planning downstream operations. (2) Parameter descriptions are minimal or missing semantic context (e.g., 'code' param in validate_markdy lacks format/constraints guidance; 'rulePreset' has enum but no explanation of what each preset enforces). (3) Error handling is absent, no recovery guidance, retryability classification, or invalid input feedback. (4) The repair_markdy tool is marked WRITE but has no confirmation/dry-run support. These gaps align with common patterns in community servers and place the server in the C-to-D range despite reasonable naming.
Provide code completion suggestions for partial MarkdyScript diagrams
Generate plain-English explanation of MarkdyScript diagram code with semantic interpretation
List available diagram templates and their descriptions
Compile MarkdyScript code and render to SVG vector graphics
Automatically fix common syntax errors and formatting issues in MarkdyScript code
Generate MarkdyScript diagram code suggestions based on natural language description or incomplete code
Convert Docker Compose YAML to MarkdyScript architecture diagram
Convert Draw.io diagram XML to MarkdyScript format
NO OUTPUT SCHEMAS DOCUMENTED for any tool. LLMs cannot plan downstream operations without knowing response structure. A validate_markdy call returns what fields? errors? suggestions? severity levels? This forces agents to guess structure and wastes tokens on trial-and-error parsing.
PARAMETER DESCRIPTIONS LACK SEMANTIC CONTEXT. The 'code' parameter in validate_markdy, explain_markdy, repair_markdy, etc. says 'MarkdyScript diagram source code' but does not specify: min/max length, line ending conventions, encoding assumptions, or what constitutes 'valid' code. Format constraints should be explicit, not implicit.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
Convert Kubernetes manifest files to MarkdyScript architecture diagram
Convert Mermaid diagram syntax to MarkdyScript format
Convert Terraform state or configuration to MarkdyScript infrastructure diagram
Validate MarkdyScript diagram code for syntax errors, semantic issues, and architecture rule violations
DESTRUCTIVE TOOL (repair_markdy) LACKS CONFIRMATION / DRY-RUN SUPPORT. This tool is marked WRITE risk but has no dry-run parameter or confirmation step. Agents may accidentally overwrite code. Consider adding an optional 'dry_run' boolean (default false) or requiring explicit 'confirm' parameter.
ZERO ERROR HANDLING GUIDANCE. Tools provide no recovery information. If validate_markdy finds errors, what should the LLM do? Call repair_markdy? suggest_markdy? Describe the error clearly? Response errors should classify as retryable, user-fixable, or fatal, and offer actionable next steps.
ENUM PARAMETER 'rulePreset' IN validate_markdy HAS NO EXPLANATION. The enum lists microservices, distributed-systems, kubernetes, event-driven, serverless, but does not explain what rule set each enforces (e.g., 'microservices: enforces max 10 services, async communication'). LLMs cannot choose intelligently without rule semantics.
DETAIL PARAMETER IN explain_markdy ('brief', 'standard', 'verbose') IS UNDER-SPECIFIED. No guidance on token/length tradeoffs, when to use each, or what output length to expect. Agents may pick 'verbose' expecting conciseness or vice versa.
TEMPLATE PARAMETER IN suggest_markdy HAS NO GUIDANCE ON VALID IDS. Description says '(e.g. microservices-db, ai-rag-pipeline)' but LLMs may hallucinate IDs like 'kubernetes-helm' or 'serverless-aws'. Should reference get_templates() to discover valid IDs, or provide a strict enum.
INCOMPLETE SCHEMA DEFINITIONS. Input schemas present with basic types, but missing constraints: no 'required' arrays, no minLength/maxLength for strings, no 'additionalProperties' to clarify object shape. Schema is JSON Schema but under-utilized.