set_material_function_output

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Modify' but fails to mention side effects (e.g., auto-compilation, persistence, error handling) or prerequisites beyond the parameters. The return value is not described despite an output schema existing.

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

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

The description is extremely concise, consisting of a one-line summary followed by a structured parameter list. Every sentence adds value with no redundancy or fluff. It is front-loaded with the core purpose.

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

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

Given the tool has 5 parameters, no annotations, and an output schema, the description explains each parameter well but lacks context about return values, error conditions, or behavioral implications (e.g., does it require the function to be saved first?). It is adequate but incomplete for a mutation tool.

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

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

Schema coverage is 0%, so the description must compensate. It does so excellently by providing clear, meaningful comments for each parameter (e.g., 'Full path to existing material function', 'New pin name'), adding significant value over the bare schema types.

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

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

The description clearly states 'Modify an existing FunctionOutput node's properties', using a specific verb and resource. It effectively distinguishes itself from sibling tools like add_material_function_output (which creates) and set_material_function_input (which modifies inputs).

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

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

The description provides parameter context (e.g., node_index from get_material_function_info) but does not explicitly state when to use this tool versus alternatives or exclude cases. No 'when-not-to-use' or alternative tool names are mentioned, leaving the agent to infer usage from context.

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