appium_find_element

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), so the description's job is supplementary. It does add real value: the return shape ('Returns driver attributes as JSON'), the elementResponseAttributes dependency on appium_driver_settings with shouldUseCompactResponses=false, and the caveat against natural-language selectors. It stops short of describing failure behavior when an element is not found.

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-loads the core purpose and the returned-UUID contract in the first two sentences, with preference ordering and cross-tool routing after. Dense and mostly waste-free, though the driver-settings aside could be trimmed.

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 carries the return-format burden and does so ('driver attributes as JSON'). Combined with strategy guidance, the scroll alternative, and the vision fallback, an agent has everything needed to select and call this tool 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 description coverage is 100% and the strategy enum is thoroughly documented in the schema itself (per-platform guidance is already in the enum/param descriptions). The description's strategy preference ordering largely repeats the schema, so it adds direction but little new parameter semantics.

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 and resource ('Find an element by strategy and selector') and immediately clarifies the downstream contract: the returned element UUID is passed to interaction tools. It is cleanly distinguishable from the sibling appium_find_elements (plural).

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?

Explicitly routes the agent to alternatives: appium_gesture action=scroll_to_element for scrolling-until-found, and appium_ai action=find_element for the vision fallback. It also gives a concrete preference ordering (accessibility id > id > platform-native > xpath) with the reason xpath is last resort.

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