Skip to main content
Glama
Sign In
obsidian-mcp-pro

obsidian-mcp-pro

by rps321321
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Add Canvas Edge

add_canvas_edge

Create a directed edge between two existing canvas nodes, optionally set a label or anchor sides, and get the generated edge UUID.

Instructions

Create a directed edge connecting two existing canvas nodes. Both fromNode and toNode must already exist on the canvas (use read_canvas to list node ids, or capture the id returned by add_canvas_node). Optional fromSide/toSide control which face of each node the edge anchors to. Returns the generated edge UUID.

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": {
      "canvasPath": "<canvasPath>",
      "fromNode": "<fromNode>",
      "toNode": "<toNode>"
    },
    "name": "add_canvas_edge"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional text label rendered on the edge
toNodeYesUUID of the target (destination) node - must already exist on the canvas
toSideNoFace of the target node the edge arrives at (default: auto-chosen by Obsidian)
fromNodeYesUUID of the source (origin) node - must already exist on the canvas
fromSideNoFace of the source node the edge leaves from (default: auto-chosen by Obsidian)
canvasPathYesRelative path from vault root to the target .canvas file

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv2.0.0
  3. Removedv1.9.0
  4. Addedv0.1.6
  5. Removedv0.1.4
  6. Changed8 schema fields changedv0.1.2
    • changedInput schema / properties / canvasPath / description
      Previous value: -"Relative path to the .canvas file"New value: +"Relative path from vault root to the target .canvas file"
    • changedInput schema / properties / fromNode / description
      Previous value: -"Source node ID"New value: +"UUID of the source (origin) node — must already exist on the canvas"
    • addedInput schema / properties / fromNode / minLength
      Added value: +1
    • changedInput schema / properties / fromSide / description
      Previous value: -"Side of source node"New value: +"Face of the source node the edge leaves from (default: auto-chosen by Obsidian)"
    • changedInput schema / properties / label / description
      Previous value: -"Edge label"New value: +"Optional text label rendered on the edge"
    • changedInput schema / properties / toNode / description
      Previous value: -"Target node ID"New value: +"UUID of the target (destination) node — must already exist on the canvas"
    • addedInput schema / properties / toNode / minLength
      Added value: +1
    • changedInput schema / properties / toSide / description
      Previous value: -"Side of target node"New value: +"Face of the target node the edge arrives at (default: auto-chosen by Obsidian)"
  7. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish that this is a non-read-only, non-destructive, non-idempotent mutation. The description adds useful behavioral context by specifying that both nodes must already exist and that the tool returns the generated edge UUID.

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

Conciseness5/5

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

The description is three tight sentences, front-loading the core action and prerequisites before optional details and return value. There is no wasted language.

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?

With no output schema, the description compensates by stating that the generated edge UUID is returned. Combined with the prerequisites and 100% schema coverage, an agent has enough information to invoke the tool correctly.

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

Parameters3/5

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

The schema has 100% description coverage, so the schema already explains all six parameters. The description adds prerequisite meaning for fromNode/toNode and clarifies fromSide/toSide, but does not add much for label or canvasPath beyond what the schema provides.

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

Purpose5/5

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

The description states a specific action and resource: creating a directed edge between two existing canvas nodes. It clearly distinguishes this from sibling tools like add_canvas_node and read_canvas by focusing on edge creation and node prerequisites.

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?

It gives clear contextual guidance: both node IDs must already exist, and it names read_canvas and add_canvas_node as ways to obtain them. It does not explicitly describe when not to use the tool, but the usage context is sufficiently clear.

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

Deploy Server

Other Tools