Skip to main content
Glama
LiveSession MCP
by Uri-Rosen

set_song_scale

Sets the song root key and scale name, and can enable scale mode to highlight the selected scale in MIDI clips.

Instructions

Set the song key, e.g. root="A", scale_name="Minor"; scale_mode=True highlights it in MIDI clips.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_song_scale"
  }
}

Input Schema

NameRequiredDescriptionDefault
rootNo
scale_modeNo
scale_nameNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, closed-world mutation, and the description usefully adds that scale_mode=True highlights the scale in MIDI clips. However, it does not say what happens when parameters are omitted or passed as null, which matters because all three parameters are optional with null defaults.

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?

A single front-loaded sentence with the behavior note appended immediately after the example; nothing is wasted. It is slightly dense but every clause carries information.

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?

An output schema exists, so return values need not be described, and the annotations cover the safety profile. The remaining weakness is the absence of reset/null semantics for a three-optional-parameter mutation tool, but for a simple setter this is close to sufficient.

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 0%, so the description must carry the burden, and it does name all three parameters and show valid example values for two of them. It does not explain null semantics — whether a null root leaves the existing key unchanged or clears it — or which scale_name values are valid, so the critical gap remains.

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?

The description states a specific verb and resource ("Set the song key") and pairs it with a concrete parameter example, so an agent knows exactly what capability this covers. It is distinguishable from the sibling get_song_scale by the verb, though it never names that counterpart explicitly.

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?

Usage is demonstrated through an inline example with real values (root="A", scale_name="Minor"), and the effect of scale_mode is explained. There is no explicit when-not guidance or reference to get_song_scale for reading the current scale, which keeps it short of a 5.

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