io.datadef/mcp

When: Use after the final layout, where one arrow should stand for a bundle of identical flows (zone to zone). Draw one large labelled arrow SHAPE between two areas of the diagram — "ingest", "serve", "publish". It is a drawing, not a connection: it links nothing and moves with nothing. To connect nodes use canvas_connect_nodes; never replace existing edges with this. Position it in the gap between the two areas using canvas_measure_canvas. Batch: `arrows` (up to 12) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use to record which source columns produce which target columns. No line is drawn. Record column-level lineage: which source column produces which target column, and how. This is what makes the diagram queryable for impact analysis, so add it for every real transformation. canvas_remove_lineage undoes it. Batch: `links` (up to 100) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_validate_canvas before you finish.

When: Use to add components (tables, pipelines, sources, consumers, service icons), each placed in its zone with `group`. Add one or more nodes to the canvas. Batch every node you want in a single call. Positions are assigned by canvas_layout_canvas afterwards — never set them yourself. Batch: `nodes` (up to 40) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. If you have not already, call get_design_guide first: it carries Datadef's size, edge and zone standard, and diagrams built without it read poorly. Next: canvas_connect_nodes for the real flows, then canvas_layout_canvas once when the structure is complete.

When: Use after the final layout to mark nodes that belong together without moving them into a zone. Regions do not move with layout. Draw a labelled translucent area behind existing nodes to show they belong together, without reparenting them. Use this when the grouping is a reading aid rather than real containment, when areas would need to overlap, or when a node belongs to two ideas at once — canvas_group_nodes cannot express any of those because it moves nodes into the zone. Call canvas_measure_canvas first and size the region to enclose the nodes with roughly 24px of margin. Batch: `regions` (up to 12) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use rarely: a pointer or highlight the user asked for. Never as a backdrop; zones are the containers. Place a rectangle, circle, arrow, or line as a visual annotation — a divider, a highlight. Shapes are drawings: they connect nothing (use canvas_connect_nodes for arrows between nodes) and they are not zones (use canvas_group_nodes). Batch: `shapes` (up to 20) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use only when the user wants a node at a specific position, outside the automatic layout. Otherwise use canvas_add_nodes. Add a single data node at an exact position, without connecting it to anything. Use when the user wants something placed somewhere specific, or when you will wire it up yourself afterwards. For building out a connected diagram, canvas_add_nodes is better — it batches and lets layout position everything. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use for a note that tells the diagram's reader a decision, constraint or gotcha. Pass `anchor` (the node or zone it explains) and it is placed beside it, no coordinates needed. To edit a note's text use canvas_update_nodes. Add a text note: a caption, a callout, a note explaining a decision. Give `anchor` (the node or zone it explains) and the note is placed beside it, clear of other content, without coordinates. Use x/y only for a note that belongs to no particular element. Notes are annotations: they take no edges. To change an existing note's text use canvas_update_nodes. Batch: `texts` (up to 20) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use only when the user asked for alignment that layout does not give. Align nodes to a shared edge or centre line, or space them evenly. Cleaner and far more reliable than computing coordinates by hand. Batch: `nodes` (up to 40) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check.

When: use whenever you would otherwise make several canvas_* write calls in a row, above all with tools that take one item per call: create every zone (group_nodes), convert many nodes (replace_node), set several tables' columns (set_columns). Eighteen zone creations or thirty-five replacements become one call and one save. Each operation is {"tool": "<canvas tool, with or without the canvas_ prefix>", "args": {<that tool's arguments, without diagram_id>}}. Operations run in order on the same diagram, so a later one can use what an earlier one created by its exact label (create a zone in operation 1, add nodes with that zone as their group in operation 2). All or nothing: if one operation fails, nothing is saved and the result names the failing operation. Write tools only; read with canvas_view. Returns compact JSON: one line per operation, the ids created, changed or removed, and the new revision. Next: canvas_layout_canvas once if the structure changed (or end the batch with a layout_canvas operation), then canvas_view.

