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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing beyond the returned content: no statement that it is a side-effect-free read, no auth requirements, no refresh/polling semantics. The 'get' name implies a safe read but this is never asserted.

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 compact clause with no filler, and the most important content (current scene) is front-loaded. It is efficient, though it is terse to the point of omitting the verb and any usage framing.

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?

An output schema exists, so the description need not explain the return payload, and it sensibly summarizes it instead. However, with no annotations and no usage guidance, an agent still lacks context on when and why to invoke it relative to the six sibling tools.

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?

The tool takes zero parameters and the schema has no properties, so there is nothing for the description to clarify. Baseline 4 applies for a no-parameter tool.

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?

The description is a noun phrase listing returned data ('Current scene, saved cue names, targets, and running ramps') rather than a verb+resource statement, so the retrieval action is only implied by the tool name. It does not contrast itself with siblings like recall_cue or resend_all, though the 'current state' semantics are distinguishable from the mutating siblings.

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 call this versus the sibling tools (save_cue, recall_cue, set_scene, ramp). No prerequisites, timing, or exclusions are stated. An agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden; it does disclose one important trait — the call returns immediately, so the glide continues in the background rather than blocking. It does not say what happens if a second ramp targets the same param, whether a ramp can be cancelled, or what side effects occur on the underlying value.

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?

Very short and front-loaded with the core verb and effect. The trailing param line is slightly awkwardly formatted but adds real information rather than padding.

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?

An output schema exists, so return-value explanation is not needed, and the fire-and-forget behavior is stated. But for a 3-required-param mutation tool with zero annotations and zero schema descriptions, the definition still leaves concurrency/interaction behavior and two parameter meanings unspecified.

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 coverage is 0%, so the description must compensate, and it does clarify the 'param' argument's accepted forms ('energy', 'bpm', 'macro:<name>') plus an example. However, 'to' and 'seconds' are left entirely unexplained beyond their names, so two of three parameters rely on inference.

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?

States a specific verb and effect ('Glide a numeric value over time') with concrete examples ('a build, a fade'), which tells the agent exactly what this does. It is clearly distinct from siblings like set_scene or send_osc, though it never names or contrasts them explicitly.

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 choose ramp over alternatives such as set_scene or send_osc, nor any prerequisites (e.g. whether the param must already exist). The only contextual cue is 'Returns immediately', which hints at the async style but is not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the concrete side effect — sending /av/cue <name> — which is more than most, but it omits failure behavior for unknown names, whether the operation is idempotent, and whether it requires the cue to have been saved in the current session.

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 front-loaded sentence covering action, name source, and emitted message. No filler, though the trailing OSC path detail is only marginally useful to an agent deciding whether to call it.

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?

An output schema exists, so return values need not be explained, and the description covers the core action and parameter source. It is still thin on error conditions and preconditions for a tool that performs a state-changing dispatch.

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 0%, so the description must compensate. It echoes the <name> placeholder and, helpfully, states where valid names originate (config/av.toml or save_cue), but it gives no format, casing, or naming constraints beyond that.

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?

"Jump to a saved cue" gives a specific action on a specific resource, and naming save_cue as the source makes the pairing with the sibling explicit. It is clear what the tool does, though "jump to" is slightly metaphorical for what is ultimately an OSC dispatch.

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?

Mentioning that cues come from config/av.toml or save_cue implies the recall-after-save workflow, which is useful context. However, there is no explicit when-to-use guidance or exclusion, and no statement about what happens if the name does not exist.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation is scene-wide (not selective), but says nothing about idempotency, cost, whether it must follow a state change, or side effects on a running engine. Output schema existing means return values need not be covered here.

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?

One sentence, front-loaded with the action and scope, followed by a parenthetical use case. Every clause earns its place with no redundancy.

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?

For a zero-parameter action with an output schema, the description covers what it does and when to reach for it, which is close to sufficient. Minor gaps remain around prerequisites (e.g. whether it must be called after set_scene) and what the broadcast actually covers, but nothing essential is missing.

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?

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to explain or get wrong. Schema coverage is 100% and nothing in the schema requires description-side compensation.

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?

