Skip to main content
Glama

add_marked_frame

DestructiveIdempotent

Adds or updates a labeled marker at a tick frame in a Level Sequence, optionally making it an evaluation fence in an undoable, saved edit.

Instructions

Adds a marked frame (a labelled marker on the Sequencer timeline) at a tick-resolution frame of a Level Sequence found by asset name under /Game, in an undo transaction, and saves the sequence; is_determinism_fence turns the same mark into an evaluation fence. Idempotent per frame: an existing mark at that frame is updated instead of duplicated, its label replaced when one is given and both flags overwritten with the values passed (false when omitted); already_existed says which. Read marks with get_marked_frames, delete one with remove_marked_frame.

Returns: { sequence_name: string, frame: int, mark_index: int, label: string, is_determinism_fence: bool, is_inclusive: bool, already_existed: bool, marked_frame_count: int, saved: bool, save_error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
frameYesTick frame number to mark.
labelNoOptional human-readable label (auto-generated if empty).
is_inclusiveNoOptional bool (default false): when a determinism fence, how the previous/next ranges are dissected ((X,Y]->(Y,Z] vs (X,Y)->[Y,Z]).
sequence_nameYesName of the target Level Sequence.
is_determinism_fenceNoOptional bool (default false): treat the mark as an evaluation fence (cannot be crossed in one evaluation).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare idempotentHint=true, destructiveHint=true, readOnlyHint=false, but the description goes well beyond them: it discloses the undo transaction, the auto-save of the sequence, the exact idempotency semantics (label replaced, both flags overwritten with passed values, false when omitted), determinism-fence behavior, and the already_existed signal. This is a rich behavioral profile not derivable from structured fields.

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?

Dense but every clause carries information; the first sentence front-loads purpose, scope, and transaction behavior, and alternatives and the Returns block are appended. The long run-on sentence could be broken up, but there is no filler.

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

Completeness5/5

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

With 5 params, full schema coverage, no output schema, and rich annotations, the description supplies everything an agent needs: the asset lookup convention, transaction/save behavior, idempotency contract, sibling navigation, and an explicit return shape. Nothing material is missing.

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 100%, so the baseline is 3, but the description adds real meaning: is_determinism_fence's conversion of a mark into an evaluation fence, and the overwrite semantics when flags are omitted (treated as false). This clarifies the mutation contract beyond the per-field schema text.

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 ('Adds a marked frame... on the Sequencer timeline') with precise scope (tick-resolution frame, Level Sequence found by asset name under /Game). It explicitly distinguishes itself from the sibling read/delete tools (get_marked_frames, remove_marked_frame), so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Names the alternatives and their conditions ('Read marks with get_marked_frames, delete one with remove_marked_frame') and spells out the update-vs-create case for an existing mark at that frame. There is no ambiguity about when to reach for this tool versus its siblings.

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