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

No annotations are present, so the description carries the full burden of disclosing behavior. It only restates the action and omits details such as what happens at the first channel, whether the change is relative to the current channel, prerequisites like a paired device, or whether state changes are reversible.

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 a single front-loaded sentence with no filler or repetition. Every word contributes to stating the action.

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 one-optional-parameter command, the description is minimally viable, but it lacks behavioral context such as boundary behavior and prerequisites. Without annotations or an output schema, a bit more context would make the tool easier 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 single optional device parameter is already fully documented. The description adds no parameter-specific detail, but none is needed beyond the schema, giving the baseline 3.

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 action ('switch to previous channel') with a clear resource target. It distinguishes from sibling channel_up by specifying direction ('previous'), and from set_channel by being a relative rather than absolute change.

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 is given on when to use this tool versus alternatives such as channel_up or set_channel. The intended use is only implied by the name and description, with no exclusions or context provided.

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 burden for disclosing side effects. It only states the core switching action and does not mention wrap-around behavior, ordering semantics, device-selection implications, or confirmation/return 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?

One short, front-loaded Japanese sentence with no filler. It is appropriately brief for such a simple action, though it sacrifices useful usage guidance for brevity.

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 no-annotation, no-output-schema action with only one optional parameter, the description is borderline sufficient but still thin: it doesn't state what 'next' means relative to the current channel, whether wrapping occurs, or how it differs from channel_down/set_channel. An agent choosing among the many channel siblings would need more context.

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% for the single optional device parameter, and the schema already explains the default resolution. The description adds nothing about device semantics, but it doesn't need to; 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 ('切り替える' – switch) and resource ('チャンネル' – channel), and the qualifier '次の' distinguishes it from channel_down (previous channel) and set_channel (specific channel). It doesn't explicitly name sibling alternatives, so it falls just short of the strongest standard.

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 mention of when to use channel_up versus channel_down or set_channel. It provides no exclusions, prerequisites, or routing context, so an agent must infer usage from the name and the word 'next'.

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 behavioral transparency burden. It discloses only the core action (app termination) and omits potential side effects, reversibility, confirmation, or what happens to app state. This is minimal for a state-changing operation.

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 a single efficient sentence with no filler or redundancy. It is well-structured and front-loaded, though it does not carry much explanatory content.

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-parameter tool with full schema coverage, the core action is stated and parameter constraints are provided by the schema. However, with no annotations or output schema, an agent still lacks guidance on behavioral expectations and when to choose this tool, leaving the definition minimally adequate.

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 both appId and device are already documented in the schema, including the default-device resolution for device. The description adds no extra parameter semantics, 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?

The description '指定したアプリを終了する。' uses a specific verb (終了する/terminate) and a specific resource (specified app). This clearly states the tool's function and distinguishes it from sibling tools such as launch_app and get_current_app.

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 close_app versus alternatives, nor any conditions, prerequisites, or exclusions. An agent must infer use from the name and 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 present, so the description carries the behavioral disclosure burden. It clearly identifies the destructive effect and precondition, but it does not describe behavior when no text field is focused, when the field is empty, or when count exceeds available characters.

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, direct Japanese sentence that front-loads the operation and context with no filler or 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 simple optional-parameter command with no output schema, the description and schema together cover normal usage well. Minor gaps remain around edge/failure cases, but an agent can select and invoke the tool correctly with confidence.

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 both count and device are already documented in the schema. The description adds directional context (cursor-before) but does not add meaning beyond the parameter definitions.

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 the exact operation (削除する), target (カーソル前の文字), and required context (フォーカス中のテキストフィールド). This clearly distinguishes it from siblings like insert_text and send_key.

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 text-editing usage via 'focused text field' and 'cursor', but it does not explicitly state when to prefer this over alternatives such as send_key for backspace-like behavior or insert_text. No exclusions or when-not-to-use guidance is provided.

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 and openWorldHint, and the description adds network-specific behavior (SSDP discovery) and the concrete output fields. It is consistent with the annotations and gives an agent a clear read-only model of the operation.

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 packs in the target, method, and return fields without filler. Every phrase 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 simple optional-parameter discovery tool, the description covers what it does and what it returns, and the schema covers the timeout. It does not explicitly mention latency or the relationship to list_devices, but nothing required to invoke it 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?

All parameter details live in the schema (timeoutMs range, default, description), and the tool description does not add anything about parameters. With 100% schema coverage, the baseline of 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?

The description clearly states a specific action — discovering LG webOS TVs on the LAN via SSDP — and identifies the returned data (IP, name, model). It does not explicitly contrast this with list_devices or other siblings, so it stops short of full 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?

The use context is implied by the protocol and target: an agent can infer this is for scanning the LAN for unlisted TVs. There is no explicit statement about when to use discover_devices instead of list_devices, nor when not to use it.

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?

The readOnlyHint annotation already covers the safety profileessed by the tool. The description clarifies that it returns an app ID, but does not disclose extra behavioral details such as output format or behavior when no foreground app exists.

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 one compact, front-loaded sentence with no filler or redundant phrasing. 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?

For a simple read-only tool with one fully documented optional parameter and no output schema, the description is complete: it states what is returned and the annotations convey that it is non-destructive.

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 description adds no parameter-specific information, but the input schema fully documents the single optional 'device' parameter, including its default behavior. With 100% schema coverage, the baseline of 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?

