Smartest-TV

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

No annotations are provided, so the description carries the full burden. It discloses one useful trait — that playback happens with screens off, i.e., audio-only mode — but says nothing about what 'stop' affects, whether it interrupts existing sessions, permission requirements, or rate limits.

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, front-loaded with the mode and capability, with an efficient action summary. No filler, though the action list mostly duplicates the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the input schema is fully documented, so return values and parameter meanings need not be restated. However, for a six-parameter multi-room tool sitting among many tv_* siblings, the missing usage routing guidance leaves the definition only minimally 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%, so all six parameters (room, query, rooms, action, volume, platform) are already documented in the schema. The description only restates the action values, adding no format, default, or interaction detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific mode ('Multi-room audio mode — play music with screens off') plus the supported actions, so an agent understands the resource and capability. The 'screens off' framing implicitly differentiates it from tv_play/tv_volume, but no sibling is named explicitly.

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 lists actions but never says when to use tv_audio versus tv_play or tv_volume, nor when to avoid it. Given the presence of dedicated tv_play and tv_volume siblings, the absence of routing guidance is a real gap.

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

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

With no annotations, the description carries the full behavioral burden. It discloses one useful trait (automatic platform/content-ID parsing), but says nothing about whether casting interrupts current playback, what happens with an unsupported URL, or whether the TV must be 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?

Two short sentences, front-loaded with the action. The second sentence ('Paste any streaming URL') partially restates the platform list already given in sentence one, a minor redundancy but not harmful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and both parameters are covered by the schema. What is missing is prerequisite state (target TV selection, current playback impact) and differentiation from the many playback siblings, which matters for a mutation-style tool with no annotations.

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 both parameters are documented in the schema (url formats, tv_name default). The description adds no syntax or format detail beyond restating that a streaming URL is accepted, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (cast) and resource (Netflix/YouTube/Spotify URL) plus the target (TV), so the action is unambiguous. It does not distinguish itself from close siblings like tv_play or tv_launch, which an agent would likely confuse this with.

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 instruction 'Paste any streaming URL' implies the trigger condition, but there is no explicit when-to-use guidance and no mention of alternatives such as tv_play or tv_launch. Usage must be inferred from the tool name and enum-free parameter.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that HTML is generated, served locally, and opened in the TV's browser, but it does not cover permissions, persistence, whether existing TV content is replaced, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tightly written sentences. The primary purpose is front-loaded, followed by a compact explanation of the underlying mechanism, 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?

Given that the schema is rich, an output schema exists, and the tool has only four parameters, the description is nearly complete for invocation. It explains the mechanism and content types, but its lack of routing guidance among many TV siblings leaves a small contextual 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?

Schema description coverage is 100%, so the input schema already documents all four parameters in detail, including content-type-specific data shapes. The description adds only the general notion of showing any URL and does not add meaning beyond what the schema 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 names a specific action and resource: turning the TV into a display that shows dashboards, messages, clocks, or URLs. It is clearly more than a restatement of the tool name, but it does not explicitly distinguish itself from related siblings such as tv_screen, tv_notify, or tv_cast.

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 showing content on a TV, but provides no explicit when-to-use guidance, prerequisites, or alternatives. With many sibling tools available, an agent is left to infer when tv_display is preferred over tv_screen, tv_notify, or tv_launch.

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

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

No annotations are supplied, so the description carries the burden, and 'List all' usefully signals an unfiltered, read-only enumeration. However, it says nothing about permissions, pagination, or whether the result can be large, which is the kind of context the description would need to add for a zero-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that fully covers what the tool returns, 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?

With an output schema present and no input parameters, the description need not explain return values, and its scope statement is sufficient to call the tool. A brief note on how it relates to tv_list_tvs would have closed the only remaining 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 tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify beyond the fact that no filtering arguments exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('List') and resource ('TV groups and their members'), so an agent immediately knows what comes back. It is not explicitly contrasted with similar siblings like tv_list_tvs, but the group-centric scope is self-evident from the phrasing.

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 statement of when to call this versus alternatives such as tv_list_tvs or tv_status. Usage is only implied by the tool name; no context, prerequisites, or exclusions are given.

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. 'Show' weakly implies a read-only operation, but the description never states the recency window ('recent' is undefined), whether history is per-user or per-device, or any pagination/ordering behavior. This is a meaningful gap for a history-listing 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?

