Skip to main content
Glama
dokaNc

IlluGen MCP

by dokaNc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Unlink pin

link_remove
Destructive

Disconnect a node's input pin by removing incoming links in an IlluGen project, then save the file and resolve any parameter that loses its driving link.

Instructions

Disconnects an input pin: removes the link(s) arriving at to_pin of to_node.

Writes the project file in place. If the pin drove a parameter, the parameter gets a fixed value again (its
default if it had none). Removing nothing is not an error. node_get lists a node's incoming links.
Returns: removed, the number of links deleted (0 if the pin was not connected).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path of the .illugen project file.
graphNoGraph to work in: empty for the top-level graph, or the id or label of a Node_Subgraph node ('outer/inner' for nested subgraphs).
to_pinYesInput pin name to disconnect.
to_nodeYesNode id or unique label whose input is disconnected.
from_nodeNoOptional: only remove links coming from this node (id or unique label). Empty = from any node.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.2
    • addedInput schema / properties / from_node / description
      Added value: +"Optional: only remove links coming from this node (id or unique label). Empty = from any node."
    • addedInput schema / properties / graph / description
      Added value: +"Graph to work in: empty for the top-level graph, or the id or label of a Node_Subgraph node ('outer/inner' for nested subgraphs)."
    • addedInput schema / properties / path / description
      Added value: +"Absolute path of the .illugen project file."
    • addedInput schema / properties / to_node / description
      Added value: +"Node id or unique label whose input is disconnected."
    • addedInput schema / properties / to_pin / description
      Added value: +"Input pin name to disconnect."
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With annotations already marking the operation destructive and non-idempotent, the description goes further: it writes the project file in place, restores a driven parameter to a fixed/default value, treats a no-op as non-error, and discloses the return value (count of removed links). This is the side-effect information an agent genuinely needs.

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?

Front-loaded with the core action, then side effects, then error semantics, then return value. Every sentence carries distinct information with no filler.

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?

No output schema exists, but the description supplies the return value explicitly, along with mutation side effects and no-op behavior. Nothing needed to invoke it correctly is missing.

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?

Schema description coverage is 100%, so the schema already documents path, graph, to_pin, to_node and from_node. The description reinforces the to_pin/to_node relationship but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb (disconnects/removes) and resource (incoming link(s) on a named pin of a named node), and contrasts naturally with sibling link_add. An agent can tell exactly what this does without opening the schema.

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?

Gives clear context: it is the unlink counterpart to link_add, points to node_get for discovering a node's incoming links, and notes that removing nothing is not an error. It does not spell out explicit when-not-use conditions, but the operative context is 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