Skip to main content
Glama
Sign In
Live Maestro

Live Maestro

by romanstark
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

write_tempo_map

Write tempo automation events as ramps or steps into a new Ableton Live Set copy, preserving exact beat/BPM read-back for verification.

Instructions

Write tempo automation to a new set copy, with exact persisted event read-back.

Shape describes interpolation toward the next event. Duplicate boundary events
encode a step. Live 12.4.6 preserved both ramps and steps on actual reopen/save.
Open the new copy and use verify_tempo_map to check its unwarped clip duration.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source_path": "<source_path>",
      "output_path": "<output_path>",
      "events": "<events>"
    },
    "name": "write_tempo_map"
  }
}

Input Schema

NameRequiredDescriptionDefault
eventsYesOrdered beat/BPM events, beginning at zero.
confirmNoTrue carries the removal out. False changes nothing and returns a report of what the call would remove, which is how to look before committing to it.
output_pathYesNew .als copy; an existing file is refused.
source_pathYesSaved source .als; source bytes are preserved.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare non-readOnly, non-destructive, non-idempotent, and the description stays consistent while adding real behavioral context: source bytes preserved, exact persisted event read-back, and the empirical claim that Live 12.4.6 preserved both ramps and steps across reopen/save. The shape/step-encoding semantics beyond the annotations are genuinely valuable. It doesn't discuss failure modes or the two-phase confirm flow.

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?

Purpose is front-loaded in one clean sentence, and the added details are brief. The stray line break and the version-pinned 'Live 12.4.6' anecdote are slightly off-topic but don't bury the point.

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 complex tool with a nested events array and an output schema, the description covers the write scope, source preservation, shape encoding, and the verification workflow adequately. It omits any explanation of the confirm/dry-run behavior, though the schema carries that.

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 structured baseline would be 3. The description goes beyond it by clarifying event shape semantics and the non-obvious rule that duplicate boundary events encode a step, which the schema's terse 'Interpolation from this event toward the next one' does not convey.

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 and resource with scope: 'Write tempo automation to a new set copy.' An agent can distinguish it from read_tempo_map and verify_tempo_map. However it never names the closest siblings (write_automation, apply_tempo_map, set_tempo) to say how this tool differs from them.

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?

Provides a downstream workflow hint ('Open the new copy and use verify_tempo_map to check its unwarped clip duration'), which is useful follow-up context. But there is no explicit when-to-use vs when-not guidance and no routing away from apply_tempo_map or write_automation, leaving the choice to inference.

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