Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_section_easing

DestructiveIdempotent

Set ease-in and ease-out durations in frames on a Level Sequence section, using manual or auto values, to control transition timing.

Instructions

Set ease-in/ease-out durations (in frames) on a sequencer section.

Returns: { sequence_path: string, section_index: int, ease_in_frames: int, ease_out_frames: int, manual_ease_in: bool, manual_ease_out: bool, set: bool, saved: bool, save_error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
track_typeNoOptional class filter ("transform"|"float"|"bool"|"vector"|"color"|"visibility"|"audio"|"event"|"fade"|"skeletalanimation"|"subsequence"|"cameracut"|"property").
use_manualNobool, use Manual* ease durations instead of Auto* (default true).
track_indexNoIndex into the binding's tracks (0 = first track, default 0; used when track_type is omitted).
binding_guidNoGUID of the binding whose section to edit.
section_indexNoIndex of the section on the resolved track (default 0).
sequence_nameNoAlias for sequence_path.
sequence_pathNoFull /Game path OR bare asset name of the target Level Sequence.
ease_in_framesNoEase-in duration in frames (omit to leave unchanged).
ease_out_framesNoEase-out duration in frames (omit to leave unchanged).
binding_name_or_guidNoAlias for binding_guid, read only when binding_guid is absent; it must also be a GUID string, a bound object's name is not resolved.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / binding_name_or_guid / description
      Previous value: -"Sequencer binding: the bound object's name or its GUID string"New value: +"Alias for binding_guid, read only when binding_guid is absent; it must also be a GUID string, a bound object's name is not resolved."
    • removedInput schema / required
      Removed value: -[
-  "sequence_path",
-  "binding_guid"
-]
  2. First observedv1.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation/isolation profile is covered. The description adds value by exposing a 'saved' and 'save_error?' in the return, signaling the tool writes/saves the asset and can fail — context not in the annotations. However, it does not address the manual-vs-auto tradeoff or what is destroyed, so it is only partially additive.

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?

The action sentence is front-loaded and the return shape is presented compactly, which is efficient given there is no output schema. Every element earns its place, with no filler.

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

Completeness3/5

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

For a mutation tool with no output schema, including the return shape substitutes well for the missing output schema. But it omits usage context — manual vs auto behavior, required binding/track resolution, and save/prerequisite conditions — leaving an agent with gaps in a 10-parameter 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%, so the schema already explains both the track/binding resolution params and the omit-to-leave-unchanged semantics of ease_in_frames/ease_out_frames. The description adds no parameter meaning beyond the schema. Baseline 3 is appropriate when the schema carries this load.

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 (Set) and resource (ease-in/ease-out durations in frames) with the scope ('on a sequencer section'), which distinguishes it from siblings like set_section_range or set_section_blend_type. The unit ('in frames') is clarified. It does not explicitly name a sibling it is not, so it falls just short of 5.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no alternatives are given. Nothing tells the agent when this is preferable to related section setters or what state the sequence must be in. There is no exclusion or selection logic at all.

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