get_eq_band_enabled

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavior beyond annotations: the exact return shape ('ret' boolean), 0-based indexing for FX and band index, and the bandtype numeric code mapping. No contradiction with annotations.

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?

The description is compact and well-structured with a purpose line, Args section, and Returns section. It is front-loaded with the core behavior and avoids unnecessary prose, though the Args section is incomplete by omitting track_index.

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?

The description provides the return contract and most parameter semantics, and the readOnly annotation covers side-effect concerns. However, it fails to explain the required track_index parameter or clarify that this is a track-FX operation versus a take-FX operation, leaving a meaningful gap for correct invocation.

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 description documents fx_index, bandtype, and bandidx with helpful semantics, including the bandtype enum mapping and 0-based indexing. However, it completely omits track_index from the Args block even though track_index is a required schema parameter and its meaning is not otherwise obvious.

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 states a specific action ('Check whether a ReaEQ band is enabled') with a clear resource target. It distinguishes itself from the sibling set_eq_band_enabled by framing itself as a read/query operation, and from get_eq_bands by targeting a single band's enabled state.

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 read/query intent is implied by 'Check whether,' and the sibling set_eq_band_enabled makes the contrast obvious, but there is no explicit guidance about when to use this tool instead of related ones, nor any mention of prerequisites like locating the ReaEQ FX first.

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