When: Use to merge several similar nodes into one while keeping their connections, usually after canvas_suggest_simplifications. Merge several nodes into one summary node, keeping every connection. Use when a set of near-identical objects adds length without adding meaning — eight staging models that all behave the same become "stg_* (8)". Do not use when the individual objects are what the reader came for. Batch: `nodes` (up to 40) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_layout_canvas once, then canvas_view.

When: Use to draw the flows that genuinely move data between two nodes. Never connect a zone: connect a node inside it. Draw edges (arrows) between nodes to show how data flows. Label an edge only when the reader could not guess what it does ("CDC", "hourly batch"); obvious flows and dimensional joins read better unlabelled. Edges always render with an arrowhead at the target; bidirectional adds one at the source. Batch: `edges` (up to 60) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_layout_canvas once, when the structure is complete.

When: Use when you want a flat list of every node, edge and zone. canvas_view shows the same ids as a zone tree with positions and defects, and is usually the better first read. Get an overview of the current canvas: zones as a nested tree in reading order, every node with its id, type, icon and family, all connections with labels, and every note in full. Call this first, before any edit, so you work from real node ids instead of guesses. Operates on one Datadef diagram, named by diagram_id. If you have not already, call get_design_guide first: it carries Datadef's size, edge and zone standard, and diagrams built without it read poorly. Next: canvas_inspect_nodes for a node's full fields, or the write tool you need.

When: Use to delete specific edges between two nodes. Remove edges, given as source and target, or as an edge id / "Source -> Target" string in `edge`. Batch: `edges` takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use to create a zone (a layer, domain, stage or boundary), nested with `parentGroup`, optionally moving existing nodes into it: the zone is drawn around them where they are, inside the zone they already share. Create a labelled zone (e.g. "Bronze Layer", "Ingestion") and optionally move nodes into it. The zone is drawn around the nodes where they already are, so nothing moves on screen; it nests inside their shared zone unless parentGroup says otherwise. Zones are what turn a tangle of boxes into a readable architecture — use them for layers, domains, or environments. Batch: One zone per call. Create all zones in a single canvas_batch call, outermost first, instead of one call per zone. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. If you have not already, call get_design_guide first: it carries Datadef's size, edge and zone standard, and diagrams built without it read poorly. Next: canvas_add_nodes with `group` set to the zone.

When: Use before changing a node's fields or columns, to see everything it carries: columns, metadata, owners, neighbours. Get full detail for specific nodes: all columns with types and keys, metadata, schedule, formula, owners. Use before modifying a node so you preserve fields you are not changing. Batch: `nodes` (up to 10) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Next: canvas_update_nodes, canvas_set_columns or canvas_replace_node.

When: Use once, after the structure (zones, nodes, edges) is complete, not after each change. With no arguments it only places what was added or changed; nothing else moves. Set mode "full", direction (LR/TB/RL), spacing (compact/normal/airy), fit (page-portrait/page-landscape/slide-16:9/square) or zone only when the user asked for a different layout. Position what you added or moved, or re-arrange the diagram. Default (no arguments): places new and moved nodes next to what they connect to, in the reading direction, and grows their zone if needed; nothing else moves. Call it once after structural edits. Re-arranging (mode "full", or any of direction / spacing / fit / zone) redraws the layout the way a generated diagram is drawn, so only do it when the user asks for a different layout: "make it vertical" → direction TB; "more breathing room" / "less cramped" → spacing airy; "fit a Word doc / paper / A4" → fit page-portrait; "for a slide" → fit slide-16:9; "tidy this zone" → zone. Notes and flow arrows follow what they annotate. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result, then notes and flow arrows, then canvas_validate_canvas.

When: Use only for a precise manual placement the user asked for: exact x/y/width/height per node. To check a layout, canvas_view is faster and already reports overlaps. Get exact geometry: every node's position and size in canvas units, the overall canvas bounds, and any nodes that overlap each other. Call this before moving, resizing, or placing anything precisely — positions are meaningless without it. Batch: `nodes` takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Next: canvas_move_nodes, canvas_resize_nodes or canvas_align_nodes.

