Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_collection_scalar_param

Destructive

Add a new scalar parameter to a Material Parameter Collection asset and save it, or overwrite the default on an existing scalar of that name.

Instructions

Add a scalar parameter (new GUID) to a Material Parameter Collection asset and save it; an existing scalar of that name only gets its default overwritten (already_existed=true). Returns scalar_count_before, scalar_count, default_value and id. For a color use add_collection_vector_param.

Returns: { collection_path: string, param_name: string, param_type: string, param_added: bool, already_existed: bool, scalar_count_before: int, scalar_count: int, default_value: number, id: string, saved: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
param_nameYesName of the new scalar parameter
default_valueNoDefault float value; default 0. An existing scalar of that name gets this value too, even when it is omitted
collection_pathYesFull /Game path to the MPC asset

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedInput schema / properties / default_value / description
      Previous value: -"Optional float default, default 0"New value: +"Default float value; default 0. An existing scalar of that name gets this value too, even when it is omitted"
  2. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds real context on top: it saves the asset, and an existing scalar of that name is not duplicated but has its default overwritten with already_existed=true. It does not mention undo/permissions or that the overwrite occurs even when default_value is omitted (that detail lives only in the schema).

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 core action and the sibling alternative in the first two sentences. However, the prose already enumerates the return keys and then a separate Returns block repeats and expands them, which is mild redundancy.

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

Completeness4/5

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

No output schema exists, so spelling out the return payload is legitimately useful, and the overwrite semantics plus the vector alternative round out the mutation contract. Remaining gaps (undoability, whether the package must be saved/compiled, MPC-exists prerequisite) are minor for this tool class.

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 already documents all three parameters, including the 'existing scalar gets this value even when omitted' nuance. The description adds only the framing that the parameter is a scalar with a newly generated GUID, which is marginal.

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 scalar parameter to a Material Parameter Collection) plus the save side effect, and explicitly contrasts with the vector sibling. An agent can distinguish it from add_collection_vector_param without opening either 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?

It names the alternative for the color case ('For a color use add_collection_vector_param'), which is a clear routing rule. It stops short of stating when to prefer set_collection_param_default or remove_collection_param, or any prerequisite that the MPC asset must already exist.

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