See through your agent's eyes. Visualize legacy code, architect new systems, understand everything.
The Mindpilot MCP server has two tools with moderate definition quality. render_mermaid has a detailed description and complex input schema, but the schema itself contains numerous formatting instructions embedded in the description rather than enforced via schema constraints. open_ui is severely underdescribed with an empty properties object and no actionable guidance. Neither tool has documented output schemas. The server lacks error handling guidance, security patterns for input validation, and composition considerations. Overall, definitions are below the baseline for production tools.
Open the Mindpilot UI application
Render a Mermaid diagram to SVG format. CRITICAL RULES: 1) Node IDs must be alphanumeric without spaces (use A1, nodeA, start_node). 2) For node labels with special characters, wrap in quotes: A["Label with spaces"] or A["Process (step 1)"]. 3) For quotes in labels use ", for < use <, for > use >. 4) For square brackets in labels use A["Array[0]"]. 5) Always close all brackets and quotes. 6) Use consistent arrow styles (either --> or ->). Example: graph TD\n A["Complex Label"] --> B{Decision?}\n B -->|Yes| C["Result "OK""]\n\nIMPORTANT: If the diagram fails validation, the error message will explain what needs to be fixed. Please read the error carefully and retry with a corrected diagram.
open_ui tool has empty input schema (no properties) and minimal description ('Open the Mindpilot UI application'). LLMs cannot determine when to call this tool or what parameters it accepts. Violates pattern:tool-description requiring non-empty descriptions and clear intent. Description is 34 characters, below the 50-character minimum actionable threshold.
render_mermaid description embeds formatting rules (critical RULES, node ID constraints, character escaping) as free-text narrative rather than enforcing via JSON Schema pattern/format constraints or enum fields. This shifts validation responsibility to the LLM, which cannot reliably parse and apply these rules. Should use schema constraints instead of description text for validation rules.
No output schema documented for either tool. render_mermaid presumably returns SVG content, but the response structure is not specified. open_ui returns nothing. LLMs cannot plan downstream usage without knowing return types. Violates pattern:tool requiring documented output schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 14 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 26 | - | v1 |
render_mermaid accepts a 'diagram' parameter (required string) but lacks validation guidance in the input schema. The description says 'MUST start with diagram type' and 'avoid forward slashes', but these are not enforceable constraints in the schema itself. No regex pattern, enum, or minLength constraint visible in the schema.
No error handling guidance provided. If a Mermaid diagram fails validation, the description says 'error message will explain what needs to be fixed', but no recovery pattern is documented. Error responses should guide the LLM on next steps (retry with correction, try alternative diagram type, etc.). Violates pattern:recovery-guide.
Parameter 'diagram' in render_mermaid is marked required but has no minLength or maxLength constraints visible. A freeform string parameter can receive arbitrarily large, malformed, or injection-attack payloads. Should validate length and structure to prevent denial-of-service or injection attacks.
render_mermaid description includes example color definitions in brackets '[color definitions]' but the actual color options are not shown. This appears to be placeholder text that was never filled in, leaving the LLM without concrete guidance on valid color values.