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

With no annotations provided, the description carries the full behavioral burden. It discloses the consolidated nature of the result, defines each returned field, and explicitly states that the tool never fails even when the TV responds partially. It also mentions reachable and stale_fields, giving agents important context about partial data. It does not explicitly claim to be side-effect-free, but the getter semantics make that evident.

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 opens with a one-line summary of what is returned, then gives the precise object shape and a key behavioral guarantee. Every sentence adds value, and the structure is front-loaded with the most important 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 getter with no inputs, this description is complete enough for an agent to select and invoke it correctly. It explains return fields, the meaning of each, the partial-response behavior, and the consolidated nature that differentiates it from siblings. The presence of an output schema also reduces the need for detailed return-value documentation.

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 has zero parameters, and the input schema covers 100% of the (empty) parameter surface. The baseline for a no-parameter tool is 4, as there is no parameter documentation burden for the description to carry.

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 ('État consolidé de la TV') and enumerates the exact fields returned: power, input, foreground_app, volume, muted, reachable, and stale_fields. This clearly distinguishes it from sibling tools that either set values (set_power, set_input, set_volume) or list discrete items (list_inputs, list_apps), making it the only tool that returns a consolidated snapshot.

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 clearly implies when to use this tool: whenever the current consolidated TV state is needed, including power status, active input, foreground app, volume, and mute. It does not explicitly state 'use list_inputs to enumerate inputs' or mention when not to use this tool, but the scope of sibling tools makes the intended context reasonably clear.

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 provided, the description carries the full disclosure burden and does so substantively: it reveals case-insensitive matching, the precise error contract (APP_NOT_FOUND plus an `available` list), and the return behavior (the consolidated state after the command). This is meaningful behavioral context far beyond a bare "launches an app." It does not address idempotency — what happens if the target app is already running — which would push it to a 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?

Four short sentences, each earning its place: purpose, input sourcing, error behavior, and return value. The purpose is front-loaded in the first sentence, and every sentence adds information absent from the schema. This is high-density prose with zero waste.

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 an output schema present, the description covers what the tool does, where the parameter comes from, what failures look like, and what is returned. The only notable gap is clarity around side effects (e.g., whether launching changes the active input, relevant given the set_input sibling) and behavior when the app is already active. These are minor against the tool's low complexity.

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%, so the lone `name` string parameter carries no documentation in the schema. The description fully compensates: the value must be an exact title from list_apps, matching is case-insensitive, and invalid values produce a known error with a recovery list. Nothing is left ambiguous about how to populate this parameter.

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 opening sentence, "Lance une application par son titre exact," names a specific verb (launch) and resource (application by exact title). This clearly separates launch_app from all siblings — set_power, set_input, list_apps, get_tv_state, etc. — none of which perform app launching. The tool name and description are coherent, giving an agent an unambiguous mental model.

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 establishes the key prerequisite: "Le titre doit être celui retourné par list_apps," telling the agent exactly where to obtain a valid value. It also prepares the agent for invalid input by specifying the APP_NOT_FOUND error and the `available` list it returns, enabling an implicit retry workflow. It stops short of a 5 because it never explicitly contrasts this tool with alternatives such as set_input for changing the active source.

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 of behavioral disclosure. It discloses caching for 6 hours, the refresh=true override, and the structure of entries (title and uri). This is strong transparency for a simple read-only listing tool, though it does not mention possible errors or edge cases.

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 tightly written in three short sentences, each earning its place: purpose, field semantics, and cache/refresh behavior. It is front-loaded with the core purpose and contains 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-optional-parameter tool, this description is fully sufficient: it explains what is returned, how to use the returned data, and the only parameter's behavior. The output schema is also present, so return-value details need not be repeated.

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%, so the description must compensate. It does: it explains what refresh=true does, the 6-hour cache default, and how the fields map to use with launch_app. This gives the agent more than the raw schema does.

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: listing applications installed on the TV, indexed by title. It also clarifies the data model (title vs. uri), making the tool's purpose unambiguous and easy to distinguish from the sibling tools like launch_app or list_inputs.

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 clearly tells the agent to use the returned 'title' together with launch_app, providing practical integration context. It does not explicitly say when not to use this tool or name alternatives, but the intended place in the workflow is clear enough.

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 present, the description carries the burden of behavioral disclosure. It discloses the deduplication behavior and explains the meaning of 'connected' and 'active', which helps the agent understand the returned data and infer read-only semantics. It does not explicitly state that the operation is read-only, but 'list' strongly implies it.

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 compact and front-loaded with the core purpose: listing deduplicated HDMI inputs. Every sentence adds value, and the final sentence provides cross-tool guidance without any 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 zero-parameter tool, the description is complete: it specifies the input source, deduplication behavior, all relevant output fields and their meaning, and how to chain the result into set_input. Nothing essential is missing for an agent to invoke and use this tool 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?

