Skip to main content
Glama
dokaNc

IlluGen MCP

by dokaNc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Add node

node_add

Add a node to an IlluGen graph, optionally setting parameters and position, then save the project file. Returns the new node's id, type, and any warnings.

Instructions

Adds a node to the graph with IlluGen's default values, optionally setting some parameters.

Writes the project file in place. Parameter values are checked: an unknown name or invalid enum value fails
with suggestions and nothing is saved; a value outside the UI range is kept and reported in warnings.
Connect the new node with link_add afterwards.
Returns: id (string id of the new node), type, and warnings if any.

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).
labelNoOptional display label. A unique label can then replace the id in the other tools.
paramsNoParameter values to set, {name: value}, names and kinds from describe_node_type. Vectors and colors as lists ([x, y], [r, g, b, a]), enums as strings. Omitted parameters keep IlluGen's defaults.
positionNo[x, y] position in the node editor. Default: to the right of the right-most node.
node_typeYesNode type from list_node_types, e.g. 'Node_Grayscale_Noise' (case, spaces and 'Node_' prefix optional).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.2
    • 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 / label / description
      Added value: +"Optional display label. A unique label can then replace the id in the other tools."
    • addedInput schema / properties / node_type / description
      Added value: +"Node type from list_node_types, e.g. 'Node_Grayscale_Noise' (case, spaces and 'Node_' prefix optional)."
    • addedInput schema / properties / params / description
      Added value: +"Parameter values to set, {name: value}, names and kinds from describe_node_type. Vectors and colors as lists ([x, y], [r, g, b, a]), enums as strings. Omitted parameters keep IlluGen's defaults."
    • addedInput schema / properties / path / description
      Added value: +"Absolute path of the .illugen project file."
    • addedInput schema / properties / position / description
      Added value: +"[x, y] position in the node editor. Default: to the right of the right-most node."
  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?

Annotations cover the safety profile (not read-only, not destructive, not idempotent), and the description goes well beyond them: it discloses the in-place file write, the exact validation failure mode ('an unknown name or invalid enum value fails with suggestions and nothing is saved'), and that out-of-range values are kept with warnings. This is unusually rich behavioral detail.

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 purpose, then mutation/validation behavior, then the sibling hand-off, then return values. Four tight sentences 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?

For a six-parameter mutation tool with no output schema, the description covers the write semantics, validation outcomes, follow-up step, and return shape (id, type, warnings). Nothing material 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 all six parameters including graph nesting syntax and param encoding. The description adds only the 'omitted parameters keep defaults' framing, which the schema also states, so baseline 3 is appropriate.

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 and resource ('Adds a node to the graph') plus the scope of default behavior and optional parameter setting. It also distinguishes itself from siblings by naming link_add as the follow-up step and implying node_set operates on existing nodes.

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: writes the project file in place, parameters are validated, and connection requires calling link_add afterwards. It does not state explicit when-not conditions or prerequisites such as needing a node_type from list_node_types (though the schema parameter description does).

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