Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_material_function_input_props

DestructiveIdempotent

Edit an existing material function input node by node ID, writing only the properties you specify, then recompile the function and mark it dirty without saving.

Instructions

Edit an existing FunctionInput node of a UMaterialFunction asset, found by node_id: only the fields you pass are written (name, type, description, preview value, default flag, sort priority), then the function is recompiled and marked dirty without saving. Read it back with get_material_function_inputs.

Returns: { function_path: string, node_id: string, input_name: string, input_type: string, applied: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
node_idYesThe input node id (UMaterialExpression name) from add_material_function_input
input_nameNoNew pin name, stored as given: it is not made unique (the engine ValidateName only acts on nodes owned by a material).
input_typeNoOptional EFunctionInputType (the 13 values; same parser as add_material_function_input)
descriptionNoNew tooltip text of 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.
sort_priorityNoInteger that orders this input pin relative to the other inputs of the function.
use_preview_value_as_defaultNoBool: true makes the preview value the default of the input when its pin is left unconnected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.2.0
    • changedInput schema / properties / description / description
      Previous value: -"Optional tooltip/description string"New value: +"New tooltip text of the input pin."
    • changedInput schema / properties / input_name / description
      Previous value: -"Optional new pin name (re-validated for uniqueness)"New value: +"New pin name, stored as given: it is not made unique (the engine ValidateName only acts on nodes owned by a material)."
    • 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"New value: +"JSON object {\"x\":0,\"y\":0,\"z\":0,\"w\":0} (FVector4f), any subset; missing components keep their current value."
    • changedInput schema / properties / preview_value / type
      Previous value: -"string"New value: +"object"
    • changedInput schema / properties / sort_priority / description
      Previous value: -"Optional int display-order"New value: +"Integer that orders this input pin relative to the other inputs of the function."
    • changedInput schema / properties / sort_priority / type
      Previous value: -"string"New value: +"number"
    • changedInput schema / properties / use_preview_value_as_default / description
      Previous value: -"Optional bool"New value: +"Bool: true makes the preview value the default of the input when its pin is left unconnected."
    • changedInput schema / properties / use_preview_value_as_default / type
      Previous value: -"string"New value: +"boolean"
  2. First observedv1.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructive/idempotent/non-readonly. The description adds genuinely new context beyond them: the function is recompiled and marked dirty but NOT saved, which tells the agent the change is unsaved and needs a separate save.

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?

Two tightly packed sentences/sections with zero filler; the scope and partial-write rule are front-loaded, and the return-value line is warranted because no output schema exists.

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 mutation tool with full schema coverage but no output schema, the description covers the missing pieces: partial-write behavior, recompile/dirty/unsaved side effects, readback alternative, and the return shape.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds the key semantic that unspecified fields are left untouched and enumerates the mutable fields (name, type, description, preview value, default flag, sort priority), clarifying patch versus replace behavior.

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+resource (edit an existing FunctionInput node of a UMaterialFunction) and how the node is identified (node_id), which cleanly distinguishes it from siblings like set_material_function_output_props.

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?

Explains the partial-update semantics ('only the fields you pass are written') and routes the agent to get_material_function_inputs for readback. It lacks explicit when-not/alternative guidance, but the mutation-vs-read split 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