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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the useful context that discovery happens over UDP broadcast (implying local-network adjacency and possible timeouts), but it does not say how long the scan takes, whether it blocks, or what it returns.

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; the verb, resource, and mechanism all appear in the first few words. Nothing could be trimmed without losing information.

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 zero-parameter read-only tool this is nearly complete, and the UDP/local-network wording conveys the key constraint. The remaining gap is that with no output schema, the description never indicates that it returns a set of discovered bulbs (and whether that set can be empty).

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 zero parameters, so per the rubric the baseline is 4. There is no parameter semantics to add, and the description correctly implies a no-argument operation.

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 (Scan), a specific resource (WiZ smart bulbs), and the mechanism (UDP broadcast on the local network). This implicitly and clearly distinguishes it from the sibling list_lights, which enumerates already-known bulbs rather than discovering 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?

The description implies the when-to-use case (finding bulbs on the network) but never states it explicitly, nor does it name list_lights as the alternative for already-known bulbs. Usage is inferable but not spelled out.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered without the description. The description adds the set of returned fields (power, brightness, color, scene), which is useful, but says nothing about behavior when a bulb is unreachable, latency, or whether state is cached.

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?

One front-loaded sentence with no filler, and the core purpose comes first. The trailing "(power, brightness, color, scene, etc.)" is informative but the "etc." leaves the return scope slightly open-ended.

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 usefully compensates by naming the state fields returned, and the single input parameter is fully documented in the schema. Remaining gaps (error/offline behavior, exact response shape) are minor for a simple state-read tool.

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?

There is a single required parameter with 100% schema description coverage ("Bulb name or IP address to query"), so the schema fully documents it. The description adds no additional meaning about target formatting or name-vs-IP resolution, so baseline 3 applies.

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 ("Get the current state of a WiZ bulb") and enumerates the state facets returned, making it easy to distinguish from setters like set_color or turn_on. It does not explicitly name a sibling, but the read-vs-write distinction against the other tools is obvious.

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 rather than stated: an agent can infer this is the read-side tool to call before deciding whether to change anything. There is no explicit when-to-use/when-not or pointer to alternatives such as list_lights or discover_lights for enumeration.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior context by noting the data comes from an in-memory registry (results depend on prior discovery), but says nothing about empty-registry results, ordering, or refresh behavior.

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 — the resource and its data source appear immediately.

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 trivial parameterless read tool with annotation coverage and no output schema, this is nearly sufficient; only the empty/stale-registry case is left unstated.

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 zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies.

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 (list) and resource (WiZ bulbs) and scopes it with 'previously discovered... from the in-memory registry,' which cleanly separates it from the sibling discover_lights that performs live scanning.

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 phrase 'previously discovered' implies you should call this after a discovery step rather than as a first action, but the description never explicitly says when to prefer this over discover_lights or what happens if the registry is empty.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful fact that the scene set is a fixed, small collection of 32, but says nothing about ordering, return shape, or whether results can change.

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; the count and the returned field are the two facts an agent needs and both are stated up front.

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 zero-parameter read-only list tool with no output schema, the description is nearly sufficient: it tells the agent how many items to expect and that IDs come back. Only the exact return shape (e.g., whether names are included) is left implicit, which is minor here.

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 zero parameters, which is the baseline-4 case. The schema confirms an empty object and the description is consistent with it, so no compensating parameter detail is needed.

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 (list scenes) and adds concrete scope detail: the fixed count of 32 and that IDs are included in the result. It is clearly distinguishable from the control siblings like set_scene, though it never names set_scene or list_lights as the contrasting alternative.

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 explicit when-to-use statement, but mentioning 'with their IDs' implies the intended workflow of looking up IDs before calling set_scene. That is inferred rather than stated, so it sits at minimum-viable guidance.

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, and it discloses almost nothing: it is a mutation of physical device state, yet reversibility, permission/auth needs, behavior for unreachable bulbs, and whether brightness is reset are all unstated. The only real trait conveyed is multi-target scope via 'one or more'.

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 that states the action, the property being set, and the affected scope with 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?

A five-parameter state-mutating tool with no annotations and no output schema should say more about side effects and failure modes; the description is essentially just a title restatement plus scope. The fully documented schema rescues the parameter side but not the behavioral side.

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% — r/g/b ranges, the 1-100 brightness bound, and the target formats (name, IP, "all") are all documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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?

Specific verb ('Set') plus resource ('RGB color') and target scope ('one or more WiZ bulbs'). It is clearly distinguishable from siblings like set_temperature (color temperature) and set_scene (preset scenes), so an agent can route without opening a 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 is only implied by the name: an agent can infer it sets a custom RGB color, but nothing states when to prefer this over set_temperature or set_scene, nor any preconditions (bulb on, discovered, etc.). No exclusions or alternatives are offered.

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 supplied, so the description carries the full disclosure burden. 'Activate' implies a state mutation, but it says nothing about whether the scene overrides existing color/temperature, whether it persists, or what happens when a scene name or bulb target is invalid.

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 naming the action, the scene identifier, and the target scope. Every word earns its place with 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?