The description uses a specific verb ('返す' / returns) and a precise resource: the ID of the app currently shown in the foreground. This clearly distinguishes it from sibling tools like list_apps, launch_app, and get_current_channel.

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 when to use the tool: when the current foreground app's ID is needed. However, it does not explicitly mention alternatives or conditions for choosing this over list_apps or get_current_channel.

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?

The readOnlyHint annotation already establishes that the operation is safe and non-mutating. The description adds useful context about what information is returned and the fallback behavior when not watching broadcast, but it does not disclose potential error conditions (e.g., device not found) or any side effects, which are minimal given the read-only nature.

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 a single, well-structured sentence that front-loads the primary return value (channel and program) and states the conditional behavior. It is concise and information-dense with no wasted words.

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 read-only tool with one optional parameter and no output schema, the description adequately covers the expected return values and the edge case of not watching broadcast. It does not describe the exact response format, but given the low complexity and readOnlyHint, this is not a significant gap.

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 description covers 100% of the single parameter (device), so the schema already documents its meaning and default behavior. The description adds no additional parameter-level detail beyond what the schema provides, so the baseline score of 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?

The description clearly states the tool returns the current channel and the airing program's name, content, and start/end times. It also specifies the behavior when not watching broadcast. While it doesn't explicitly differentiate from siblings like get_current_app, the focus on channel/program is distinct enough for an agent to infer its purpose.

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 usage for retrieving current viewing status but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_current_app or get_program_guide. An agent would need to infer the appropriate context from the tool's name and description.

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, so the read-only nature is known. The description adds value by disclosing the behavior when the TV is in standby and unresponsive (returns that fact), and by enumerating possible states. This goes beyond the annotation and informs the agent of an edge case that affects output interpretation.

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 a single concise sentence that front-loads the main function and includes the essential edge case. Every word earns its place; there is no redundant or vague 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 simple read-only tool with one optional parameter, the description covers the core behavior, example values, and the standby-response edge case. The lack of an output schema is acceptable since the description gives examples. It does not specify the exact return format (e.g., JSON vs plain string), but that is minor given the tool's simplicity.

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 only parameter (device) is fully described in the schema (coverage 100%), so the schema carries the semantic load. The description adds no additional context about the parameter, such as default resolution or format. With full schema coverage, the baseline of 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?

The description states a specific verb ('返す' – returns) and resource ('TVの電源状態' – TV power state), and lists concrete example values (Active, Active Standby, Screen Off). This clearly distinguishes it from sibling tools like power_on/power_off which change state, and from get_system_info which is broader. The purpose is 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?

The description implies its use for querying power state but does not explicitly state when to use it over alternatives. For example, it does not mention 'use this to check if the TV is on before sending commands' or contrast with get_system_info. The context of siblings makes it obvious for a human, but the description itself gives no explicit when/when-not 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?

Annotations provide readOnlyHint=true, and the description adds useful behavioral context beyond that: it returns the list of upcoming programs and, crucially, returns a message if the user is not currently watching a broadcast. This edge-case disclosure is valuable and does not contradict the annotation.

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 primary function is front-loaded, and the conditional edge case is given in the second sentence. 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?

For a simple read-only tool with one optional parameter and no output schema, the description is complete: it states what is returned (upcoming program list)and the relevant edge case(not watching broadcast).No essential behavior 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?

The input schema already documents the optional device parameter with 100% coverage. The description adds no additional parameter-specific meaning, so the baseline of 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 clearly states the verb '返す' and the resource '視聴中チャンネルの番組表' (program guide of the currently viewing channel), which distinguishes it from sibling tools like list_channels or get_current_channel. It also defines the exact scope: upcoming programs for the channel being watched.

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 clear context for when to use the tool: when a program guide for the currently watching channel is needed. It also explains the behavior when not watching a broadcast. However, it does not explicitly name alternatives or state when not to use it, so it stops 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?

Annotations already declare readOnlyHint=true, and the description's '取得' is consistent. The description adds some context about valid key sets per category but no further behavioral caveats such as auth requirements, return shape, or side effects. It stays within the safety profile already conveyed by annotations.

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 a single sentence followed by a compact example. It front-loads the main action and contains no filler or redundant 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 3-parameter read-only getter with full schema coverage, the description is mostly complete. However, it never mentions set_settings as the write alternative and does not hint at the return structure (no output schema exists). These minor gaps prevent a perfect score.

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 baseline is 3. The description adds a valuable mapping between category values and valid keys (picture vs sound), showing how the required parameters interact. This goes beyond the schema's simple property descriptions.

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 specific verb '取得する' (retrieve) and resource 'システム設定' (system settings), then gives concrete category/keys examples. This clearly distinguishes it from the sibling set_settings, which would be the write counterpart.

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 usage through examples (e.g., category=picture keys=[brightness,contrast,backlight,color,pictureMode]) but does not explicitly state when to use this tool versus alternatives like set_settings, nor any exclusions. Usage context is present but not fully elaborated.

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?

The annotation readOnlyHint=true already declares this as a safe read operation, lowering the bar for the description. The description adds the list of possible output values, which is useful context but does not go beyond that—no mention of failure modes, permissions, or side effects. Given the annotations, this is adequate.

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 a single concise sentence that front-loads the primary purpose and includes practical examples. There is 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?

