When AI agents create diagrams through the MCP, arrows and lines are almost always unbound/floating. Moving a shape leaves its arrows behind.
This is because creating bound arrows requires knowledge of a complex bidirectional binding protocol that isn't documented in the MCP's read_me output or element format reference.
What's required for a bound arrow today:
- The arrow needs startBinding and endBinding objects with elementId, focus, gap, and fixedPoint
- Each connected shape needs the arrow added to its boundElements array as {"id": "arrow-id", "type": "arrow"}
- Both sides must be consistent or the binding silently fails
This is error-prone even for human developers. For AI agents generating element JSON, it's the single most common diagram quality issue - every agent-generated Excalidraw diagram I've seen has floating arrows.
Suggested improvement options:
- Option A - Auto-bind: If an arrow's start/end point is within or on the edge of a shape, automatically create the binding. This is how the Excalidraw editor UI works when a human draws an arrow to a shape.
- Option B - Shorthand properties: Accept startElementId and endElementId on arrow elements in create_view, and have the server resolve the bindings (calculate fixedPoint from geometry, add the arrow to each shape's boundElements).
- Option C - Document it: At minimum, add the binding format to the read_me output with an example. Currently read_me describes arrow elements but doesn't mention startBinding/endBinding or the requirement for shapes to list bound
arrows.
Option A would be the biggest improvement since it would make every existing agent's diagrams better without any prompt or code changes.
Reproduction: Create any diagram with create_view where arrows connect shapes. The arrows will not follow the shapes when dragged in the Excalidraw editor, because no binding metadata is present.
When AI agents create diagrams through the MCP, arrows and lines are almost always unbound/floating. Moving a shape leaves its arrows behind.
This is because creating bound arrows requires knowledge of a complex bidirectional binding protocol that isn't documented in the MCP's read_me output or element format reference.
What's required for a bound arrow today:
This is error-prone even for human developers. For AI agents generating element JSON, it's the single most common diagram quality issue - every agent-generated Excalidraw diagram I've seen has floating arrows.
Suggested improvement options:
arrows.
Option A would be the biggest improvement since it would make every existing agent's diagrams better without any prompt or code changes.
Reproduction: Create any diagram with create_view where arrows connect shapes. The arrows will not follow the shapes when dragged in the Excalidraw editor, because no binding metadata is present.