open_url

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions launching via 'am start' and optionally targeting a package, which gives some insight into the underlying action. However, it does not disclose safety (e.g., whether this might launch external apps or change device state), nor any side effects like what happens if the URL is invalid or the deep link is not handled. For a tool that can launch arbitrary intents, more behavioral context would be warranted.

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 description is two sentences long, front-loaded with the main action. Every sentence adds value: the first states the core functionality and mechanism, the second clarifies optional targeting. No filler or redundant content.

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?

Given the tool has 3 parameters (all covered by schema), no output schema, and moderate complexity (launching an intent), the description provides basic completeness. It explains the 'what' and 'how' but omits important context like whether it handles malformed URLs, what the return value indicates (success/failure), or prerequisite conditions (e.g., device must be connected). This is adequate but not thorough.

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%—each parameter already has a description in the schema: url as 'URL or deep link to open', serial as 'Target device serial', package as 'Optional package to target the intent at.' The tool description adds no new detail beyond what is in the schema, such as syntax or formatting nuances. Since schema coverage is high, a baseline of 3 is appropriate.

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 uses a specific verb+resource combination, 'Open a URL or deep link via an ACTION_VIEW intent (am start) — the way to jump straight to a deep-linked screen.' It clearly states the tool opens URLs or deep links and mentions the underlying mechanism (ACTION_VIEW intent). While it doesn't explicitly distinguish itself from siblings among many other tools, its purpose is distinct enough given the sibling list includes no other URL-opening tools.

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?

The description implies its usage context: 'the way to jump straight to a deep-linked screen' indicates when to use it (for deep links), and the optional package targeting provides some guidance. However, it lacks explicit exclusions or alternatives—for example, it doesn't say when NOT to use it (e.g., for opening a URL in a browser vs. a deep link). No sibling tool directly overlaps, so the lack of competition reduces the need for heavy guidance.

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