A single short, front-loaded sentence with no wasted words. It is efficient, though the brevity comes at the cost of the substantive detail scored elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the tool has only one optional parameter, keeping complexity low. However, with no annotations and no definition of what 'recent' means or how history is scoped, the description is thinner than the minimum needed to call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single parameter 'limit' is undocumented in both schema and description. The description adds no meaning to the parameter (e.g., max items, ordering interaction), leaving the agent to guess its semantics from the name and default alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Show') and resource ('recent play history'), so the agent knows this retrieves past playback data rather than current state (tv_state/tv_status) or upcoming content (tv_whats_on). No explicit sibling differentiation is offered, but the resource is distinct enough to select correctly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus related tools such as tv_state, tv_status, or tv_whats_on, and no mention of prerequisites. The agent must infer usage entirely from the name.

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 carry the full behavioral burden. 'Get' implies a read-only operation, but the description does not state permissions, side effects, rate limits, or whether data is cached or live. More context is needed for a tool with zero annotation coverage.

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, and the core purpose is front-loaded. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is low-complexity with two optional parameters, full schema descriptions, and an output schema, so the description need not explain return values. However, it is incomplete for routing among 22 sibling tools and lacks behavioral context in the absence of annotations. Adequate but with clear 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 coverage is 100%, so the two optional parameters are fully documented in the schema itself. The description mentions 'screen time' and 'subscription value analysis', which loosely correspond to report_type values, but adds no syntax or format details beyond what the schema already provides. Baseline 3 is appropriate 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 uses a clear verb ('Get') and names three specific report types ('viewing insights', 'screen time', 'subscription value analysis'), so the purpose is immediately clear. It does not, however, differentiate this tool from sibling tools like tv_history or tv_recommend, which could overlap in some contexts.

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 when-to-use guidance, no prerequisites, and no alternatives. It only states what the tool returns; an agent must infer usage context from the 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 provided, so the description carries the full behavioral burden. It says what the tool does but does not disclose permissions, TV state requirements, whether launching replaces current playback, or other side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short, front-loaded lines with no filler. Each sentence contributes either the core action or the key routing alternative.

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 three-parameter launch tool with full schema coverage and an output schema, the description covers purpose, key parameters, and sibling routing adequately. The main remaining gap is behavioral context, which is less critical here because return values are handled by the output 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 description coverage is 100%, so the input schema already documents app, tv_name, and content_id. The description adds only the deep-link/content-ID usage distinction, which the schema also covers, so 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 gives a specific verb and resource: launch an app, optionally with a deep link. It also explicitly distinguishes this tool from the sibling tv_play by contrasting exact content ID use against content-name use.

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 explicit routing guidance: use tv_play when you have a content name, and use tv_launch when you have the exact content ID. This covers when to use this tool and when to choose the primary 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a safe, read-only enumeration and names the returned fields, but adds nothing about ordering, scoping, or side effects. For a zero-parameter listing tool the risk surface is small, so this is adequate rather than 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 front-loaded sentence with no filler; the action, scope, and returned fields all appear in one clause. Nothing 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?

An output schema exists, so return-value detail does not need to live in the description, and the tool has no inputs to explain. The only shortfall is the absence of routing guidance against the many sibling TV tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (configured TVs) and enumerates the fields returned (name, platform, IP, default status). The purpose is unambiguous, though it does not explicitly contrast itself with sibling read tools like tv_status or tv_state.

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 indication of when to use this versus alternatives such as tv_status or tv_state, nor any prerequisites or exclusions. The agent must infer that this is the discovery/enumeration call from the description 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?

With no annotations provided, the description carries the full behavioral burden. 'Continues from watch history' is useful context, but it does not disclose side effects such as changing TV playback state, required permissions, behavior when no history exists, or error conditions for an action tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste. The primary action is front-loaded, followed immediately by the key continuation rule.

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 no required parameters, and includes an output schema, so return values need not be explained. Still, as an action tool with no annotations, the description leaves behavioral gaps around side effects and prerequisite conditions that a more complete definition would cover.

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 the 'query' and 'tv_name' parameters are already fully documented with defaults and omission behavior. The description adds no additional parameter meaning beyond what the schema provides, so 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 and resource: 'Play the next episode.' It also explains the continuation logic via watch history, which helps distinguish it from a generic play command. However, it does not explicitly contrast itself with siblings like tv_play or tv_whats_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 implies usage when continuing a series, but offers no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as tv_play or tv_queue. The agent is left to infer that this is for resuming episodic content.

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. 'Toast' implies a transient, non-blocking overlay, but the description never says whether it interrupts playback, how long it persists, whether it requires an active session, or what happens if the named TV 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?

