mcp

by io.datadef

Overview Discussions Admin

Remove edges

canvas_disconnect_nodes

Destructive

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "diagram_id": "<diagram_id>",
      "edges": "<edges>"
    },
    "name": "canvas_disconnect_nodes"
  }
}

Input Schema

Name	Required	Description	Default
`edges`	Yes
`diagram_id`	Yes	Diagram id, from list_diagrams, create_diagram or create_blank_diagram.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 28, 2026

changedInput schema / properties / diagram_id / description

Previous value: -"Canvas id, from list_diagrams, create_diagram, or create_blank_diagram."New value: +"Diagram id, from list_diagrams, create_diagram or create_blank_diagram."

addedInput schema / properties / edges / items / properties / edge

Added value: +{
+  "description": "Edge id, or \"Source -> Target\".",
+  "type": "string"
+}

addedInput schema / properties / edges / items / properties / source / description
```
Added value: +"Source node id or label."
```
addedInput schema / properties / edges / items / properties / target / description
```
Added value: +"Target node id or label."
```
removedInput schema / properties / edges / items / required
```
Removed value: -[
-  "source",
-  "target"
-]
```

First observedAug 5, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With destructiveHint=true already flagged by annotations, the description still adds genuinely new context: a viewer-role account is refused (auth requirement), and the return payload is spelled out (created/changed/removed ids, diagram revision, one-line summary, next step) despite there being no output schema. Batch semantics are also disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Labeled blocks (When, Batch, Returns, Next) make it scannable and front-load the purpose. Slightly list-like for such a short tool, but every sentence carries operative information and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema, the description covers everything an agent needs: scope, identifier formats, batching, authorization failure mode, and the shape of the return. Nothing material is left to guesswork.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, so the description must compensate, and it does: it explains that an edge can be given as source+target or as an edge id / "Source -> Target" string in `edge`, and that `edges` accepts a list. The diagram_id scoping is stated ('Operates on one Datadef diagram, named by diagram_id') but its provenance is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('delete specific edges between two nodes') and narrows scope with 'specific edges', which separates it from the broader canvas_remove_nodes. It does not explicitly name the near-siblings canvas_update_edges or canvas_remove_lineage, so the agent must infer the distinction from the tool name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'When: Use to delete specific edges between two nodes' gives an explicit trigger, and the Batch section states the calling convention directly ('put every item in one call rather than one call per item'). A 'Next: canvas_view' pointer closes the loop, though no when-not or alternative-tool guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All mcp tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?