Send Intent

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

No annotations exist, so the description bears the full disclosure burden. It does disclose the key side effect — this launches an activity and changes the foreground app — plus the return shape ('ok plus the new foreground app'). It says nothing about failure behavior for malformed intents, missing components, or whether the action is blocked on certain devices.

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-loaded with the concrete shell equivalent, then the example, then parameter formatting notes, then the return. Three sentences and no filler. It is dense rather than padded, though the example and the extras note could be tightened slightly.

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?

An output schema exists, so return values need not be spelled out (and the description's brief mention is a bonus). But for a flexible 6-parameter intent tool with zero schema coverage, leaving `data`, `package`, and `device` undefined is a real gap — an agent cannot tell how to target a specific device or attach a URI.

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% and there are 6 parameters, so the description must compensate. It does add real meaning for `action` (via an example intent string), `component` (the 'package/.Activity' format), and `extras` (type-to-extras coercion). The `data`, `package`, and `device` parameters get no explanation at all — `device` in particular, which is unexplained despite likely meaning multi-device targeting.

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+resource ('Start an activity with an arbitrary Android intent') and grounds it in the underlying command (`am start -a ACTION`), which tells an agent exactly what primitive this wraps. It does not explicitly distinguish itself from the closer siblings (`launch_app`, `open_url`), leaving that differentiation to inference.

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 settings-page example implies a usage context (deep-linking to a specific screen), which is genuinely helpful. However, there is no statement of when to prefer `launch_app` or `open_url` over this lower-level escape hatch, and no mention of any prerequisite such as a connected device or debugging permissions.

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