Adjust the channel high-pass filter between 20 and 400 Hz. Set the frequency to activate filtering, or disable it with the on switch—keeping low-end rumble under control.
Channel high-pass (low-cut) filter, 20..400 Hz. Setting freq_hz also switches it on unless on=false.
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | ||
| target | Yes | ||
| freq_hz | No |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and destructiveHint=false, which indicate a mutating but non-destructive operation. The description adds valuable behavioral context beyond those annotations: it explains that setting freq_hz automatically switches the filter on unless on=false, and specifies the valid frequency range. This is exactly the type of side-effect disclosure that helps agents predict outcomes.
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 extremely concise: two sentences, no filler, and the core purpose is front-loaded. Every word adds information, making it easy to parse quickly.
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 simple filter-setting tool, the description covers the main behavior and range, but it omits any explanation of the target parameter (likely the channel identifier) and does not describe what happens when on is explicitly set versus when freq_hz is given. It also lacks any description of the output or confirmation. Given the absence of an output schema, these gaps matter, though the core operation is understandable.
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?
With 0% schema description coverage, the description must compensate, but it only explains freq_hz and on partially. The required 'target' parameter is entirely undocumented; an agent cannot infer what value to pass (likely a channel identifier) from the description. The auto-switch behavior for freq_hz and the override with on are helpful, but the missing target semantics is a significant gap.
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 clearly states the tool sets a channel high-pass (low-cut) filter with a specific frequency range (20–400 Hz). This verb+resource combination is unambiguous and distinguishes it from sibling tools like set_gate or set_eq without needing to inspect schemas.
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 implies the tool is for applying a high-pass filter to a channel, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. The context is clear enough for a domain-savvy agent, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.