Skip to main content
Glama

add_material_function_input

Add an input pin to a UMaterialFunction asset, set its type, description, sort order, and preview/default value, then recompile the function and mark it dirty without saving.

Instructions

Add a FunctionInput node (a new input pin) to a UMaterialFunction asset with the optional props applied, then recompile the function and mark it dirty without saving. Returns node_id, the handle for set_material_function_input_props and delete_material_function_input, plus num_inputs and added.

Returns: { function_path: string, input_name: string, input_type: string, node_id: string, num_inputs: number, added: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
input_nameYesName of the new input pin, stored as given: a name another input already uses is not made unique.
input_typeNoOne of the 13 EFunctionInputType values: Scalar|Vector2|Vector3|Vector4|Texture2D|TextureCube|Texture2DArray|VolumeTexture|StaticBool|MaterialAttributes|TextureExternal|Bool|Substrate (optional, default "Scalar")
descriptionNoOptional tooltip/description string for the input pin
function_pathYesFull path to the material function, e.g. '/Game/MyGame/MF_Example.MF_Example'
preview_valueNoJSON object {"x":0,"y":0,"z":0,"w":0} (FVector4f), any subset; missing components keep their current value. Used for previews, and as the default with use_preview_value_as_default.
sort_priorityNoOptional int controlling the input's display order relative to other inputs
use_preview_value_as_defaultNoOptional bool; if true, the preview value becomes the input's default

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.0
    • changedInput schema / properties / input_name / description
      Previous value: -"Name of the new input pin"New value: +"Name of the new input pin, stored as given: a name another input already uses is not made unique."
    • addedInput schema / properties / preview_value / additionalProperties
      Added value: +true
    • changedInput schema / properties / preview_value / description
      Previous value: -"Optional {x,y,z,w} (FVector4f) preview value used when previewing / as default"New value: +"JSON object {\"x\":0,\"y\":0,\"z\":0,\"w\":0} (FVector4f), any subset; missing components keep their current value. Used for previews, and as the default with use_preview_value_as_default."
    • changedInput schema / properties / preview_value / type
      Previous value: -"string"New value: +"object"
    • changedInput schema / properties / sort_priority / type
      Previous value: -"string"New value: +"number"
    • changedInput schema / properties / use_preview_value_as_default / type
      Previous value: -"string"New value: +"boolean"
  2. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare the generic non-readonly, non-destructive, non-idempotent profile. The description adds real behavioral context beyond that: the function is recompiled and marked dirty but NOT saved, and it names the returned handles. It does not describe failure modes or permission requirements, so not a 5.

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

Conciseness4/5

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

Front-loaded with the mutation and its side effects in the first sentence. The trailing 'Returns:' block slightly duplicates the return-value mention already in sentence one (node_id, num_inputs, added), a minor redundancy that keeps it from a 5.

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, and the description fully compensates by enumerating the return shape (function_path, input_name, input_type, node_id, num_inputs, added) plus the not-saved caveat. For a 7-param mutation with 100% schema coverage, nothing essential 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 documents all seven parameters, including input_type enum values and preview_value semantics. The description adds no parameter-level detail beyond referring to 'optional props', 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 and resource ('Add a FunctionInput node ... to a UMaterialFunction asset') and scopes the effect ('with the optional props applied'). An agent can distinguish this from siblings like add_material_function_output or add_material_function_call without opening a 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?

The description implies the workflow context (apply optional props, then recompile) and names the sibling tools that consume the returned node_id (set_material_function_input_props, delete_material_function_input), which guides follow-on usage. It stops short of stating explicit when-to-use/when-not conditions, so it is not a full 5.

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