Skip to main content
Glama

set_gameplay_effect_modifier_custom_curve

DestructiveIdempotent

Assign a CurveTable lookup row to a GameplayEffect modifier's CustomCalculationClass magnitude, remapping custom calc output through the curve.

Instructions

Set the FinalLookupCurve (a CurveTable row) on a GE modifier whose magnitude is already CustomCalculationClass; the custom calc output is remapped through the curve

Returns: { ge_blueprint_path: string, modifier_index: int, modifier_count: int, magnitude_type: string, calculation_class: string, curve_table_path: string, curve_table_readback: string, curve_table_matches: bool, row_name: string, row_name_readback: string, row_name_matches: bool, row_exists: bool, set: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
row_nameYesName of the row within the CurveTable to use as the final lookup curve
blueprint_nameNoAlias of `ge_blueprint_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `ge_blueprint_path`.
modifier_indexYesIndex into the GE CDO Modifiers array; the modifier's magnitude must already be CustomCalculationClass (call set_gameplay_effect_modifier_custom first)
curve_table_pathYesFull asset path of the UCurveTable holding the lookup row
ge_blueprint_pathNoFull asset path of the GE Blueprint

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 declare destructive=true, idempotent=true and readOnly=false, so the safety profile is covered. The description adds real behavioral value beyond that: it explains the runtime semantics ('the custom calc output is remapped through the curve') and enumerates the return payload including verification flags (curve_table_matches, row_name_matches, row_exists, set), giving the agent a way to confirm the write landed.

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?

The operative sentence is dense but front-loaded and free of filler. The trailing 'Returns:' block is verbose, but since no output schema exists it is the only place the agent learns the result shape, so it earns its space.

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?

For a 5-parameter mutation with no output schema, the definition supplies the precondition, the remapping semantics, and the full return shape. What is missing is failure behavior when the row or CurveTable does not resolve, though the row_exists/curve_table_matches flags partially mitigate that.

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 baseline is 3. The description's only real parameter information – the CustomCalculationClass precondition on modifier_index – is already repeated in that parameter's schema text, so the description adds little beyond the structured fields.

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 pairs a specific verb ('Set') with a named resource ('FinalLookupCurve (a CurveTable row)') and pins down the exact condition under which it applies ('a GE modifier whose magnitude is already CustomCalculationClass'), which is what separates it from siblings like set_gameplay_effect_modifier_attribute_curve. An agent can tell why this tool exists without opening the 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 states an explicit precondition – the modifier must already be CustomCalculationClass – and the schema decription names the enabling call ('call set_gameplay_effect_modifier_custom first'). That is strong context, but the description does not contrast this tool against the other curve-related sibling (set_gameplay_effect_modifier_attribute_curve), so the alternative-selection guidance is implied rather than explicit.

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