For a simple getter with no required parameters, a read-only annotation, and no output schema, the description is largely complete. It explains what is returned and gives examples, though it does not explicitly state the return type (e.g., string) or error behavior. These are minor gaps given the tool's simplicity.

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 'device' parameter is fully documented in the schema. The description does not add any additional meaning about the parameter, and it is optional. Per the rubric, baseline 3 applies when the 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?

The description clearly states the tool returns the current audio output destination, listing concrete examples like tv_speaker and external_optical. This is a specific verb-resource pair that distinguishes it from set_sound_output, which is a sibling. The purpose is unambiguous and easy for an agent to act on.

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: this is the read counterpart to set_sound_output. However, there is no explicit guidance about when to prefer this over alternatives or any exclusion criteria. For a simple getter, the context is clear, but it does not state when not to use it or mention the sibling as an alternative.

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?

The readOnlyHint annotation already communicates that this is a safe read operation. The description adds useful scope by naming model name and webOS version, but it does not disclose any behavioral details beyond that, such as return shape or device-connectivity 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?

A single concise sentence that front-loads the core purpose with no filler. Every word contributes to describing what the tool returns.

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 read-only system-info tool with one fully documented optional parameterable parameter and a readOnlyHint, the description is largely sufficient. The only gap is the vague trailing '等' (etc.), which leaves the full set of return fields unspecified.

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% for the single optional device parameter, so the schema fully documents its meaning and default resolution. The description adds no parameter-level information, which is acceptable at this coverage level.

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: it returns the TV model name and webOS version. This clearly differentiates it from the many sibling control and query tools, even without naming 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?

No guidance is given about when to use this tool versus siblings like get_settings or get_power_state. The description only states what the tool returns, leaving the selection criteria entirely 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?

The readOnlyHint annotation already covers the safety profile, and the description adds that it reports both volume and mute state. However, it does not disclose return format, default-device behavior, or failure cases, though for a simple read operation this is not a major 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?

The description is a single concise sentence with no filler. It front-loads the action and directly states what is returned.

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 read-only tool with one optional documented parameter, the description is sufficient for an agent to invoke it correctly. The lack of an output schema leaves the exact return structure unspecified, but the described content is clear enough for this use case.

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 single optional device parameter is fully described in the input schema (100% coverage), including its default resolution behavior. The description adds no additional parameter context, so the baseline score of 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 clearly states the operation ('返す') and the resource ('現在の音量とミュート状態'), making it unambiguous that this is a read-only query for volume and mute status. It is also naturally distinguishable from sibling mutation tools like set_volume, mute, and volume_up/down.

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 retrieving current state rather than changing it, but it does not explicitly say when to use it over alternatives or mention any exclusions. The sibling names provide context, but the description itself offers no direct usage 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 burden. It discloses a failure condition (no input field displayed), the default append behavior via replace=false, and the enter behavior. However, it does not mention whether the operation is reversible, whether it clears existing text by default, or what happens on failure. The replace parameter is described in the schema, so the description adds only the failure condition and enter 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?

The description is two sentences, front-loads the core action and failure condition, and includes the enter behavior. Every sentence earns its place with no 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 4 parameters, 100% schema coverage, and no output schema, the description covers the essential behavior, failure condition, and the enter option. It could mention the default append behavior more explicitly, but the schema already covers replace. The main missing context is what happens when the input field is not focused, but the description already states it fails.

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 all four parameters. The description adds context for enter (confirm after input) and replace (replace vs append), but these are also in the schema. The description does not add meaning beyond the schema, 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?

The description clearly states the action (input text into the focused text field on TV), the target resource (focused text field such as search box), and a key failure condition (fails if input field is not displayed). It is distinct from siblings like delete_text and send_key.

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 when to use it: when a text field is focused on the TV. It also states a precondition (input field must be displayed) and mentions the enter option for confirming input. It does not explicitly contrast with delete_text or send_key, but the context 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It states that the tool launches an app and can pass parameters, which is the core behavior. However, it doesn't disclose side effects (e.g., whether launching an app switches input, whether it brings the app to foreground, whether it requires the device to be powered on, or what happens if the app is already running). For a launch operation, these are meaningful behavioral traits that an agent might need to know.

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 a single, compact sentence in Japanese that front-loads the core action and app ID examples, then mentions the optional parameter capability. Every word earns its place; there is no fluff or repetition of schema details.

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 has 3 parameters, one required, and a nested object for params. The schema covers all parameters, and the description provides examples. However, there is no output schema, and the description doesn't mention what the tool returns (e.g., success/failure, launched app info). For a launch action, an agent might want to know if it returns a status or error. Given the moderate complexity and lack of annotations, a 3 is fair.

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 all three parameters (appId, device, params). The description adds a concrete example of appId values and clarifies that params are optional ('任意で'). It also explains the device parameter's default resolution in the schema itself. The description doesn't add much beyond the schema, but the schema is already thorough, 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?

