observe

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

No annotations are supplied, so the description must carry the full behavioral burden. It does disclose the payload content (interactive and labelled elements plus handles), which is meaningful, but omits that this is a read-only/non-mutating operation, anything about cost or latency, and whether the returned handles remain valid across subsequent calls.

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 tightly packed sentences with the purpose front-loaded and the optional behavior second. No filler, no repetition of the title or 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?

With no output schema the description does need to describe return content, and it does in brief (elements with handles). But the role of handles, the meaning of width, and whether this is a safe read are all absent, leaving the definition only partly sufficient for a tool that sits at the core of an automation loop.

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%, so the description must compensate for both parameters. It only accounts for 'screenshot'; the 'width' parameter (with its non-obvious 540 default) is never mentioned, leaving an agent unable to judge what width affects in the captured image or in the coordinate space.

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 and resource: 'List interactive and labelled elements on screen with handles', which is distinct from the sibling 'screenshot' that returns an image. It never names a sibling explicitly, so differentiation is inferable rather than stated, keeping it below 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?

'Optionally attach a screenshot' implies the common pattern of inspecting and capturing in one call, and the mention of handles implies this precedes tap/tap_text. However, it gives no explicit when-to-use-vs-screenshot rule and no prerequisites or exclusions.

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