canvas_connect_nodesDraw edges between nodes to show how data flows. Always label the edge with what actually happens ("ingest", "dbt transform", "hourly sync") — unlabelled edges make a diagram useless.
Operates on one Datadef diagram, named by diagram_id.
| Name | Required | Description | Default |
|---|---|---|---|
| edges | Yes | ||
| diagram_id | Yes | Canvas id, from list_diagrams, create_diagram, or create_blank_diagram. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the write nature is known. The description adds the labeling rule and diagram scope, but does not disclose whether existing edges are appended, replaced, or validated, nor what happens if labels are missing. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, purposeful sentences plus a scope statement. It front-loads the action ('Draw edges'), gives a critical rule, and concludes with the diagram scope. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with nested edge objects and no output schema, the description explains the core operation and labeling requirement, which combined with the schema is sufficient for invocation. It omits details like edge limits (though schema has maxItems) and alternative tools, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers diagram_id well, but the edges property itself lacks a description (50% coverage). The description explains the purpose of edges and the importance of labels, yet it does not clarify optional fields like type or style beyond the schema. It partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Draw[s] edges between nodes to show how data flows,' naming the verb and resource. It emphasizes the required labeling of edges, which distinguishes it from sibling tools like canvas_update_edges or canvas_add_lineage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it operates on one Datadef diagram and insists edges be labeled with meaningful actions. However, it does not explicitly mention when to prefer this tool over alternatives such as canvas_add_lineage or canvas_update_edges, so it falls short of explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clear, distinct purpose: canvas_add_nodes vs canvas_add_standalone_node, canvas_add_region vs canvas_group_nodes, and canvas_describe_canvas vs canvas_inspect_nodes are all well-differentiated in their descriptions. The only slight overlap is between get_diagram and canvas_describe_canvas, but they operate at different levels (full diagram vs current canvas state).
All canvas tools follow the consistent canvas_verb_noun pattern (e.g., canvas_connect_nodes, canvas_remove_nodes, canvas_layout_canvas), while high-level tools follow verb_noun (create_diagram, export_diagram). The two groups are internally consistent and the prefix clearly separates them.
With 34 tools, the server exceeds the recommended range for a typical MCP server. While every tool has a distinct role, the sheer number of canvas manipulation tools (27) feels heavy for most diagram-editing tasks and could be consolidated without losing functionality.
The tool set covers diagram creation, reading, updating, and export, but there is no delete_diagram tool, breaking the full CRUD lifecycle. Canvas editing is comprehensive, but the missing deletion at the diagram level is a notable gap that agents cannot work around.