set_key

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. It does not disclose whether changing the key transposes existing notes, whether the change is persisted to the project file, what happens on an out-of-range integer or unparseable key name, or whether a project must already be open — all material for a mutation tool.

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 verb and the encoding rule, with no filler. The only bloat is the full bilingual restatement, which doubles length without adding information, though this is a common convention for Japanese-authored tools.

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 single-parameter setter this covers the value domain well, which is the main risk area. It remains incomplete on effects and failure modes — an agent cannot tell from this text whether the key change transposes the score or merely labels it.

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%, yet the description fully compensates by explaining the dual encoding: integers 0=C through 11=B, or note names such as 'F#'/'Bb'. That is the essential fact an agent needs; only edge details (enharmonic acceptance, exact integer bounds, case sensitivity) are left implicit.

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 ('Set the project key') and spells out the exact value domain, so the agent knows precisely what is being configured. It stops short of naming any sibling, but among the listed siblings none competes for the same action, so disambiguation is not really needed.

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 description is pure value specification — it never says when to call this, what the current key should be replaced with, or what happens to existing notes when the key changes. Usage is only inferable from the tool name itself, which the rubric treats as weak guidance.

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