A single front-loaded sentence with zero filler; every word earns its place and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the schema covers both parameters. Still, for a display-action tool with no annotations, the description is minimal and omits any statement of side effects, target requirements, or failure behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'message' and 'tv_name' (including the omit-for-default behavior) are already fully documented in the schema. The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb (show) and a specific resource (toast notification on the TV screen), which is more distinctive than the generic names of siblings like tv_display or tv_screen. However, it never differentiates itself from those siblings explicitly, so an agent must infer the distinction from the word 'toast' alone.

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 instead of tv_display, tv_screen, or tv_scene, nor any stated preconditions (e.g., TV must be on/connected). The single sentence gives no usage context at all.

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

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

With no annotations present, the description carries the full burden, and it does disclose two real behaviors: automatic content-ID resolution and deep-linking into the TV app. However, it omits prerequisites (must the TV be on/paired?), failure modes, and ambiguity handling when a name matches multiple titles, which matters for a 6-param playback tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and immediately followed by the key behavioral note. Efficient, though the 'primary tool' line is slightly self-referential rather than instructive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the schema fully documents parameters. What is missing is the operational context a playback tool needs: TV state prerequisites, auth/pairing requirements, and what happens when the query is ambiguous. Adequate but with clear 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 coverage is 100%, so every parameter is already documented, including platform values and Netflix-only season/episode. The description only hints at title_id's role by noting the ID is resolved automatically; it adds no syntax or format detail beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: find content by name and play it on TV. It also self-declares as the primary tool and distinguishes itself via auto-resolution and deep-linking. It never names the siblings it is not (tv_launch, tv_cast, tv_resolve), so differentiation is partial.

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?

Calling itself 'the primary tool' implies preferred usage, but there is no explicit when-to-use versus when-not, and no alternative is named (e.g. tv_resolve for lookup-only, tv_cast for casting). Usage is implied rather than prescribed.

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, yet it says nothing about idempotency, behavior when the TV is already on/off, error conditions, or permissions. For a state-changing tool with zero annotation coverage this is a significant gap, partially offset by the presence of an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single five-word sentence with zero waste and the core action front-loaded. Appropriately sized for a trivial toggle tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters, 100% schema coverage, an output schema, and low operational complexity, the definition is nearly complete. Only minor behavioral notes (already-on/off handling, idempotency) are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and both parameters ('on' and 'tv_name') are fully documented in the schema including the default-TV behavior. The description adds no parameter meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Turn TV on or off'), so an agent immediately knows it toggles power. It does not, however, differentiate itself from related siblings like tv_state or tv_status that could also be confused with power control.

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 alternatives such as tv_state (check state first) or tv_scene. Usage is only faintly implied by the verb, leaving routing decisions 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?

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing: it does not say whether 'clear' destroys the whole queue, whether 'add' requires a resolve step first, whether 'play' targets a TV and what happens if tv_name is omitted, or whether any action has side effects outside the queue. For a multi-action mutation tool this is a substantial 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?

Two short sentences, front-loaded with the verb and resource, no filler. It is arguably over-terse for a five-action tool, but nothing in it 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?

With six parameters, five distinct actions, an output schema, and zero annotations, the description should explain per-action behavior and risk (especially 'clear'). It leaves the agent to infer semantics of each action entirely from the schema, which is inadequate for a mutating queue 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 every parameter (query, season, episode, tv_name, platform) is already documented in the schema, including action-conditional requirements. The description adds no format, default, or conditional detail beyond the schema baseline, so a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb ('Manage') plus resource ('the play queue') and enumerates the five supported actions, so an agent knows this is the queue-control tool. It does not differentiate itself from near-neighbors like tv_play or tv_next, which could also relate to advancing playback, leaving some ambiguity about which tool owns 'skip'.

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 lists the action values but gives no guidance on when to choose tv_queue over tv_play, tv_next, or tv_cast, nor any prerequisites or ordering context. The action names are already present in the 'action' schema field, so the list adds no routing information.

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

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

With no annotations, the description carries the full behavioral burden. It conveys a read-only retrieval implied by 'Get' and explains what drives the results (watch history + trending), but says nothing about side effects, permissions, or rate limits. Barely adequate rather than informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler. Nothing redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the two parameters are schema-documented. However, given the many overlapping siblings, the definition is thin on routing and usage 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%, so both 'mood' (with its enumerated values) and 'limit' are already fully documented in the schema. The description adds no meaning beyond that, which lands at 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 verb (Get) and resource (personalized recommendations) and discloses the data sources (watch history + trending). It does not distinguish itself from plausible siblings such as tv_whats_on or tv_insights, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. An agent cannot tell from this text alone whether to reach for tv_recommend versus tv_whats_on, tv_history, or tv_insights.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the key behavioral trait that resolving does not trigger playback, but says nothing about caching, network lookups, failure modes, or auth requirements. It covers the most important side-effect question and little else.

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 ends with the key scoping qualifier. Zero 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?

