Plan or stop Ableton Live playback with a guarded, confirm-to-execute process that requires the observed state version and a single-use token.
Plan or stop Ableton transport playback.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | False executes with token and hash. | |
| planHash | No | Plan hash. | |
| confirmationToken | No | Single-use plan token. | |
| expectedStateVersion | Yes | Observed stateVersion. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.1Output schema / additionalPropertiesRemoved value: -trueOutput schema / anyOfAdded value: +[
+ {
+ "oneOf": [
+ {
+ "properties": {
+ "confirmation": {
+ "properties": {
+ "expiresAt": {
+ "type": "number"
+ },
+ "planHash": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "token": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "planHash",
+ "expiresAt"
+ ],
+ "type": "object"
+ },
+ "dryRun": {
+ "const": true
+ },
+ "plan": {
+ "type": "object"
+ }
+ },
+ "required": [
+ "dryRun",
+ "plan",
+ "confirmation"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "dryRun": {
+ "const": false
+ },
+ "operationOutcome": {
+ "properties": {
+ "evidence": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": 1
+ },
+ "status": {
+ "enum": [
+ "applied",
+ "outcome_unknown",
+ "postconditions_failed",
+ "pending_postconditions",
+ "pending_user_action"
+ ]
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "status",
+ "reason",
+ "evidence"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "dryRun",
+ "operationOutcome"
+ ],
+ "type": "object"
+ }
+ ],
+ "properties": {
+ "dryRun": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "dryRun"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "outcome": {
+ "enum": [
+ "unknown",
+ "not_executed"
+ ]
+ }
+ },
+ "required": [
+ "message",
+ "outcome"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+]v0.3.0Input schema / properties / confirmationToken / descriptionPrevious value: -"Short-lived, single-use token returned by the matching dry run."New value: +"Single-use plan token."Input schema / properties / dryRun / descriptionPrevious value: -"Omit or true to return a plan; false requires a valid confirmationToken."New value: +"False executes with token and hash."Input schema / properties / expectedStateVersion / descriptionPrevious value: -"Exact stateVersion observed immediately before planning."New value: +"Observed stateVersion."Input schema / properties / planHash / descriptionPrevious value: -"Hash returned by the matching dry run."New value: +"Plan hash."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=false, so the description should explain what stopping destroys (playback position? pending launches?) and that re-invocation is not safe. Instead it adds nothing beyond the safety flags, and does not mention the confirmation-token or state-version preconditions for the destructive path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler and the resource front-loaded. It is efficient, though the brevity comes at the cost of the two-phase workflow explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive, non-idempotent, two-phase (plan/execute) transport tool with four parameters and a required state version. The description omits the plan-then-confirm workflow, the meaning of a stale expectedStateVersion, and how it differs from stop_all_clips or panic, leaving key operational context missing despite the available output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 dryRun, planHash, confirmationToken, and expectedStateVersion. The description adds no additional semantics about how these combine (e.g., plan first, then confirm), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It names the resource (Ableton transport playback) and a verb (stop), plus a planning mode, but 'Plan or stop' blurs two distinct operations into one phrase and never distinguishes it from siblings like transport_play, stop_all_clips, or panic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus transport_play, stop_all_clips, or panic, and no explanation of the plan-then-execute workflow implied by dryRun/planHash/confirmationToken. The agent must infer everything from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.