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

Annotations already declare non-readonly, openWorld, non-idempotent, non-destructive, but the description adds genuinely new behavior: which browser gets targeted and why, and the return contract ({ opened, url, browser, pageId }) including the side effect that a non-null pageId makes the opened tab the device's current page. That side-effect disclosure is exactly the kind of context annotations cannot carry.

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 action in the first sentence and keeps the mechanism and return-contract details after it. It is a dense single paragraph rather than bullets, but every clause (foreground browser rule, Chrome fallback, pageId chaining) carries information an agent needs.

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 correctly compensates by enumerating the return fields and explaining pageId semantics, and it covers the browser-selection behavior. Remaining gaps are minor (failure modes, whether the target browser must already be installed), so it is close to complete for a two-parameter tool.

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% for both parameters (url with 'include https://', udid as device serial), so the schema already does the work. The description adds no parameter-level syntax or format detail beyond what is in the schema, which is the baseline-3 case.

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 ('Open a URL in a browser on an Android device') and implicitly distinguishes itself from ios_navigate_url, web_navigate, and session_navigate by naming the platform. The added detail about driving the foreground browser versus falling back to Chrome makes the tool's exact behavior identifiable without opening the 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?

Explains the operative selection rule (use the browser already in the foreground when present, otherwise Chrome) and routes the agent to follow-up tools ('android_devtools_* / webpage_*') after a successful call. It does not explicitly contrast itself with android_devtools_navigate or web_navigate, so the alternative-choice guidance is incomplete but the usage context is clear.

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