Skip to main content
Glama

set_gameplay_effect_modifier_attribute_based

DestructiveIdempotent

Switch an existing Gameplay Effect modifier's magnitude to AttributeBased so it scales from a captured Source or Target attribute.

Instructions

Switch an existing GE modifier's magnitude to AttributeBased (scales off a captured attribute)

Returns: { ge_blueprint_path: string, modifier_index: int, modifier_count: int, magnitude_type: string, backing_attribute: string, capture_attribute_readback: string, backing_attribute_matches: bool, attribute_source: string, coefficient: number, pre_multiply_add: number, post_multiply_add: number, calculation_type: string, snapshot: bool, set: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
snapshotNoIf true capture the attribute at spec creation, else track changes. Default true
coefficientNoMultiplier applied to the captured value. Default 1.0
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 (0 = first)
attribute_sourceNoCapture source: Source (caster) or Target (recipient). Default Source
calculation_typeNoAttributeMagnitude | AttributeBaseValue | AttributeBonusMagnitude. Default AttributeMagnitude
pre_multiply_addNoAdditive value applied before the coefficient. Default 0.0
backing_attributeYesAttribute to capture, e.g. Health or MySet.Health (must exist on some AttributeSet)
ge_blueprint_pathNoFull asset path of the GE Blueprint
post_multiply_addNoAdditive value applied after the coefficient. Default 0.0

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the mutation profile (readOnly=false, destructive=true, idempotent=true), so the description need not restate safety. It adds real value by documenting the rich return payload (including backing_attribute_matches and capture_attribute_readback, which signal a post-set verification readback), useful context absent from any output 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?

Purpose is front-loaded in a single clean sentence. The trailing Returns block is long but each field is informative given there is no output schema; it is slightly bulky inline but not redundant.

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 10-param mutation tool with no output schema, the description covers purpose and the full return contract. The notable gap is that it never states the destructive consequence — that switching magnitude type likely discards the modifier's prior magnitude configuration — despite destructiveHint=true.

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 every parameter is already documented in the schema with defaults, aliases, and enum-like values. The description adds no additional parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Switch an existing GE modifier's magnitude to AttributeBased' — with the parenthetical clarifying the scaling mechanism. The AttributeBased magnitude mode implicitly distinguishes it from siblings like set_gameplay_effect_modifier_attribute_curve or set_by_caller, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

The description implies usage (switch an existing modifier's magnitude type) but gives no when-to-use/when-not guidance and does not point to alternative magnitude-setting tools such as set_gameplay_effect_modifier_custom or set_gameplay_effect_modifier_attribute_curve. An agent must infer which sibling to pick from the name alone.

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