States a specific verb (re-broadcast) and a clear resource scope (the whole scene), which distinguishes it from the targeted-send semantics implied by sibling send_osc. It does not explicitly name or contrast itself with any sibling tool, so it falls short of a 5.

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?

Provides a concrete trigger scenario ('after restarting Max or the visual engine'), giving the agent a clear condition under which this tool is appropriate. It offers no exclusions or explicitly named alternatives (e.g. send_osc for single messages), so it stops short of 5.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful trait: the snapshot is volatile and lost on server restart. It omits other mutation behavior such as whether an existing name is overwritten and whether any prerequisite state is required.

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 front-loaded sentence with zero waste; the action comes first and the durability caveat is parenthetically attached rather than padded into its own sentence.

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?

An output schema exists, so return values need not be described, and for a one-parameter tool the description covers the action and a key behavioral caveat. Only name-collision/overwrite behavior is missing.

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 0% — the schema says only that 'name' is a string — so the description must compensate. 'Under a name' identifies it as a label but adds no uniqueness, overwrite, or format semantics, leaving the parameter effectively undocumented.

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?

Names a specific verb (snapshot) and resource (current scene) plus the naming parameter, so the operation is unambiguous. It never explicitly names the sibling recall_cue, so it stops short of full sibling differentiation.

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?

The pairing with recall_cue is strongly implied by the save/restore naming, and 'current scene' implies you call it while the desired state is live, but no alternative or when-not condition is ever stated. Usage is inferred rather than guided.

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

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

With no annotations, the description carries the full burden. It discloses the broadcast default ("to all targets") and frames itself as an escape hatch, but says nothing about side effects, permissions, ordering, or whether omitted targets is safe. Output schema exists, so return values need not be described.

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?

Two short sentences, front-loaded with the escape-hatch framing and the routing behavior, then the use case. No filler; every clause carries information.

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?

For a 3-parameter raw-message tool with no annotations, the description covers purpose, usage, and target defaulting, but leaves most parameter semantics and side-effect behavior undocumented. Adequate but with clear gaps given zero schema description coverage.

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 coverage is 0%, so the description must compensate. It implicitly conveys address and args via the example ("/visuals/layer/2/opacity" 0.5) and clarifies the targets parameter's default behavior ("all targets or the named ones"), but leaves arg typing and the full meaning of targets unspecified.

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?

States a specific verb+resource ("send a raw OSC message") and scopes it ("to all targets or the named ones"), which an agent can distinguish from scene-model siblings like set_scene. It is clear but does not explicitly name which sibling it replaces.

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?

"Use for program-specific messages the scene model doesn't cover" gives a clear when-to-use condition with a concrete example address. It implies the alternative (the scene model / set_scene) without naming it explicitly, so no exclusion list is provided.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the OSC broadcast to every target, the partial-update semantics (unspecified fields are left alone), and that bpm is not the real tempo. It omits reversibility, whether cues are needed to persist the scene, and error/rate-limit behavior.

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?

Front-loaded with the core action, followed by compact parameter notes and a tempo caveat. Every sentence carries information, though the parameter notes are telegraphic enough to be slightly fragmented.

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?

An output schema exists so return values needn't be explained, and the mutation semantics and OSC broadcast are covered. However, for a 6-parameter mutation tool with zero annotations and zero schema descriptions, the unexplained key and section parameters and the unstated meaning of a 'scene' leave real gaps.

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 0% across 6 parameters, so the description must compensate. It defines ranges for energy and macros (0..1), the palette format (list of hex colors), and partially explains bpm, but key and section are left entirely undefined in both schema and description.

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?

States a specific verb (change), resource (the shared scene), and a distinctive side effect (broadcast to every target over OSC), which separates it from the raw send_osc sibling. It does not name any sibling explicitly to contrast against, so it stops short of a 5.

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?

Gives explicit cross-tool routing for the tempo case: bpm here is informational, and changing Live's tempo requires ableton-mcp's set_tempo or Ableton Link. It also clarifies the partial-update contract ('only fields you pass are changed'). No guidance on when to use save_cue/recall_cue instead, so not a 5.

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