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

Annotations declare non-read-only, non-idempotent, non-destructive. The description adds real behavioral detail beyond them: it steps the focus ring until focus holds, presses Select by default unless select:false, and is Apple TV-only. It does not describe failure behavior when no matching label exists, so not a full 5.

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

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

Front-loaded with the platform constraint then the core action, followed by the alternative-routing tail. Dense but nearly every clause carries actionable information; the comparison and routing sentences are justified for a fleet of near-sibling tvOS/ios tools.

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?

No output schema exists, and the description fully covers the tool's contract: platform scope, mechanism, default behavior of select, and how to source the label. An agent has everything needed to invoke 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: where to obtain the `label` value (ios_page_source, home-screen tile label="…") and that label matches either a label or an accessibility identifier, plus the practical effect of select:false.

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 with scope: move focus to the element matching `label` on Apple TV, and clarifies it steps the focus ring until focus holds. It immediately distinguishes itself from siblings like ios_tap_by_label (coordinate/label tap) and tvos_select by describing the focus-ring mechanism.

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

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

Gives explicit when/when-not and routes to alternatives: remote keys go through ios_tv_button, typing goes through ios_tv_text, and the label value is read from ios_page_source. It also states the key precondition that it reaches elements not yet on screen, which a coordinate tap cannot.

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