When: Use only when the user asked for a specific placement. Moving a zone moves its children; never move the children as well. Set node positions precisely. Use absolute x/y to place something exactly, or dx/dy to nudge it. Coordinates are absolute canvas units (same space canvas_measure_canvas reports). Moving a group moves its children with it — do not also move those children in the same call. Call canvas_measure_canvas first. Batch: `moves` (up to 60) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check. Do not run canvas_layout_canvas afterwards: it would undo the placement.

When: Use to move existing nodes or zones into another zone (they are placed inside it and the zone grows to fit), or out of every zone with group null. A zone cannot move into its own sub-zone. Move existing nodes or zones into an existing zone, or out of every zone (group: null). They keep their place on screen when they already sit inside the zone; otherwise they are placed inside it and the zone grows to fit. A zone cannot move into its own sub-zone. Batch: `nodes` takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use to delete lineage rows between two nodes (one column pair, or all rows between them). Lineage pointing at deleted nodes or columns is cleaned automatically. Delete lineage rows between two nodes: one column pair, or every row between the two nodes when no column is given. Lineage pointing at deleted nodes or columns is cleaned automatically and never needs this. Batch: `links` (up to 100) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use to delete nodes and their edges. Removing a zone keeps its contents (they move up to the parent, same place on screen): that is how to ungroup. Pass keepChildren:false only to delete the zone with everything inside it. Delete nodes, notes or zones, with every edge and lineage row touching them. Removing a zone keeps its contents by default: they move up to the zone's parent and stay where they are on screen (this is how to ungroup a zone). Pass keepChildren:false only when the user wants the zone AND everything inside it deleted. Batch: `nodes` takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use when one component changes identity or type (Redshift becomes Snowflake, a card becomes a service icon). The node keeps its id, connections, lineage, zone, position and fields. Turn a node into a different component in place — Redshift becomes Snowflake, a batch job becomes streaming. It keeps its id, every connection and lineage row, its zone, position, owners, schedule, colours and columns; only what you pass changes (a new label with no icon picks the new product's icon). canvas_update_nodes does the same for many nodes at once. Batch: One node per call. To convert many nodes, use canvas_update_nodes with `type` (and `label`, `icon`) for each, in one call. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use only when the user asked for a specific size. Set the width and height of nodes. Mostly for shapes, text boxes, and group zones — data nodes size themselves from their content, and resizing one can clip what it displays. Batch: `resizes` (up to 40) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check.

When: Use before adding nodes that should show a vendor logo (Snowflake, Kafka, Power BI) and you are unsure of the icon id. Find icon ids in Datadef's library (2000+ cloud and data-tool logos) by product name, e.g. "Amazon Aurora PostgreSQL", "k8s", "Azure Event Hubs". Pass `queries` to look up many names in one call (best id per name); pass `query` for the top matches of one name. Scores: 90+ sure, 75+ good. A name with no match has no icon; leave the icon field out rather than guessing. Batch: Pass `queries` with every vendor at once (up to 40, best id per name) instead of one call per vendor. Next: canvas_add_nodes (or canvas_update_nodes) with icon set to a returned id; omit icon when nothing matched.

When: Use `mode: "merge"` to add or update (renameTo) a few columns, `mode: "remove"` to drop some, or the default replace for the full list. Columns that stay keep their ids and lineage. Change a table's columns. mode "merge" adds new columns and updates (or renames, with renameTo) the ones you name, leaving the rest alone — use it to add one column. mode "remove" deletes the named columns only. mode "replace" (default) makes the list exactly what you pass. Columns are matched by name, so a column that stays keeps its id, its lineage and the edges anchored to it; lineage and anchors of removed columns are cleaned up. Mark primary and foreign keys. Batch: One table per call. For several tables, send one set_columns operation per table in a single canvas_batch call. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_add_lineage for column-level mappings, if there are any.

When: Use when the diagram feels dense or the user asks to simplify. It changes nothing; it reports what could collapse. Report where this canvas could be collapsed — groups of similar nodes that could become one summary node — without changing anything. Use it to decide whether the diagram is denser than it needs to be. Density is not automatically a problem: keep the detail when the detail is the point. Operates on one Datadef diagram, named by diagram_id. Next: canvas_collapse_nodes to apply a suggestion the user wants.

