Skip to main content
Glama

Measure Beat Grid

lab_beatgrid
Idempotent

Measure the TEMPO of the sequence's bound music track and store the beat grid — opens the real file with ffmpeg and analyses it, no guessing and no provider, so it costs nothing but a few seconds. Writes bpm and metadata.beat_grid on the audio row; it does NOT touch the timeline (timeline_geaendert: false). Deterministic and cached: a second call returns the same numbers without downloading again (pass neu_messen to force). READ confidence AND verlaesslich BEFORE YOU CUT. Below the threshold (0.35) lab_apply_rhythm computes durations but deliberately does NOT snap them to the grid — that is a decision, not a failure. Soft material measures badly: a real swing track came out at 0.164, an ordered hard pulse (techno, 128 bpm) at 0.621. Half and double tempo are the classic misreads, so bpm_alternativen is part of the answer. frame_konflikt reports the collision between beat grid and frame grid, for BOTH renderers: export (24 fps, the delivered MP4) and murnau (25 fps, the editor timeline). Read frames_pro_schlag as a DEVIATION, not a count: it is how far one beat sits from a whole frame, between 0 and 0.5. 0 means beat and frame coincide (100, 125 and 150 bpm at 25 fps do); anything above means beat-accurate and frame-accurate cannot both hold, and the rounding error accumulates across clips — measured on a finished MP4 at 128 bpm: up to 64.7 ms off the audible beat although every cut point had snapped. Shown here, not fixed: that decision belongs to a human. Refusals that name their own remedy: 409 without a bound music track (run lab_bind_audio), 409 when the track is pending (poll lab_list_audio), 502/504 when the audio host is unreachable or slow, 422 when the file carries no usable audio, 503 when ffmpeg is missing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taktNoBeats per bar (default 4). INPUT, not detection — time-signature detection is explicitly out of scope. It only affects where the downbeats fall, which is what the rhythm 'auf die Songstruktur' snaps to
seq_idYesSequence id (from lab_create_sequence/lab_list_sequences) — positive integer as string
neu_messenNoMeasure again even though a result for this exact file already exists. Default false. The measurement is deterministic — the same file gives the same number, so this only helps after the track behind the url was swapped

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: writes `bpm`/`metadata.beat_grid`, does not touch the timeline, is deterministic and cached, costs only seconds, opens the real file via ffmpeg with no provider, and enumerates refusal codes (409/502/504/422/503) with remedies. This is rich disclosure; only the exact return-field semantics of every key are left implicit.

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?

Front-loaded with the core action and outcome, and most sentences carry genuine behavioral information. It is long and dense with parenthetical asides and example measurements, some of which could be trimmed, but little is pure 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?

No output schema exists, yet the description explains the return fields an agent must interpret (confidence, verlaesslich, bpm_alternativen, frame_konflikt, frames_pro_schlag) and their meaning, including the 0–0.5 deviation semantics. Nothing needed to call and interpret it is 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 description coverage is 100%, so the schema already documents `takt`, `seq_id` and `neu_messen`. The description reinforces `neu_messen` ('pass neu_messen to force') but adds no format or constraint information beyond what the schema already states. Baseline 3 is appropriate.

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+resource: 'Measure the TEMPO of the sequence's bound music track and store the beat grid'. It immediately distinguishes itself from siblings like lab_apply_rhythm (which consumes the grid) and lab_bind_audio (which supplies the track), so an agent can route correctly without opening a 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?

Explicitly instructs 'READ confidence AND verlaesslich BEFORE YOU CUT', explains what lab_apply_rhythm does below the 0.35 threshold, and names the remediation tools for each refusal (lab_bind_audio, lab_list_audio). When-to-use, downstream dependency, and alternatives are all covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources