rew_dual_resolution_analysis

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It only says 'Return ... views,' which implies a read-only operation, but it does not state whether prior state is required (does 'id' need a loaded measurement/session?), what the return value contains or its format, whether there are side effects, or failure modes. For an analysis tool with zero annotation coverage, this is a significant gap.

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 sentence with no filler; the core idea (two views, one engineering one perceptual) is front-loaded and the rationale follows immediately. It is efficiently written, though the brevity is partly at the expense of the parameter and usage detail the other dimensions penalize.

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 7-parameter, parameter-heavy analysis tool with 0% schema description coverage, no annotations, and no output schema, this description is far from sufficient. It captures the conceptual intent but omits operational essentials: what 'id' refers to, what the returned views are, parameter semantics, and prerequisites. An agent would struggle to call this correctly without inspecting elsewhere.

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 all 7 parameters, so the description bears full responsibility for explaining them. It offers only faint conceptual hints — 'ERB-perceptual' maps to stepErb/widthErb and 'minimally smoothed' to smoothingTransitionHz — but it gives no units, ranges, defaults, or interactions for lowHz, highHz, modalBoundaryHz, or the others. Seven undocumented parameters with near-zero compensation earns a low score.

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 verb and resource ('Return raw/minimally smoothed and ERB-perceptual views') and gives a genuine rationale — keeping narrow engineering defects separate from broad listening interpretation. This helps conceptually separate it from analysis siblings like rew_crossover_analysis. However, it never names an alternative and the deliverable is abstract ('views' — data, a figure, a trace?), 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?

There is no when-to-use vs. when-not-to-use guidance and no alternative tool named, despite many closely related analysis siblings (rew_crossover_analysis, rew_multiseat_analysis, rew_direct_late_analysis, rew_compression_analysis). The 'so narrow engineering defects remain separate' clause implies a use case, but it does not say when an agent should pick this over other analyses or what conditions make it inappropriate.

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