The description clearly states the verb (起動する = launch), the resource (アプリ = app), and provides concrete examples of app IDs (netflix, youtube.leanback.v4, com.webos.app.hdmi1). It also mentions optional launch parameters, distinguishing it from sibling tools like close_app, list_apps, and get_current_app. The title 'アプリ起動' reinforces the purpose without being a mere tautology.

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 when to use this tool: when you need to launch an app by its ID. It doesn't explicitly state when not to use it or name alternatives, but the sibling list includes close_app, list_apps, get_current_app, and open_url, which are clearly different operations. The context is clear enough for an agent to select this tool for launching apps, though explicit exclusions would push it to 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?

The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds no further behavioral disclosure such as output format, pagination, or handling of hidden apps, but it is consistent with the annotation and sufficient for a simple list operation.

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, front-loads the primary purpose, and includes only useful downstream information. Every sentence earns its place with no 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 simple read-only listing tool with fully documented optional parameters, the description is largely complete. It explains what is returned (IDs and titles) and how the result is used. A minor gap is the absence of an explicit statement that the result is a list, but this is implied.

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 fully documents the device and includeHidden parameters. The description adds no additional parameter semantics beyond the schema, so the baseline score of 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?

The description is specific: it returns the IDs and titles of apps installed on the TV, and it explicitly connects the returned id to launch_app. This clearly distinguishes the tool's purpose from sibling tools like list_channels or get_current_app.

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 downstream usage guidance by stating that the returned id should be passed to launch_app. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when to call this tool.

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?

The readOnlyHint annotation already covers safety, and the description adds that it returns receivable channels and that the output can feed into set_channel. It does not disclose return shape, ordering, or how includeSkipped affects results, but the annotation lowers the bar for behavioral disclosure.

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 sentences, front-loaded with the core purpose and filtering capability. The second sentence about set_channel adds useful downstream context, though it is slightly tangential to the tool's own invocation.

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 read-only listing tool with fully documented optional parameters, the description is adequate. It lacks an explicit description of the return format and does not mention query or includeSkipped, but those are covered in the schema and the readOnlyHint annotation covers safety.

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 documents type, query, device, and includeSkipped. The description adds broadcast type examples, but these largely duplicate the schema's own examples and do not compensate for missing context on the other parameters.

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 returns a list of receivable channels and that the type parameter filters by broadcast type, with concrete examples. However, it does not explicitly distinguish this from sibling tools like get_current_channel or get_program_guide, though the word '一覧' implies enumeration.

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 this tool is for listing and filtering channels and notes set_channel can accept identifiers from the list. However, it does not explicitly state when to prefer this tool over alternatives such as get_current_channel or get_program_guide, nor mention exclusions.

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, so the agent knows this is a safe read operation. The description adds that it reads from devices.json and includes the default device, which is useful context. It doesn't disclose return format or whether the list is ordered, but for a simple read-only list tool, the annotation plus description is adequate.

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 sentence, front-loaded with the resource and action. No wasted words. It conveys the essential information efficiently.

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, the description is nearly complete. It states the data source and the inclusion of the default device. The only minor gap is not describing the return format (e.g., array of device objects), but with no output schema and simple semantics, this is a small 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?

The tool has zero parameters, so the schema is trivially complete. The description adds meaning by specifying the data source (devices.json) and that the default device is included. With no parameters, the baseline is 4, and the description provides useful context about what the returned list contains.

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 ('返す' = returns) and a clear resource: devices stored in devices.json plus the default device. It distinguishes itself from sibling tools like discover_devices, pair_device, and remove_device, which are about discovery, pairing, and removal rather than listing. However, it doesn't explicitly name a sibling alternative, so it doesn't fully differentiate from list_apps or other list tools, though the resource is clear.

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 usage: call this when you need the list of registered devices and the default device. It doesn't explicitly state when not to use it or mention alternatives like discover_devices for finding new devices. The context is clear enough for an agent to infer, but there is no explicit routing 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by specifying exactly what is returned (ID, label, connection status) and how the result interacts with switch_input. It does not mention error conditions or response format, but for a simple read-only list tool the annotation plus return-field disclosure is sufficient.

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 a single compact sentence that front-loads the core purpose and then immediately provides a practical usage hint. Every word earns its place; there is no redundant or verbose content.

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 read-only list tool with one optional parameter fully covered by the schema and no output schema, the description is complete. It names the returned fields and explains how the returned ID is consumed by switch_input, giving the agent everything needed to call and use the result 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 single optional device parameter is already fully documented in the schema. The description adds no extra meaning about the parameter, which is acceptable given the high coverage and baseline of 3.

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: it returns the ID, label, and connection status of external inputs such as HDMI. It also distinguishes itself from siblings by explicitly linking the returned ID to switch_input, leaving no ambiguity about what the tool is for.

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 this tool to obtain an ID for switch_input, providing a concrete usage context. It does not explicitly list alternatives or exclusions, but the switch_input reference is strong implicit guidance for when this tool is relevant.

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. It does disclose a key trait: commands are best-effort and may be ignored by unsupported apps. However, it does not describe result reporting, failure handling, or side effects; the coverage is adequate but not rich.

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 short sentences with no redundancy: the first fronts the command set, the second adds a practically important caveat. Every sentence contributes signal.

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 command tool, the description plus fully covered schema is nearly sufficient. It includes the main caveat (app support), and the only notable gap is response/error behavior, which is minor for this 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?

Schema description coverage is 100%, so the baseline is 3. The description restates the enum actions in prose but adds little beyond the schema; the device parameter's default behavior is already fully explained in 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?

