Skip to main content
Glama
dokaNc

IlluGen MCP

by dokaNc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Set node

node_set
Idempotent

Update an existing IlluGen node's parameter values, label, position, or disabled flag; only supplied fields change, and the project file is saved in place.

Instructions

Changes an existing node's parameter values, label, position or disabled flag.

Only what you pass changes. Writes the project file in place; values are checked like in node_add. For
curves, gradients and spline points use curve_set, gradient_set and spline_set.
Returns: changed {name: new value} and warnings (value outside the UI range, or parameter currently driven
by a link, in which case the value only applies once unlinked).

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).
labelNoNew display label; omit to keep it.
paramsNoParameter values to change, {name: value}, same format as node_add. Other parameters are left as is.
node_idYesNode id as a string (from project_summary or node_add), or the node's label if it is unique.
disabledNotrue bypasses the node in IlluGen (a disabled export node is skipped by project_render); false re-enables it; omit to keep it.
positionNoNew [x, y] position; omit to keep it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.2
    • addedInput schema / properties / disabled / description
      Added value: +"true bypasses the node in IlluGen (a disabled export node is skipped by project_render); false re-enables it; omit to keep it."
    • 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: +"New display label; omit to keep it."
    • addedInput schema / properties / node_id / description
      Added value: +"Node id as a string (from project_summary or node_add), or the node's label if it is unique."
    • addedInput schema / properties / params / description
      Added value: +"Parameter values to change, {name: value}, same format as node_add. Other parameters are left as is."
    • addedInput schema / properties / path / description
      Added value: +"Absolute path of the .illugen project file."
    • addedInput schema / properties / position / description
      Added value: +"New [x, y] position; omit to keep it."
  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 declaring non-read-only, idempotent, non-destructive, the description still adds substantial context: it writes the project file in place, validation mirrors node_add, and it documents the return payload plus two warning conditions (out-of-UI-range values, values currently driven by a link that only take effect once unlinked). This goes well beyond the annotation hints and is consistent with idempotentHint=true.

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?

Three short sentences, front-loaded with the purpose, then the partial-update rule, then sibling routing and return/warning behavior. The Returns paragraph is justified because there is no output schema, and no sentence 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 7-parameter mutation tool with no output schema, the definition covers the missing pieces: in-place file write, partial-update semantics, validation behavior, sibling alternatives, and the return/warning shape. An agent has everything needed to invoke it 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?

Schema description coverage is 100%, so every parameter is already documented, including 'omit to keep it' semantics for label/disabled/position. The description adds only the general 'only what you pass changes' framing and the node_add-compatible params format, 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 (changes) and resource (an existing node) and enumerates the mutable fields: parameter values, label, position, disabled flag. It then explicitly routes editing of curves, gradients and spline points to curve_set, gradient_set and spline_set, so an agent can separate it from those siblings without opening their schemas.

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 ('Only what you pass changes') and names the three alternative tools for other resource kinds. It lacks explicit prerequisite/exclusion guidance (e.g. when to prefer node_set_data or subgraph_expose_param over this tool), so it is strong but not complete.

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