An output schema exists and schema coverage is full, so return values and parameter details need not be restated. The description covers purpose and the primary behavioral distinction, though with no annotations it could say more about permissions or lookup behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (query, season, episode, platform, title_id) is already documented in the schema. The description adds no syntax or format detail beyond that, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (resolve) and resource (content name to platform ID) and immediately distinguishes itself from the tempting sibling tv_play via 'without playing'. An agent can tell this apart from tv_play/tv_launch without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without playing' implies the use case and steers the agent away from tv_play, but there is no explicit when-to-use statement or named alternative. Usage is inferable rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Run' implies a state mutation on a device, yet the description never says whether running a scene changes device state, whether it is reversible, whether it requires an active TV connection, or how failure is reported. The preset list is the only added 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?

Two short sentences, zero filler, and the core capability ('Run or list scene presets') is front-loaded before the enumeration of built-ins. Nothing wastes the agent's context budget.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation. However, for a tool with a state-mutating 'run' action and no annotations, the description leaves an agent guessing about side effects, prerequisites for targeting a TV, and whether 'run' is destructive. It is minimally viable but thin given the mutation risk.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains that name is required for 'run' and tv_name targets a TV. The description adds real value by enumerating the built-in preset names (movie-night, kids, sleep, music), which are valid values an agent could not get from the schema. That nudges it just above a bare baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb pair and resource: 'Run or list scene presets.' This is clear and actionable, and the sibling list contains no other scene-related tool, so it is reasonably distinguishable. It stops short of explicitly contrasting with neighbors, but the resource noun does the disambiguating work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the 'list' vs 'run' pair and the schema's default of 'list' tell the agent the two modes exist, but there is no explicit when-to-use guidance, no prerequisites (e.g., must a TV be selected first), and no exclusions or alternatives named. Adequate but with clear gaps.

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, and it does disclose one valuable trait: audio continues when the screen is off. Beyond that it says nothing about required auth, idempotency, or whether the change persists, and the audio note is duplicated in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the core action front-loaded and zero 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?

With an output schema present, return values need not be explained, and the toggle behavior is covered. The description falls short on sibling disambiguation and any operational context (auth, persistence), which matters for a device-control tool with no annotations.

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 (on, tv_name) are already fully documented in the schema. The description adds no additional parameter meaning, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (turn on/off) and resource (screen), so the agent knows exactly what the tool does. However, it offers no differentiation from closely named siblings like tv_power, tv_display, or tv_state, leaving the agent to guess which controls the screen.

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 when-to-use guidance and no mention of alternatives, despite several plausible overlapping siblings (tv_power, tv_display). The agent must infer usage purely from the verb phrase.

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

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

No annotations exist, so the description carries the full disclosure burden. It usefully notes the snapshot semantics and that unsupported fields return None, which is real behavioral value, but it omits whether this is strictly read-only, whether it has side effects, latency/polling characteristics, or prerequisites such as the TV 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?

Front-loads the purpose before the usage note and edge-case behavior in three tight sentences with no filler. Well structured, though the middle sentence is slightly redundant with the first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values beyond the None-fallback nuance it already gives. For a simple one-param snapshot read tool it is essentially complete, missing only minor read-only/side-effect reassurance.

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?

Only one parameter with 100% schema description coverage, where the schema already documents 'Target TV name. Omit for default TV.' The description adds nothing beyond the schema, which is the expected baseline 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?

States a clear verb (Get) and resource (TV state) and enumerates the four dimensions captured (playback, volume, input, power). The word 'unified' hints at why this differs from single-dimension siblings like tv_volume or tv_power, but it never names tv_status or any sibling explicitly, so differentiation is implied rather than stated.

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?

'Returns a single snapshot for agent branching' implies a use case (consolidated state for decision-making) but gives no explicit when/when-not guidance and does not route the agent away from alternatives like tv_status or tv_state_watch. Usage is inferable but not prescribed.

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

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

With no annotations, the description carries the full burden and does useful work: it discloses the non-obvious streaming behavior (count progress notifications at interval spacing, final snapshot returned last), which an agent could not guess from the schema. It omits error/cancellation behavior and any permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short lines, front-loaded with the core action and mechanism, with no filler. Every sentence adds 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?

An output schema exists so return values need no explanation, and the streaming semantics and defaults are covered. For a no-annotation streaming tool it is nearly complete, though it lacks any note on interruption/auth behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining how count and interval compose into the default watch duration (12 x 5s = 1 minute). That relationship is not derivable from the individual parameter descriptions alone.

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?