The description states a specific action ('sends play/pause/stop/rewind/fast-forward') and a clear resource (media control). This distinguishes it from siblings like volume, input, and app controls, even without naming 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 intended use is clear: use this tool when playback transport commands need to be sent. It also warns that some apps may not support the commands, which gives practical context, though it does not explicitly name alternatives or exclusion cases.

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 discloses the key behavioral trait: omitting the 'mute' parameter causes a toggle, while supplying true/false sets the state. However, it says nothing about side effects (e.g., volume restoration on unmute), failure modes, or what happens when the device is unreachable.

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 terse sentences, front-loaded with the primary action and immediately followed by the critical toggle clarification. Every word earns its place with no redundancy or 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 simple tool with two optional parameters and no annotations or output schema, the description covers the core invocation behavior. However, with no output schema, the agent is left uninformed about return values, and no error/offline device behavior is mentioned, leaving some gaps for a control-plane 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?

Schema description coverage is 100%, so both parameters (mute and device) are already documented in the schema, including the omission defaults. The description adds only marginal value by restating the toggle behavior already present in the schema's mute parameter description, which is the baseline expectation.

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 action ('ミュートを ON/OFF する') on a specific resource (mute), clearly differentiating this from the sibling tools (power, channel, volume, etc.). It also clarifies the toggle-vs-set duality, leaving no ambiguity about what the tool accomplishes.

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 implied: use this tool when the user wants to mute, unmute, or toggle mute. However, it does not explicitly mention when to prefer this over alternatives, nor any exclusions such as devices that do not support muting. No and-when-not guidance is provided.

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 present, so the description carries the behavioral burden. It states the core action—opening the URL in the TV browser—but does not disclose side effects, prerequisites, success/error behavior, or whether the browser is launched vs. navigated to. This is adequate but not rich.

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 that states the action without filler. The key location ('TV のブラウザ') and action are front-loaded, and no sentence is wasted.

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?

