Skip to main content
Glama
dha-aa
by dha-aa

Set Item

set_item
DestructiveIdempotent

Update After Effects project items by renaming, relabeling, moving, or editing comments; adjust footage interpretation (fps, loop, alpha) or swap source files for all layers using that footage.

Instructions

Change a project item (comp, footage or folder): name, comment, label (0-16), folder (null: top level); footage interpretation (fps, loop, alpha); file swaps the footage's file for every layer that uses it (sequence: file is a sequence's first frame).

Input Schema

NameRequiredDescriptionDefault
fpsNoConform frame rate (image sequences import at 30)
fileNo
loopNo
nameNo
alphaNo
labelNo
folderNo
commentNo
item_idYes
sequenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.22.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare not-read-only, idempotent and destructive. Beyond that the description adds real behavioral detail the annotations cannot: 'file swaps the footage's file for every layer that uses it' (a cross-layer side effect) and 'sequence: file is a sequence's first frame'. It leaves out return behavior and permission requirements.

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?

A single densely packed sentence with no filler and the mutation target front-loaded. It is efficient, though the semicolon-chained clauses make it slightly hard to scan.

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-parameter destructive mutation with no output schema, the description covers the operation and most field semantics, including the important side effect on dependent layers. Gaps remain for 'loop', the alpha enum meaning, and error/return behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 10%, so the description carries most of the semantic load and largely succeeds: label range (0-16), folder null = top level, file's swap semantics, sequence's first-frame meaning, and the footage-interpretation grouping of fps/loop/alpha. It still leaves 'loop' and the alpha enum values unexplained, so it does not fully compensate.

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 ('Change') and resource ('a project item') and immediately narrows the resource to comp/footage/folder, then enumerates the settable fields. This is enough to tell it apart from set_comp, set_layer and set_property without opening any sibling schema.

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?

Usage is only implied via the field list (name/label/folder = item metadata; fps/loop/alpha = footage interpretation). There is no explicit when-to-use versus set_comp/set_layer, and no stated prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.