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

No annotations are provided, so the description carries the full burden. It discloses the return fields (IP, model, eISCP port, MAC), which is useful, but says nothing about scan duration/latency, network-access requirements, or that it is a safe read-only operation. Adequate but with real gaps for a zero-annotation 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?

Two sentences, zero waste, and the core action (finding receivers on the local network) is front-loaded ahead of the return-value detail.

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 parameterless discovery tool with an output schema, the description covers purpose and return shape sufficiently; the return-value sentence is mildly redundant given the output schema. The main omission is behavioral context (scan time, permissions) that annotations would otherwise supply.

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 tool takes no parameters, so per the baseline this dimension starts at 4. There is no syntax or argument meaning the description could add, and it does not attempt to.

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 (Find) and resource (Onkyo/Integra/Pioneer receivers on the local network), plus the identifying fields returned. It is clearly a discovery tool rather than a control tool, so it is distinguishable from the get_status/set_* siblings, but it never explicitly contrasts itself with them.

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?

Usage is only implied: an agent can infer you discover receivers before configuring them, but the description names no conditions, prerequisites, or alternatives. No explicit when-to-use or when-not-to-use guidance is present.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the return payload (all five state fields) plus the multi-receiver prerequisite workflow. It is silent on permissions, error cases, or whether the call can fail for an unreachable receiver, which keeps it below 5.

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 sentences, front-loaded with the returned data and followed by the one conditional prerequisite. No filler, no restating the tool name.

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?

There is no output schema, so the description must carry the return contract — and it enumerates every field returned, including the volume range. Combined with the receiver-selection prerequisite, an agent has everything needed to call this correctly.

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% and the single 'receiver' param is fully documented in the schema, including the 'as returned by discover_receivers' and 'omit to use the default receiver' semantics. The description's 'pass the one you want' merely restates that, so baseline 3 is appropriate.

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 ('Get') and enumerates exactly which state fields are returned (power state, master volume with its 0-100 range, mute state, selected input, listening mode). This cleanly separates it from the set_* mutators and from discover_receivers without needing to open any schema.

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?

Gives an explicit conditional prerequisite: 'If there are several receivers on the network, call discover_receivers first and pass the one you want.' That names the alternative tool and the condition that selects it. It lacks any explicit when-not-to-use guidance, so it falls short of a 5.

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

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 usefully discloses a precondition ('receiver must be on') and the label convention for source names, but says nothing about failure behavior, whether the change is idempotent, or side effects on other settings — gaps that matter for a state-changing call.

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?

Three short sentences, front-loaded with the action, followed by the naming convention and the precondition. Every sentence adds information; there is no filler.

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?

