Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_mesh_material_color

DestructiveIdempotent

Apply a runtime color tint to one material slot on a Blueprint component via a temporary dynamic material instance; changes won't persist after save or reload.

Instructions

Tint one material slot of a Blueprint component template by creating a DYNAMIC material instance (MID) over the current or given material, setting one vector parameter, and assigning the MID to the slot. A MID is a RUNTIME object, so this is a quick preview, NOT the way to author a change that must survive save/reload -- for a persistent tint make a MaterialInstanceConstant and assign it with apply_material_to_blueprint. A parameter_name the material does not declare is accepted silently and simply does nothing.

Returns: { component: string, material_slot: int, parameter_name: string, color: [number, number, number, number], success: bool } -- success:true only means the MID was created and assigned; re-read with get_blueprint_material_info after a save/reload to see whether anything persisted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorYesRGBA color [R, G, B, A] as floats, each clamped to 0.0-1.0; exactly 4 values are required
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
material_pathNoOptional material asset path to use as the MID's parent; without it the component's current slot material is used, falling back to /Engine/BasicShapes/BasicShapeMaterial
material_slotNoOptional slot index; defaults to 0
blueprint_nameNoName of the blueprint
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
component_nameYesName of an OWN SCS component; must be a UPrimitiveComponent
parameter_nameNoOptional vector parameter name; defaults to "BaseColor". A name the material does not declare is NOT reported as an error -- it just has no visible effect.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=true, idempotent=true): it discloses that MIDs are runtime-only and lost on reload, that an undeclared parameter_name fails silently, and that success:true only means the MID was created/assigned (verified via get_blueprint_material_info after reload). This is exactly the behavioral context an agent needs.

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 the core action, then the persistence caveat and the alternative, then a return-shape block. No filler; each sentence carries a distinct, decision-relevant fact.

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?

With no output schema, the description correctly supplies the return shape and, crucially, the caveat that success:true is not proof of persistence and should be re-checked. Combined with the PIE warnings in the schema, an agent has everything needed to call and interpret this tool.

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% and every parameter (color clamping, force/PIE refusal, material_path fallback, slot default, blueprint_path alias, silent parameter_name) is thoroughly documented in the schema itself. The description restates a subset of this but adds no syntax or semantics the schema does not already carry, so the baseline of 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?

The description names a specific verb (tint) applied to a specific resource (one material slot of a Blueprint component template) and immediately explains the mechanism (creating a DYNAMIC material instance over the current or given material). It explicitly distinguishes itself from the persistent-authoring sibling apply_material_to_blueprint, so an agent can route correctly without opening another schema.

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

Usage Guidelines5/5

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

Explicit when-to-use and when-NOT-to-use guidance: this is a preview, not for changes that must survive save/reload, and the alternative (MaterialInstanceConstant + apply_material_to_blueprint) is named for persistent tints. The force/PIE constraint adds a further usage condition.

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