When: Use to relabel, retype, restyle (dashed, colour), reverse, put arrowheads on both ends, or re-point an existing edge, instead of disconnecting and reconnecting it. Change existing connections in place: relabel, retype, restyle (solid/dashed/dotted, colour), reverse the direction, put arrowheads on both ends, or re-point one end to another node. Identify each edge by source and target, or by `edge` (an id or "Source -> Target"). Change only the edges the user asked about: a request and its response are two edges on purpose, never merge them into one two-headed edge to tidy the drawing. Batch: `updates` (up to 60) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use for any in-place change: rename a node or zone (it keeps its size and contents), edit a note's text, recolour (`color: "green"`, `fill`, `family`), change a zone's style, swap an icon, or change a data node's type; fields you do not pass stay as they are. Many nodes in one call. Change existing nodes, zones or notes in place: rename (a zone keeps its size and contents), edit a note's text, recolour ("color": "green" or "#16a34a"; "fill" for the background; "family" for a layer hue), change a zone's style, swap an icon, change a data node's type. Only the fields you pass change; id, position, size, edges and everything else are kept. Batch many nodes in one call. For columns use canvas_set_columns. Batch: `updates` (up to 60) takes a list; put every item in one call rather than one call per item. Operates on one Datadef diagram, named by diagram_id. Returns compact JSON: the ids it created, changed or removed, the diagram revision, a one-line summary and the next step. A viewer-role account is refused. Next: canvas_view to check the result.

When: Use before you finish: broken references and icons, nodes outside their zone, overlapping zones or nodes. Loops are reported as information only. Check your work: broken references, broken icons, nodes sticking out of their zone, overlapping zones or nodes, unconnected or unfed nodes. By default it reports only issues in what you changed in this session (scope "changed"); scope "all" checks the whole canvas. Fix errors; judge warnings; info needs no action. Operates on one Datadef diagram, named by diagram_id. Next: Fix errors. Warnings are observations; ignore the ones that do not apply.