An output schema exists, so return values need not be described, and the core action plus precondition are covered. It omits any mention of multi-zone behavior or the default-receiver fallback, though the schema itself documents the latter.

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 coverage is only 50% (the receiver parameter is documented in the schema, source is not). The description compensates for the undocumented parameter by explaining that values mirror front-panel labels and giving concrete examples ('bd-dvd', 'net'), which adds meaning the bare enum cannot convey.

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 gives a specific verb and resource ('Select the main zone's input source'), which is inherently distinct from sibling operations like set_volume, set_mute, or set_power. It does not explicitly name or contrast any sibling, so it stops short of the top tier, but an agent can identify the operation without opening the schema.

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?

Usage context is clear (switch the main zone's input) and a concrete precondition is stated: 'The receiver must be on.' There is no explicit when-not guidance or reference to alternatives, but for a simple discrete setter the context is sufficient.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses a precondition (receiver must be on) and a failure mode (may reject modes unsuited to the current input signal), which is more than most. However, it says nothing about persistence, whether the setting survives power cycles, or permission requirements.

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?

Three tight sentences, front-loaded with the core action, then mode semantics, then the precondition/failure caveat. Every clause carries information and nothing is padded.

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?

An output schema exists so return values need no explanation, and the precondition plus rejection behavior covers the main operational risk. The remaining gap is the undocumented half of the mode enum, which is material for a tool whose sole required argument is that enum.

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 coverage is only 50%: the 'receiver' param is documented in-schema but the 12-value 'mode' enum has no descriptions. The description compensates for 4 of those 12 values (direct, pure-audio, dolby-surround, dts-neural-x) but leaves stereo, all-ch-stereo, full-mono, theater-dimensional and all four game modes unexplained, so an agent still cannot distinguish those choices.

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 and resource with scope ('Set the main zone's listening mode (surround processing)'). No sibling competes for this function (set_power/set_volume/set_input/set_mute are all different domains), so an agent can route unambiguously.

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 gives value-selection guidance ('direct' and 'pure-audio' play unprocessed; 'dolby-surround'/'dts-neural-x' upmix) and a precondition (receiver must be on), but never says when this tool is the right call versus doing nothing or using set_input first. Usage is implied rather than stated.

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

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 says nothing about prerequisite state (connected/selected receiver), whether the change persists, or any permission/error behavior; only the boolean toggle is implied.

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 short sentence, front-loaded with the action, with no filler. It is efficient, though its brevity leaves no room for the scoping detail the tool arguably needs.

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?

An output schema exists so return values need not be explained, but for a mutation tool with zero annotations the description should cover prerequisites and the receiver/default-receiver behavior, which it omits entirely.

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 coverage is 50%: 'receiver' is documented in the schema (IP from discover_receivers, omit for default), while 'muted' has only a title. The description's 'mute or unmute' loosely maps to the boolean, but adds no format or edge-case meaning beyond the schema.

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 (mute/unmute) and resource (the main zone), which is enough to distinguish it from siblings like set_volume, set_power, and set_input. It stops short of naming the receiver/zone scope that the 'receiver' parameter implies, so it doesn't fully resolve how this tool relates to multi-receiver setups.

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 versus alternatives, no mention of whether a receiver must first be picked up via discover_receivers, and no statement of what happens when 'receiver' is omitted or that only the main zone is affected.

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

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

No annotations are provided, so the description carries the full burden. It usefully clarifies that 'off' means standby rather than a hard power-off, which is genuine behavioral context beyond the schema. However, it says nothing about side effects on other zones, permission requirements, or error behavior for an unreachable receiver.

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 front-loaded sentence with no filler, stating both states of the toggle. Efficient, though it is arguably terse given the missing behavioral detail elsewhere.

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?

An output schema exists, so return values need not be described, and the schema covers the receiver parameter. For a mutation tool with zero annotations, the description covers the state semantics but omits side effects and error/precondition behavior, leaving it only minimally sufficient.

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 coverage is 50%: the 'receiver' parameter is documented in the schema (including the discover_receivers reference and default behavior), but the required 'on' parameter has no schema description. The description compensates partially by establishing that true = on and false = standby, so the required flag's meaning is recoverable. Baseline 3 fits.

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 verb (turn on / put into standby) and resource scope (the main zone), making the tool's job clear. It maps the boolean 'on' to the two states, so an agent understands the effect. It stops short of differentiating itself from siblings like get_status or set_volume, but the power semantics are unambiguous.

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?

Usage is implied by the name and description (use this to change power state of the main zone), but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_status for reading power state. Adequate but leaves routing to inference.

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

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

There are no annotations, so the description carries the full behavioral burden. It does disclose two useful traits beyond the schema: values above the configured safety cap are clamped, and newer models accept 0.5 steps. However, it omits error behavior, permission/auth requirements, and whether the clamping is silent or reported.

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 tight sentences with zero filler. The core action and scale are front-loaded, with the clamping caveat following immediately after.

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?

An output schema exists, so return values need not be explained, and the description covers the key range and clamping behavior. It is nearly complete for a simple setter, missing only auth/permission notes and out-of-range error semantics.

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 only 50%: the receiver parameter is documented in the schema, but the required level parameter has no schema description. The description compensates by defining the level's 0-100 scale and the 0.5-step granularity, adding real meaning beyond the bare number type.

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 ("Set") and resource ("master volume") and adds scale semantics ("receiver's 0-100 display scale"). This clearly separates it from set_mute, set_power, and set_input, but it never names those siblings explicitly, so it sits just below the top tier.

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 explains what the tool does but gives no when-to-use context and never points to alternatives such as set_mute for temporary silencing. An agent must infer the routing between sibling setters on its own.

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