send_intent

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

With no annotations, the description carries the full burden, and it does supply one genuinely useful behavioral fact: 'Reports am errors even if exit code is zero,' which warns the agent not to trust exit status alone. It also flags the root/nonroot distinction. However, it says nothing about side effects of dispatching intents, permission requirements, or whether a failed dispatch partially applies.

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?

It is a single dense, telegraphic sentence with no wasted filler, which is efficient. But the run-on colon-separated list is hard to parse and the capability enumeration is not front-loaded as a clear statement of what the tool does.

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?

For a 12-parameter, zero-annotation tool, the description covers a decent share of the surface (kinds, extras typing, MIME, categories, flags, root mode) and an output schema exists to explain returns. It still leaves wait and user_id unexplained and gives no example of a valid call, which is a meaningful gap for a tool this broad.

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 coverage is 0% (titles and defaults only), so the description must compensate, and it does partially: it maps to kind, extras types (bool/int/long/float/string/null), flags, categories, mime_type, data_uri (DeepLinks), and package/activity (internal components). But action, wait, and user_id are never mentioned, so several of the 12 parameters remain opaque.

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 the tool name plus an enumeration of what the Intent can be (activity/broadcast/service/foreground_service/stop_service, internal components, DeepLinks, extras types), so an agent can tell this is the general-purpose Intent dispatcher. It does not explicitly differentiate itself from the sibling start_activity_root, which overlaps with the 'activity' kind, so it stops short of a 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?

There is no when-to-use or when-not-to-use guidance. The description never says to prefer this over start_activity_root for simple activity launches, nor when root vs nonroot or wait=true should be selected, leaving the agent to infer routing from a feature list.

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