The tool has zero parameters, so the input schema provides nothing to clarify and the description does not need to explain parameter usage. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output fields instead.

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 the tool returns the TV's HDMI inputs, deduplicated by CEC/HDMI per port, and enumerates the exact fields returned. This clearly identifies the resource and distinguishes it from sibling list_apps, which would cover apps rather than HDMI inputs.

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 explicitly tells the agent to use the returned 'name' value with set_input, which is direct and actionable guidance for the intended workflow. It does not explicitly state when not to use this tool versus alternatives, but the HDMI-focused scope makes the primary use case clear.

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?

This description goes beyond the input schema by disclosing several important behaviors: the dependency on list_inputs, case-insensitivity, the exact error type and payload for unknown names, the side effect of waking the device via CEC, and the return of consolidated state. With no annotations provided, the description carries the full burden, and it does so thoroughly.

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?

Four short sentences, each carrying distinct information: the action, the source of valid values, error behavior, and side effects plus return value. It is front-loaded and free of redundancy.

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 with one string parameter, the description covers the source of valid values, error handling, side effects, and the return value. Combined with an output schema for the consolidated state, there are no significant gaps.

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 input schema only defines a string parameter `name` with no description, so coverage is 0%. The description compensates by explaining that the name must be exactly the one returned by list_inputs and that case is ignored. It doesn't provide examples or format details, but for a single simple parameter this is sufficient.

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 selects an HDMI input by its exact name, which is a specific verb-resource pairing. It does not explicitly contrast with sibling tools such as list_inputs or set_power, but the action is distinct enough that an agent can infer it is for input selection.

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 provides clear usage context: the name must come from list_inputs, case is ignored, and unknown names return INPUT_NOT_FOUND with an `available` list. It does not explicitly say when not to use this tool or name an alternative, but the exact-name requirement and error behavior give practical 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?

With no annotations, the description carries the full transparency burden. It explains the exact behavior for on=true and on=false and states that it returns the consolidated state after the command. This is good behavioral disclosure for a simple one-parameter tool, though it does not mention edge cases like idempotency or device power state.

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 two short sentences with no filler. The first sentence states the purpose, and the second explains the parameter and return behavior, front-loading the most essential 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 one-boolean-parameter tool with an output schema, the description is nearly complete: it explains purpose, parameter semantics, and the return value. It lacks explicit 'when to use' context, but that is a minor gap given how straightforward the tool is.

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 schema only defines a boolean named 'on' with no description coverage. The tool description compensates fully by explicitly stating that on=true cuts sound and on=false restores it, making the parameter's meaning unambiguous.

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 action: activating or deactivating mute mode, with a specific verb and resource. It is easily distinguishable from the sibling volume control tool, even though it does not explicitly name an 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?

The intended usage is implied by the verb and the boolean parameter: use this when you want to mute or unmute audio. However, there is no explicit guidance about when not to use it or how it differs from set_volume or set_power.

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 provided, the description carries full behavioral disclosure. It explicitly reveals that `on=true` falls back to Wake-on-LAN if the API is unreachable, `on=false` puts the TV into standby, and the response returns the consolidated state after the command. This is rich, useful behavioral context beyond the raw schema.

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 three short sentences with no filler. It front-loads the core action, then adds parameter semantics, and ends with the return behavior. Every sentence 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?

For a single-parameter tool with an output schema available, this description is complete: it covers the action, the parameter semantics, edge-case fallback behavior, and the response concept. Nothing critical is missing for an agent to select and invoke the tool 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 0%, so the description must compensate. It fully explains the single boolean parameter: `on=true` means power on with a WoL fallback, and `on=false` means standby. This meaning is completely absent from the schema, which only declares the type as boolean.

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 uses a specific verb and resource: 'Allume ou éteint la TV' (turns the TV on or off), making the tool's sole purpose unmistakable. It is clearly distinguished from siblings like set_input, set_volume, and set_mute by focusing on power state only.

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 clear usage: call this tool whenever the TV needs to be powered on or off, using the boolean `on` parameter. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous and no exclusions are needed given the tool's narrow scope.

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 behavioral disclosure burden, and it does well by revealing the client-side cap (40 by default), the exclusivity constraint, and that it returns consolidated state after the command. It does not mention persistence, permissions, or mute interaction, but these are less critical for a volume-setting 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?

Three compact sentences deliver all essential information with no filler. The parameter semantics are front-loaded, followed by the constraint, the cap, and the return behavior.

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 two-parameter tool with an output schema available, the description is complete: it explains both parameter choices, the one-of rule, the volume cap, and the return value. No critical information needed to invoke the tool correctly is missing.

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%, so the description must compensate, and it fully does: it explains that `level` sets an absolute value, `delta` makes a relative adjustment, and exactly one must be provided. This gives the agent actionable meaning beyond the raw schema defaults.

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 clear action ('Règle le volume') on a specific resource (volume) and immediately distinguishes the two operational modes: absolute (`level`) and relative (`delta`). This makes it easy to differentiate from sibling tools like set_mute or set_power.

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 explicit usage direction: use exactly one of `level` or `delta`, choosing based on whether an absolute value or a relative adjustment is needed. It does not explicitly compare itself to sibling tools, but the resource and behavior are distinct enough that the guidance is clear.

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