Skip to main content
Glama

fire_scene

Fire an Ableton Live scene and get the actual beat the launch lands on, making timing visible even with quantization.

Instructions

Fire a scene and report which beat the launch actually lands on.

Returns:
    Dictionary with the launch grid, the song position read on either side of the
    call, and the beat the launch falls on, or both candidate beats where the
    window spanned a boundary.

Note:
    ``fire`` answers that it succeeded and says nothing about when anything starts.
    Live quantises a launch to the next grid boundary, so aiming a scene at a
    particular bar from outside is a race: read the position, decide, fire, and Live
    may already have passed the boundary the decision was made for. Measured against
    Live 12.4.5: a read of ``song.current_song_time`` returned 55.6, the scene was
    fired, and the launch landed at 96 rather than 64, one 8 bar boundary later than
    intended. Nothing in the result said so.

    This does not remove the race, which is Live's and is not reachable from here.
    It makes the landing visible. The position is read immediately before and after
    the call, and the answer names the beat a launch issued at either end of that
    window falls on. Where the two differ, ``certain`` is false and both are given:
    the launch is on one of them and which one is not knowable from outside.

    With quantisation off the launch starts at once, so the window's own ends are
    the answer and the beat is known no better than the window is wide.

    This fires and does not wait. ``is_playing`` read straight afterwards is
    normally false and that is correct, not a failure: nothing has started yet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sceneYesScene index in song.scenes, counted from 0.
confirmNoTrue fires the scene. False reports the launch grid and where a launch issued now would land, and fires nothing.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations are minimal (all false), so the description carries the full burden and does so richly. It discloses the asynchronous fire-and-not-wait behavior, Live's quantisation race with a concrete measured example, the meaning of certain=false and candidate beats, and that is_playing=false immediately after is expected behavior rather than failure. No contradiction with annotations.

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 purpose is front-loaded and the Returns section is compact. The Note section is lengthy but each part earns its place by explaining real behavioral pitfalls. The measured example adds credibility and concrete context, though it is slightly more detailed than strictly necessary.

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?

Given the tool's complexity—quantisation timing, race conditions, ambiguous landing beats, and async behavior—the description is exceptionally complete. It covers what happens before, during, and after the call, how to interpret ambiguous results, and why immediate is_playing=false is not an error. With an output schema present, return-value details are not missing.

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 coverage is 100%, so the baseline is 3. The description clarifies the 'confirm' behavior indirectly through 'This fires and does not wait,' but it does not explicitly map behavior to the confirm parameter or add extra meaning beyond the schema's own description of the two parameters. It neither hurts nor significantly improves schema semantics.

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 opens with a specific verb and resource: 'Fire a scene' and adds the distinguishing reporting behavior ('report which beat the launch actually lands on'). This clearly separates it from generic transport tools like play and stop, and the Returns section reinforces the unique output.

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?

The description gives clear operational context: it explains the race condition, what measure the result is reliable to, and how to interpret is_playing immediately after firing. It does not explicitly name alternatives or say when not to use it, but the context is sufficient for an agent to decide when this tool's reporting adds value.

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