Names a specific verb (stream/watch) plus resource (tv_state snapshots) and the delivery mechanism (progress notifications), which cleanly separates it from the sibling tv_state single-snapshot tool. It stops short of explicitly naming tv_state as the alternative, so sibling differentiation is implied rather than stated.

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 'Default is 1 minute of watching' line implies this is for time-boxed observation, but there is no explicit when-to-use vs. tv_state or tv_status, no conditions, and no exclusions. Usage must be inferred from the streaming mechanics.

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 behavioral burden. 'Get' strongly implies a non-mutating read, and listing the returned fields gives useful context, but it says nothing about permission requirements, whether the call is cached/polled, or freshness of the data. Adequate but thin for a zero-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the verb and resource first and the payload fields compactly enumerated. No filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, and the one optional parameter is fully documented in the schema. The main gap is the absence of any routing guidance relative to the many overlapping tv_state-family siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter already documents 'Target TV name. Omit for default TV.' The description adds no further parameter meaning, so the baseline 3 for high schema coverage applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('TV status') and enumerates the returned fields (current app, volume, mute, model, firmware), which makes the tool's scope concrete. It does not, however, differentiate itself from near-neighbors such as tv_state or tv_state_watch, leaving the agent to infer the 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?

The description gives no indication of when to call this tool versus alternatives like tv_state, tv_state_watch, or tv_insights, all of which plausibly overlap with status retrieval. No preconditions or exclusions are stated.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a real trait beyond the schema — "Resolves once, launches on all targets via asyncio.gather" signals parallel fire-and-forget dispatch rather than waiting for playback confirmation. However, it says nothing about partial-failure behavior, per-TV errors, permissions, or whether playback state is verified.

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, front-loaded with the core capability and with zero padding. The asyncio.gather detail is mildly implementation-flavored but does convey parallel dispatch semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the schema covers all parameters. Still missing for a 7-param broadcast tool with no annotations: whether group and tv_names are mutually exclusive in practice, and what happens when one TV fails while others succeed.

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 7 parameters (including the group-vs-tv_names hint). The description adds no parameter meaning beyond that — baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and multi-target scope: "Play content on multiple TVs simultaneously (party mode)." The multi-TV scope clearly distinguishes it from single-target siblings like tv_play and tv_cast, though no sibling is named explicitly.

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 "multiple TVs simultaneously (party mode)" implies the usage context, but there is no explicit when-to-use versus tv_play/tv_launch, and no stated prerequisites or exclusions. Usage must be inferred from the scope wording 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?

With no annotations, the description carries the behavioral burden and discloses the key modes: a no-arg read returns current volume and mute status, while level/direction/mute perform mutations. It does not cover edge cases like argument conflicts, error behavior, or required permissions, 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?

The description is front-loaded, bulleted, and free of filler. Every sentence maps directly to an invocation mode.

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 multi-mode behavior of a 4-optional-parameter tool and output schema exists to cover return values. It does not specify precedence when multiple optional arguments are supplied together, which is a minor 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?

Schema coverage is 100%, so the baseline is 3, but the description adds useful mode examples such as level=25, direction="up"/"down", and mute=True/False/None. It omits tv_name, which is fully covered by 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 resource (volume/mute) and the exact operations available: get, set, step up/down, and toggle mute. It clearly separates this tool from siblings like tv_audio and tv_display by focusing only on volume and mute behavior.

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 bullet list gives explicit usage patterns for no args, level, direction, and mute, which tells the agent when each mode applies. It does not explicitly name alternatives or exclusions among sibling TV tools, so it stops short of full 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?

With no annotations provided, the description carries the full behavioral burden, yet it says nothing about whether this is a read-only fetch, how fresh the trending data is, region/locale behavior, or whether it triggers any network/account side effects. For a zero-annotation tool this is a meaningful gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler, which is appropriate for a simple query tool. It is arguably slightly too thin given the lack of any usage or behavioral framing, keeping it just short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the parameter set is fully covered by the schema. However, the absence of annotations means the description should have supplied the read-only/behavioral context it omits, leaving the definition only minimally viable.

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 both parameters are already fully documented in the schema, making 3 the baseline. The description's 'Netflix and/or YouTube' does loosely reinforce the platform parameter's omit-for-both semantics, but adds no syntax or limit detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Show') and resource ('trending content') scoped to two named platforms, so an agent immediately understands the operation. It does not, however, distinguish itself from the nearby sibling tv_recommend, which plausibly offers overlapping recommendation-style functionality.

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 when-to-use guidance and no mention of alternatives such as tv_recommend or tv_history. The only routing signal is implicit in the platform parameter, so the agent must infer when this tool is the right choice.

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