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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-open-world, so safety is covered. The description adds genuine value beyond them: the pad is a REAL HID device visible in Settings, this reads the device rather than a web page and works with no browser open, and the return is presence-only rather than last-sent input. It stops short of 5 because it does not describe failure/permission behavior when no pad is present.

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 purpose is front-loaded in the first sentence and each subsequent sentence carries distinct information (HID truth, browser independence, presence vs. values, what the return field means). It runs slightly long with some emphatic repetition ('REAL HID device', 'rather than a web page'), which is the only thing keeping it from 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?

With no output schema, the description usefully explains the key return surface by telling the agent to inspect the `gamepad` field and its `registered` subfield. It leaves the rest of the output shape ('the surrounding HID surfaces') vague, so an agent cannot fully predict the response, but for a one-parameter read tool with full annotation coverage it is nearly 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?

There is a single parameter (udid) with 100% schema description coverage, so the schema fully documents it. The description adds no syntax, format, or sourcing guidance for udid, 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 states a specific verb and resource: reporting whether a virtual game controller is currently registered on an iOS device. It also functionally distinguishes itself from the value-reporting sibling (ios_gamepad_state) by stating 'It reports presence, not the last axes/buttons you sent.' An agent can tell the two apart 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?

Usage context is clear: this is a device-level truth check that 'stays true with no browser open,' and the agent is told to read the `gamepad`/`registered` field to decide whether a pad exists. However, it never names an alternative tool (e.g. ios_gamepad_state, ios_gamepad_disconnect) or states explicit when-not conditions, so the routing guidance stops short of the top score.

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