Loading ToolBench
The server defines 4 tools with clear names following verb_noun conventions (get*, create*, delete*). All tools have non-empty descriptions (range: 69-137 chars, within baseline of 34-392). Input schemas are explicitly declared using Zod with type constraints (enums, strings, numbers). However, there are significant gaps: (1) No output schemas documented, tool responses are unspecified, forcing LLMs to infer return structure. (2) Some parameter descriptions lack actionable detail, e.g., 'X coordinate' lacks guidance on valid ranges or auto-positioning behavior. (3) deleteElement uses a generic 'id' parameter that accepts both IDs and labels but lacks clarity on precedence. (4) No error handling or recovery guidance in tool descriptions. (5) Missing critical context about side effects and state mutations beyond basic description.
Create an arrow connecting two nodes. Nodes can be referenced by ID or by label text.
Create a new node (shape with label) in the diagram. Returns the created node ID.
Delete a node or edge from the diagram by ID or label.
Return a markdown representation of the complete diagram, including nodes, relationships, labels, frames, and colors.
No output schemas documented. Tools return responses but callers have no visibility into fields, types, or structure. LLMs cannot confidently extract return values for downstream tool composition.
deleteElement parameter 'id' is overloaded: accepts both element IDs and label text. No guidance on precedence, resolution strategy, or error behavior if both match. Increases ambiguity and LLM error likelihood.
Numeric parameters (x, y, width, height in createNode) lack range constraints or validation guidance. LLMs may pass negative, zero, or absurdly large values without clear feedback on valid bounds.
No error handling guidance in descriptions. Tools will fail in various ways (file not found, invalid node references, disk write errors) but descriptions give no hint of what to do on failure or how to recover.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
createEdge allows referencing nodes by ID or label text but provides no guidance on ID format, whether labels must be exact matches, or behavior if multiple nodes share a label.
Enum descriptions embed example values ('transparent', 'light-blue', etc.) in text rather than relying on the formal enum constraint. This mixes descriptive prose with schema, risking LLM confusion about whether examples are exhaustive.