This is a simple two-parameter action with no nested objects and no output schema; the description plus complete schema is sufficient for a correct call. It lacks only optional behavioral detail such as return/error semantics, which is not critical for this simple action.

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%: both url and device are already documented with format and default-device resolution details. The description adds no parameter-level meaning, so the baseline of 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 uses a specific verb ('開く' - open), a concrete resource (URL), and a scoped target (TV's browser), which clearly sets it apart from sibling tools like launch_app or send_key. It is not a tautology: it adds the TV context beyond the title.

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 makes the intended use clear: when the task is to open a URL in the TV's browser. It does not name alternatives or exclusions, but the purpose is specific enough that an agent can reliably route to this tool.

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 must carry behavioral disclosure. It usefully describes the interactive approval dialog and the saving of client-key, but it does not disclose what happens if the user rejects, whether the operation can block indefinitely, or whether existing pairings are overwritten.

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 a single dense sentence with no filler and front-loads the core action. Its length is reasonable, though splitting the wait/approval detail into a separate sentence would improve scannability.

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 description covers the essential interaction (user must approve on the TV) and the outcome (client-key saved). It omits return value, timeout/rejection behavior, and prerequisites, which matters because there is no output schema or annotations to fill those 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?

Schema description coverage is 100%, so the schema already documents host, name, and makeDefault. The tool description adds general context about client-key storage but no per-parameter meaning beyond the schema, 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?

The description states a specific action: connect to a TV at a given IP, pair it, wait for user approval, and save the client-key. This clearly distinguishes pair_device from sibling tools like list_devices or remove_device, which manage already-known devices.

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 described workflow ('connect to the TV at the specified IP and pair') implies when to use it but does not state prerequisites such as discovering the TV first or exclude alternatives such as remove_device or set_default_device. No explicit when/when-not guidance is provided.

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 destructiveHint=true, so the description is partially relieved of that burden. It adds the nuance that 'power off' means entering standby rather than cutting power entirely, which is useful. However, it does not disclose other potential behaviors such as whether a pairing/session is lost or if further commands become unavailable.

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 a single, tight sentence with no filler. The action is front-loaded and every character earns its place, making it highly efficient for such a simple command.

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 low-complexity tool with a fully documented schema and a destructive annotation, the description is nearly complete. It could strengthen completeness by explicitly stating that the tool is idempotent or that standby differs from hard power-off, but those are minor omissions given the simple nature of the action.

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 only parameter, device, has 100% schema description coverage, including its default resolution order. The description adds no additional meaning to this parameter, so a 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?

The Japanese description 'TV の電源を切る（スタンバイ）' clearly states the action: turning off the TV and putting it in standby. This is a specific verb-resource pairing that unambiguously distinguishes it from the sibling tool power_on.

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 offers no guidance on when to use this tool versus alternatives like power_on or get_power_state. While the context of siblings implies usage, the description itself provides none, leaving it to the agent to infer.

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 behavioral burden. It discloses the WOL mechanism, the dependency on a MAC saved during pairing, and a prerequisite TV setting. It could mention failure/error behavior, but the key behavioral traits are described.

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, dense sentences with no filler. The purpose is front-loaded, followed by the MAC behavior and the TV-side prerequisite. Every sentence contributes useful 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 simple power-on tool with no output schema, the description covers the purpose, prerequisite, and parameter behavior. It does not describe error cases such as an unreachable TV, but the core invocation context is adequately specified.

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%, so the baseline is 3. The description adds extra meaning by explaining that the MAC was saved during pair_device and that the mac parameter overrides that saved value. This goes beyond the schema's '登録済みの値' phrasing.

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 a specific action ('TV の電源を入れる') and the mechanism (Wake-on-LAN), with the resource being the TV. This differentiates it from related siblings like power_off and get_power_state, so an agent can immediately tell what this tool does.

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?

It provides clear context: powering on via WOL, using the MAC stored during pair_device, and allowing an override. It also states the required TV-side setting. It does not explicitly compare alternatives, but the intended use case is clear enough given the sibling names.

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?

The annotations already declare destructiveHint=true, lowering the burden on the description. The description adds useful context by specifying that the deletion includes the client-key, clarifying exactly what is destroyed. It does not discuss irreversibility or permissions, but the annotation already signals destructive 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?

The description is a single sentence with no filler. It front-loads the action and target while including the key detail about the client-key, making it appropriately concise.

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 one-parameter destructive tool, the description, schema, and annotation together provide enough information to invoke it correctly. It would benefit from noting irreversibility or return behavior, but given the low complexity and presence of destructiveHint, the current completeness is adequate.

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 provides 100% coverage of the single required 'name' parameter with the description '削除するデバイス名'. The tool description does not add further parameter-level detail, so it relies on the schema, which is already 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 uses a specific verb '削除する' (delete) with a clear resource, '保存済みのデバイス' (saved device), and adds that the client-key is included. This distinguishes it from siblings like list_devices, pair_device, and discover_devices, which serve different purposes.

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 usage for removing saved device registrations, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Sibling tools such as pair_device or list_devices are not referenced, so the routing is left 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?

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: DRM-protected content (Netflix/Prime Video) appears black. It also discloses the image resolution and format, which is not present in the structured metadata.

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 core action and output format, followed by use case and DRM caveat. Every sentence earns its place without repeating schema content.

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 read-only capture tool with one optional parameter, the description plus annotation is sufficient. It includes return format, intended usage, and a known limitation, so an agent has everything needed to call it 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 optional device parameter is already well documented in the schema, so the description does not need to add parameter detail. Baseline 3 is appropriate because the description contributes no additional parameter semantics.

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 ('TV画面のスクリーンショット') and even specifies the output format (960x540 JPEG). This makes the tool's function unmistakable and distinct from the sibling tools, none of which offer screen capture.

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?

Explicitly describes the intended use case: check the current display before operating on the TV. It does not name alternative tools or state exclusions, but the guidance is clear enough for an agent to know when to invoke this tool.

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. It does add one useful behavioral fact—multiple keys are sent sequentially—and lists acceptable keys. However, it says nothing about return values, error conditions, permissions, or what side effects occur on the target device.

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 one dense, front-loaded sentence followed by the key list. There is no filler, and the long key enumeration is necessary input vocabulary rather than unnecessary verbosity.

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 send operation, the key input and device defaulting are covered adequately. However, with no annotations and no output schema, the description leaves operational ambiguity around expected responses, failure behavior, and when to prefer a sibling tool such as media_control.

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 describes the keys parameter with examples, while the description enumerates the complete set of valid key names and explains that arrays are sent in order. That is meaningful semantic value beyond the structured schema. The device parameter is already fully documented in 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?

The description clearly states the action: send remote control button operations, and it enumerates the exact key vocabulary an agent can use. This makes it easy to tell apart from mouse or text-input siblings, though it does not explicitly name those alternatives.

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 about when to use this tool versus siblings like send_mouse, media_control, or insert_text. The key list implies remote-button scenarios, but no exclusions, alternatives, or decision criteria are provided.

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 burden and does add key behavioral details: move is relative, the coordinate scale is defined (1920x1080, twice screenshot coordinates), and a workaround for absolute positioning is shown with an example. It stops short of describing click/scroll side effects, but the core behavior is transparent.

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 dense Japanese sentences with no filler: the core operation, coordinate semantics, an absolute-positioning trick, and a practical use case. Every sentence earns its place and the most important information is front-loaded.

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 four-parameter tool with no output schema and no annotations, the description is complete enough: it covers the action enum behavior, coordinate system, absolute positioning, and a triggering scenario. The remaining details are already present in the input schema.

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%, so the baseline is 3, but the description adds meaning beyond the schema by explaining that dx/dy are relative movements and providing the coordinate conversion and absolute-positioning example. This materially helps the agent use dx/dy correctly.

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?

Description states a specific verb and resource: 'TV のマウスポインタを操作する' and covers move, click, and scroll via action enum. It clearly differentiates from sibling keyboard/text tools like send_key and insert_text by describing mouse-specific behavior and the virtual-keyboard use case.

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 a clear use case: 'ブラウザ等でテキスト欄をクリックして仮想キーボードを出すときに使う' and explains the relative-move behavior needed for absolute positioning. It does not explicitly state when not to use alternatives, but the context is explicit enough for selecting this tool.

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 burden of behavioral disclosure. It does explain the main effect, accepted channel identifiers, and the automatic switching behavior, but it omits side effects, error conditions, or what happens if the requested channel 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?

The description is short and front-loaded with the core verb, followed by relevant examples. Every sentence adds useful information, though it could be slightly more structured by separating input semantics from behavioral notes.

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-parameter tool with no output schema, the description covers the essential invocation details. However, it lacks usage exclusions and edge-case behavior (e.g., already on the requested channel, device not powered on), and the large sibling set makes the absence of usage guidance more noticeable.

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 already covers both parameters (100% coverage), so the baseline is 3. The description adds real value by giving concrete examples of valid channel values (011, 41, NHK総合, テレ東) and clarifying that channelId is also accepted, which goes beyond the schema's terse '番号 / 局名 / channelId'.

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 verb and resource: 'チャンネルを切り替える' (switch channels) and specifies the accepted channel forms (number, station name, channelId). It does not explicitly contrast itself with sibling tools like channel_up/channel_down or watch_tv, so it falls just short of full 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?

No guidance is given about when to use this tool instead of alternatives. The note about automatically switching when not viewing broadcast hints at behavior, but it does not tell the agent when to prefer set_channel over channel_up, channel_down, or watch_tv.

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 disclosing behavior. It only says 'sets' a default, implying a mutation, but it does not reveal whether the change is persistent, whether the device must be already known/paired, or any side effects. This lack of behavioral detail is a significant gap for a state-changing 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?

The description is a single, compact sentence that states the purpose without any redundant information. Every word contributes to understanding the tool, making it highly efficient.

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 setter with one parameter and no output schema, the description provides the core purpose. However, with no annotations, it omits important operational context such as prerequisites (e.g., device must be discovered), persistence of the setting, or error behavior, leaving some gaps for an agent to infer.

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 has 100% description coverage (the 'name' parameter is described as 'デバイス名'). The description adds the contextual meaning of this being the default for omitted parameters, but it does not add substantial detail beyond what the schema already states. 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?

The description clearly states the tool's function: setting the device to be used when the 'device' parameter is omitted. It uses a specific verb ('set') and resource ('default device'), and the scope is distinct from sibling tools like list_devices, pair_device, or remove_device, making it easily distinguishable.

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 clear context: it is for configuring the fallback device when the 'device' parameter is not supplied. However, it does not explicitly exclude alternative tools or mention when not to use it, so it stops short of a full 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?

With no annotations, the description carries the behavioral burden. It discloses that the operation changes settings and can return 401 without WRITE_SETTINGS permission, which is useful context. However, it does not explain side effects, whether changes are immediate/reversible, or what happens for invalid keys.

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 short, front-loaded with the purpose, and every sentence earns its place: purpose, example, and permission caveat. It is concise without being minimal to the point of uselessness.

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?

Given there is no output schema and no annotations, the description provides a usable overview, example, and an error condition. Still, it omits how to discover valid categories, what the return/response looks like, and whether the device parameter should usually be specified.

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%, so the baseline is 3. The description adds value with a concrete example ('category=picture settings={backlight: 60}') that illustrates how the category and settings parameters relate, going slightly beyond the generic schema descriptions.

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 changes system settings ('システム設定を変更する') and includes a concrete example with category and settings. It is distinct from get_settings but does not explicitly differentiate itself from other sibling mutators like set_volume.

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 usage by stating what it does and giving an example, but it offers no explicit when-to-use guidance, conditions, or alternatives. It does mention a firmware-dependent permission failure, but not how to choose this tool over siblings.

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 only says the output destination is switched; it does not mention whether the change persists, whether a specific device must be reachable, what happens with invalid output IDs, or whether there are side effects on currently playing media.

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 one front-loaded sentence with no filler or extraneous detail. It is appropriately sized for a simple operation, though it does largely restate the title's core concept.

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 low-complexity and both parameters are fully described in the schema, so an agent can construct a valid invocation using the structured data alone. However, the lack of an output schema and any behavioral/usage context leaves gaps around result expectations and error handling, making the overall context only adequate rather than 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 description coverage is 100%; the output property lists concrete example values and the device property documents default-device fallback behavior. The description adds no parameter-level meaning, so it correctly lands at the baseline 3 rather than compensating for any schema gaps.

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 concrete action and resource: '音声出力先を切り替える' (switch the audio output destination). This makes the tool's intent clear and distinguishes it from read-style siblings like get_sound_output, though it does not explicitly name or contrast those siblings.

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 about when to use this tool versus alternatives such as get_sound_output, set_default_device, list_devices, or the discovery commands. No prerequisites, sequencing, or exclusions are mentioned, so the agent must infer usage from the tool name and schema alone.

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 present, so the description carries the full burden. It only repeats the basic action without disclosing side effects (e.g., persistence, device selection behavior, failure handling, or interaction with mute). This is minimal disclosure, just a restatement of the tool name with a range.

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 a single short sentence with zero wasted words. It is front-loaded with the core action and range, and there is no unnecessary elaboration.

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 tool with no output schema and no annotations, the description is incomplete. It fails to explain when to choose this over relative volume controls, what happens with device selection, or whether the change is permanent. Given the sibling tools, an agent lacks critical context for correct invocation.

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% for both parameters, so the baseline is 3. The description does not add any extra meaning beyond the schema; it merely echoes the volume range. It doesn't clarify the device parameter or provide format details, but the schema already covers it.

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 verb 'set' and the resource 'volume' with an explicit range (0-100), which clearly differentiates it from siblings like volume_up, volume_down, and get_volume. Even though it's terse, the action and target 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?

No guidance is provided on when to use this tool versus alternatives. With siblings such as volume_up, volume_down, and mute, an agent is left to infer that this sets an absolute value, but the description never explicitly states that or mentions exclusions.

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 of behavioral disclosure. It only says 'displays a toast on TV screen' and offers no information on side effects, duration, whether the TV must be on, or any authentication requirements. This is a minimal statement without additional behavioral context.

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 a single, concise sentence that communicates the core function without any wasted words. It is front-loaded with the action and resource, making it immediately understandable.

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 with only two parameters, both fully described in the schema, and the purpose is clear. However, there is no mention of behavioral context, return behavior, or usage caveats. Since no output schema exists and annotations are absent, a bit more detail about expected behavior would make it complete – though the current level is adequate for basic invocation.

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% (both device and message have descriptions, including constraints like maxLength=200). The description itself adds no parameter-level detail beyond the schema, so the baseline score of 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 states a specific verb ('表示する' – display) and a clear resource ('TV 画面にトースト通知' – toast notification on TV screen). It precisely identifies the tool's function and is distinct from all sibling tools, none of which involve toasts.

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 is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is purely a single functional statement and does not help an agent decide between show_toast and other display-related tools.

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 must disclose behavior, but it only states the action. It does not explain effects on device state, error handling for invalid input IDs, or conditions like the device being powered on.

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 a single, concise sentence that is easy to parse. It is appropriately front-loaded, though it could include a bit more context without losing conciseness.

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?

Given the lack of annotations and output schema, the description is incomplete. It does not mention success/failure behavior, how to verify the switch, or explicitly instruct to obtain inputId from list_inputs (though the schema hints at it).

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 description adds no extra meaning beyond the schema's parameter descriptions. The example clarifies the format of inputId but that is already covered by the schema's reference to list_inputs.

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 ('switch') and resource ('external input') with concrete examples (HDMI_1, HDMI_2), making the tool's purpose clear. It does not explicitly contrast with siblings like list_inputs or set_channel, but the resource type is 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?

No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing to call list_inputs first, nor any exclusions for other input-switching tools.

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 states the action (lower volume by one step) but does not mention side effects, reversibility, or any state changes beyond the immediate adjustment. For a simple mutation tool, this is acceptable but does not add extra context beyond the basic action.

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, concise sentence that front-loads the core action and magnitude. Every word is necessary; there is zero redundancy or fluff. The structure is optimally efficient.

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?

Given the simple nature of the tool (one optional parameter, no output schema), the description fully captures the operation. The device parameter is documented in the schema, and the action is unambiguous. Nothing an agent needs to call this 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?

The schema already documents the single optional 'device' parameter with 100% coverage, so the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate as the schema handles parameter documentation and the description does not need to compensate.

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 ('下げる' – lower) with a clear resource ('音量' – volume) and specifies the action magnitude ('1段階' – by one step). This clearly differentiates from sibling tools like volume_up (increase), set_volume (absolute setting), and mute (mute state). An agent can immediately understand the tool's function without ambiguity.

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 usage for incremental volume decrease but provides no explicit guidance on when to prefer this over set_volume (absolute control) or mute. There are no exclusions or alternative recommendations, leaving the agent to infer the appropriate context. This is adequate but not explicit.

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 discloses the core effect (raise volume by one step) but does not mention behavior at maximum volume, whether the volume belongs to the device or current app, or whether the operation can silently fail. For a mutating tool with zero annotation coverage, this is under-specified.

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 that is front-loaded with the action and increment. There is no filler, repetition, or unnecessary detail, so this is appropriately concise.

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, has one optional parameter, and full schema coverage, so the minimal description is mostly usable. However, with no annotations and no edge-case or alternative routing information, an agent cannot fully anticipate volume-cap behavior or confirm which device is affected without assuming defaults.

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 sole parameter device is fully documented in the schema, including its type, meaning, and default fallback behavior. The description adds no parameter-level detail, but since schema coverage is 100%, the baseline of 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?

The description states a clear action (上げる) and resource (音量) with an explicit increment qualifier (1 段階), so an agent knows this tool changes volume by one step rather than setting an arbitrary level. It does not explicitly differentiate from siblings like set_volume or send_key, but the increment is a meaningful distinction.

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 tool versus volume_down, set_volume, or send_key. An agent must infer from the name and description that this is the incremental increase tool, which is not enough for confident selection among similar volume/media tools.

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 states the switching action but does not describe side effects, prerequisites, or what happens to the current app/input after switching.

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 a single, front-loaded sentence with no filler. It efficiently conveys the core action and scope.

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 one-parameter tool, the core purpose is present and the parameter is fully documented. However, the lack of usage alternatives and behavioral details makes it only minimally complete given the large sibling tool set.

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 only one optional device parameter, and the schema description covers it 100%, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already provides.

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 (切り替える), a clear resource (テレビ放送/チューナー), and the starting state (アプリや外部入力から). This clearly distinguishes it from sibling tools like launch_app and switch_input.

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 'アプリや外部入力から' provides useful context for when the tool applies, but it does not name alternatives or exclusion conditions. With many related siblings like switch_input and set_channel, the agent must infer when watch_tv is the preferred choice.

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