EQ Management

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

No annotations are supplied, so the description carries the full behavioral burden. It never says that set_defaults and set_house_curve mutate global state, whether those changes are reversible, what existing settings are overwritten, or whether a live API connection is required. Only the word 'global' hints at scope of impact.

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 with the resource scope first and the action inventory second — well front-loaded and free of filler. The only waste is that the action list duplicates the enum already present in the schema.

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 tool that mixes reads with global-state mutations, three parameters, and no output schema, the description is too thin: it omits connection requirements, the destructive footprint of the set_* actions, and any clue about the payload structure the caller must build. An agent could call it, but not confidently or safely.

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 action enum and the two payload parameters are already documented structurally, and the description's action list merely restates the enum. It adds no information about the shape or expected contents of the 'defaults' and 'house_curve' objects, which the schema leaves as untyped free-form. Baseline 3 is appropriate given the schema does the heavy lifting.

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 names a specific resource (global EQ defaults and settings) and enumerates the exact operations: list_equalisers, list_manufacturers, get_defaults, set_defaults, get_house_curve, set_house_curve. That is far more concrete than the vague 'Manage' opener would suggest. It does not, however, distinguish this tool from the sibling rew_api_measurement_eq, which an agent could easily confuse it with.

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 tool versus alternatives such as rew_api_measurement_eq, nor any statement of prerequisites (for example, whether rew_api_connect must run first). The action list implies what can be done, but nothing tells the agent which action to pick or when this tool is the wrong choice.

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