When: use to see a diagram before you edit it and after each round of changes; this is how you check your work. It answers in milliseconds from the saved diagram, where export_diagram starts a browser for 6-10 s. Returns a text map: the zones as a tree, each with its place on a coarse grid (r1 = top row, c1 = left column) and its nodes (label, type, icon, #id), then the edges, then the checks a render would reveal: overlapping nodes, overlapping sibling zones, nodes sticking out of their zone, nodes not laid out yet, empty zones, and the validator's error and warning counts. Every #id works as a node reference in the canvas_* tools. It also says when an edit_diagram run or a generation is still in progress on the diagram, and gives a preview image link that renders only if opened. For a large diagram, pass zone to look at one zone. include_image also renders a PNG (slow: only when you need to see styling). Next: fix what the checks report with the targeted canvas_* tool, then canvas_view again.

When: use when you will build the diagram yourself with the canvas_* tools, because you want control over the result or already know the architecture from the conversation. Use create_diagram instead when Datadef's model should design the whole thing from a prompt. Creates an empty diagram and returns its diagram_id. No AI generation runs: you draw it. Call get_design_guide first: it is the standard Datadef's own generator follows, and building without it produces the diagrams this tool exists to avoid. Next: canvas_search_icons (all vendors in one call), then one canvas_batch with every zone (group_nodes) and node (add_nodes), canvas_connect_nodes, canvas_layout_canvas once, canvas_view.

When: use when Datadef's own model should design a whole new diagram from a description or a pasted schema. To build it yourself step by step, use create_blank_diagram; to change an existing diagram, canvas_view and the canvas_* tools, or edit_diagram. Generates a professional data architecture diagram from a description and saves it to the user's Datadef account. Use it for any data-shaped diagram: medallion and lakehouse architectures, ETL/ELT pipelines, streaming topologies, data mesh, star and snowflake schemas, ER diagrams, lineage maps, cloud architectures, and data platform designs. EXISTING SCHEMAS: if the conversation or the repository has the schema itself (SQL DDL, a MySQL or pg_dump export, migrations, schema.prisma), pass the file contents as the prompt, unedited. Datadef parses it instead of asking a model: every table, column, type, primary key and foreign key comes out exactly as written, in seconds. Warehouse DDL with no declared foreign keys (fact_sales.customer_key → dim_customer.customer_key) gets its links from key names, drawn dashed. Add a sentence only if you want something other than a picture of that schema; "turn these tables into a star schema" or "design the pipeline that loads them" goes to the model instead. Write a specific prompt. Name the actual technologies (Snowflake, dbt, Airflow, Kafka, Fivetran), the layers or zones you want, and the tables that matter, the diagram is only as detailed as the description. Zone names you give are treated as a specification, not a suggestion. SCOPE: if the user's request is open-ended ("diagram our platform", "show me something"), ask them how much detail they want before calling this, or say which scope you chose. Default to scope "overview". A dense 40-node diagram is impressive and usually not what someone wanted from a one-line request; they can always ask you to expand it. TIMING: this waits up to ~35 seconds; fast generations come back finished, with a preview image and a markdown line…

When: use for a large change you can describe in words better than you can make it tool by tool: "reorganise this into bronze, silver and gold", "rebuild the consumption side from this spec", "add owners and schedules everywhere". For a precise change (rename, add a node, rewire an edge), the canvas_* tools are faster and exact. Datadef's own editing agent carries out the instruction: add nodes, rewire connections, add columns, reorganise into layers, fill in owners and schedules. Be specific about what to change and where: "Add a Kafka topic between the API and the bronze table, labelled 'events'" works; "make it better" does not. Timing: an edit takes 30-120 s. This waits about 35 s; a finished edit comes back with its summary, the ids it changed and a PNG. A slower one answers "in progress" and keeps running on the server: do NOT call edit_diagram again. Sending the same instruction again joins the running edit (or returns the result of the one that finished less than a minute ago); a different instruction is refused until it finishes. canvas_view and get_diagram report when it has finished. Next: canvas_view to check the result.

When: use to give the user an image of a diagram, or a link to download, attach or embed one. Not to check your own edits: a render starts a browser (6-10 s), while canvas_view answers in milliseconds and reports overlaps. Renders a diagram to PNG or JPEG. Returns the image inline AND a short-lived signed download URL. Use the inline image to show the diagram; use the URL when the user wants to save it, attach it, or share a link: it serves the file directly and needs no API key. Next: nothing; show the image or the link to the user.

When: read once before your first canvas_* call, to build or to edit. Datadef's standard for a readable diagram (size, edge discipline, nested zones, notes) and the tool workflow: which canvas_* tool to use when, batching, laying out once, checking with canvas_view. It is the same standard Datadef's own generator follows, so a diagram you build by hand comes out indistinguishable from a generated one. Works without a subscription. Next: create_blank_diagram to build, or canvas_view to edit an existing diagram.

When: use to show the user a diagram (it attaches a rendered PNG and a markdown image line, 6-10 s), or to poll a diagram that create_diagram or edit_diagram is still working on. To check your own edits, canvas_view is faster and reports overlaps. Returns every node with its type and columns, every connection and the zones, plus whether a generation or edit_diagram run is still in progress. Next: canvas_view and the canvas_* tools to edit.

When: use to find the id of an existing diagram before viewing, editing or exporting it. Lists the diagrams in the user's Datadef account, most recently updated first. Next: canvas_view with the diagram_id to see it.

Re-sync a repo-linked diagram from the current state of its repository. If the tracked branch or tag has not moved since the last sync, nothing changes. If it has, the diagram is REGENERATED from the repository, which replaces manual canvas edits. Only the owner of the repository connection can use this.

For a diagram that was created from a connected git repository: which repo and branch or tag it tracks, when it last synced, the commit it reflects, and whether daily sync is on. Use repo_refresh to sync it now. Only the owner of the repository connection can use this.