With 100% parameter coverage, no output schema, and a simple mutation, the description is close to sufficient. The remaining gap is the missing workflow context (discover/list before setting) and unstated behavior for unknown scenes, which for a 3-param tool is a minor omission.

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 schema already explains scene name/ID, speed range, and the target options including 'all'. The description only restates name/ID and bulb targeting, adding no format, range, or default detail 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?

Specific verb ('Activate') plus resource ('WiZ scene') and scope ('on one or more bulbs'), which separates it from set_color/set_temperature/list_scenes. It does not, however, explicitly name or contrast itself with any sibling tool, keeping it short of a 5.

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?

No guidance on when to choose this over set_color or set_temperature, and no mention of prerequisites such as discovering bulbs or listing available scene names before calling. The agent must infer the workflow entirely from the sibling list.

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 does not disclose whether the change is applied atomically across multiple bulbs, what happens to brightness when omitted, whether the setting persists across power cycles, or what errors look like for unreachable bulbs.

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?

One short sentence, front-loaded with the verb and resource, with no wasted words. Nothing extraneous to trim.

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 mutation tool with no annotations and no output schema, the definition is minimally viable: it says what changes but not the effect on omitted parameters, multi-bulb failure behavior, or confirmation of success. The schema covers inputs fully, so the gap is behavioral rather than structural.

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 schema already documents target, temp range, and brightness. The description's only parameter-adjacent content ('warm to cool white') duplicates the Kelvin endpoints already spelled out in the temp property.

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?

Specific verb+resource ('Set the color temperature of one or more WiZ bulbs') with the scope of valid values parenthetically stated. It is clearly distinguishable from the sibling set_color, which handles color rather than white-point temperature.

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 purpose implies when it is used (white-temperature control) but there is no explicit when/when-not guidance and the sibling set_color is never named or contrasted. An agent must infer that color temperature and color are mutually exclusive operations.

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 burden, and it does add one useful behavioral fact: it reads current state first (a read-modify-write). It says nothing about whether the toggle is idempotent, what happens if a bulb is offline, or whether the change applies instantly — gaps for a mutation 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?

One short front-loaded sentence with a parenthetical for the behavioral nuance; nothing redundant and 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?

For a single-parameter tool with no annotations and no output schema, the description is workable but thin — it omits what the result looks like and any failure/idempotency semantics. Adequate minimum, not complete.

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 100% and the single 'target' parameter is fully documented in the schema. The description's 'one or more bulbs' lightly reinforces bulk-targeting via 'all', but adds no format or syntax detail beyond what the schema provides, so the baseline 3 applies.

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 (toggle) and resource (power state of WiZ bulbs), with scope made explicit ('one or more'). The verb itself differentiates it cleanly from the turn_on/turn_off siblings without needing to name 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?

No guidance on when to prefer toggle over turn_on/turn_off, or whether it requires the bulb to already be reachable/discovered. Usage is only inferable from the verb, and no alternatives or prerequisites are mentioned.

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 does not state whether the operation is idempotent, what happens if a bulb is already off, whether it returns per-bulb status, or whether targeting 'all' has side effects.

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 clause with no filler or redundancy. Every word earns its place.

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 tool is simple and the schema fully documents the only parameter, but with no annotations and no output schema, the description would benefit from noting the effect on already-off bulbs or the bulk-targeting behavior.

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 required 'target' parameter is fully documented in the schema (name, IP, or "all"). The description adds nothing beyond the schema, which is the expected baseline.

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 (turn off) and resource (WiZ bulbs), so the action is unambiguous. It does not distinguish itself from close siblings like turn_on or toggle, though the verb itself makes the distinction fairly obvious.

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?

No guidance on when to use this over alternatives such as toggle (which likely flips state) or turn_on. No prerequisites or context are provided, leaving the agent to infer selection rules.

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 provided, so the description carries the full burden of behavioral disclosure. It says 'turn on' but doesn't describe what happens with the optional brightness parameter (does it default to a previous value or full brightness?), whether targeting 'all' affects undiscovered bulbs, or any state side effects. For a mutation 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 efficient sentence with no waste. It's appropriately sized for a simple tool, though it doesn't front-load any usage constraints because it has none.

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 2-param mutation tool with no output schema, the description is minimally adequate but incomplete. It doesn't explain the effect of the optional brightness parameter or clarify behavior when targeting all bulbs, which an agent needs to invoke 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%, so the schema already fully documents both parameters (target with 'all' option, brightness range). The description adds no parameter semantics beyond what the schema provides. Baseline 3 is correct when 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?

States a specific verb (turn on) and resource (WiZ bulbs), and the plural 'one or more' distinguishes it slightly from a single-bulb operation. It doesn't explicitly differentiate from sibling turn_off or toggle, but the verb is clear. A 4 is appropriate since the purpose is unambiguous but lacks sibling routing.

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?

No when-to-use guidance, no mention of alternatives like turn_off or toggle. The description says nothing about when this is preferable over toggle, or about prerequisites like discovery. Implied usage only.

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