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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: no automation session is required, and it discloses a specific failure mode ("no HID available" on iOS 17.x / no-tunnel), which an agent needs to interpret a failed call.

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 tight paragraph, front-loaded with the action and its HID mechanism, then the pairing, coordinate convention, and failure mode. Every clause carries information; the em-dash phrasing is slightly dense but not wasteful.

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 4-param, no-output-schema input tool, the description covers the essential operational facts: what it does, its partner tool, the coordinate convention, and the known error condition. It is complete enough to invoke correctly, with the only gap being the norm fraction mode already handled by the 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 schema already documents udid, x, y and the norm fraction mode. The description only restates that coordinates are iOS screen points and omits the norm=true fractional mode the schema defines, so it adds little and is marginally less complete than 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: lifting the held contact via direct HID input, with the concrete equivalent (mouse-button-up / touch-up) spelled out. It explicitly names its counterpart tool ios_contact_hid, so an agent can place it in the press/release pair 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?

"Pairs with ios_contact_hid" and "no automation session needed" give clear context for when this tool applies — after a held contact, without a session. There is no explicit statement of when not to use it or which alternative to prefer if HID is unavailable, which keeps it 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.