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, and it is extraordinarily complete. It covers output semantics (format 'description' vs 'xml'), coordinate meaning (element CENTER as exact tap point), flag conventions ([focused], [zero-area], [off-screen]), pruning behavior for anonymous containers, output size limits (~185k characters), and the auto-start session requirement. Every notable side effect or format nuance an agent would need is disclosed upfront.

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?

Despite being long, every sentence carries actionable information that would otherwise require separate lookups or trial-and-error. The core purpose and the most critical coordinate semantics are front-loaded, followed by usage heuristics and specific format behaviors. There is no filler, no repetition of schema text, and the structure (defaults → flags → search → xml → session) follows a natural decision flow.

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 7 parameters, no annotations, no output schema, and a complex output model, the description leaves nothing essential uncovered. It explains the output format, the meaning of every flag, the relationship to companion tools, the trade-offs between formats, and the conditions required to run. An agent could confidently invoke this tool correctly in almost any scenario without further exploration.

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?

Though schema coverage is 100%, the description adds substantial semantic depth beyond the schema. For example, the `search` parameter is explained as grepping the 'WHOLE hierarchy — including elements scrolled off-screen' with flags, the `label` parameter is tied to returning 'the COMPLETE SUBTREE', and `type` is linked to description-format filtering and prefix flexibility. The schema gives names; the description gives the behavioral meaning needed to choose the right parameter values.

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 opens with a precise verb-object pair: 'Get the UI hierarchy (page source) of an iOS device' and immediately positions it as 'THE single source of truth for element coordinates (physical screen points).' This clearly differentiates it from page-source tools on other platforms, and the rest of the description references specific iOS sibling tools (ios_tap_by_label, ios_scroll_to_element), so any ambiguity with generic page-source tools is removed.

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

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

The description gives explicit directives on when to use companion tools: 'Prefer acting on these labels via ios_tap_by_label rather than tapping raw coordinates', 'bring them into view with ios_scroll_to_element, don't swipe blindly', 'use ios_find_element (strategy "accessibility id")' for duplicate labels, and 'Reach for the subtree whenever you need attributes the compact format omits.' It also states when to prefer 'xml' over 'description' and when to use `search`. This is actionable, context-specific guidance with no vague phrasing.

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