open_app

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent behavior, so a lower bar applies, yet the description adds nothing beyond them – no note on the high-risk confirmation flow that the `confirmation_token` parameter implies, no statement about side effects of launching processes, and no duplication/instance semantics tied to `reuse_existing`.

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?

A single short sentence with zero padding and no ambiguity about being secondary to `launch_app`. It is efficient, though its extreme brevity means it carries no useful information beyond the aliasing relationship.

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 an 8-parameter, destructive, open-world launch tool with no output schema and a confirmation-token workflow in its schema, a one-line alias note is not sufficient context. An agent gets no warning about risk, confirmation gating, or what happens on failure/timeout, all of which matter for this operation.

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%, so the schema already documents all eight parameters (including defaults, ranges, and the 'prefer app' guidance for `command`). The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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 identifies the tool as a 'Compatibility alias for launch_app', which tells an agent both the underlying capability (launching apps, inferred from the `app`/`command`/`new_window` params and the sibling `launch_app`) and its status as a legacy alias. That distinguishes it from the primary sibling, though it never states the action in its own words.

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?

'Compatibility alias' implicitly signals that `launch_app` is the preferred entry point for new work, but this is left to inference rather than stated. There is no explicit when-to-use/when-not-to-use guidance, nor any mention of when the alias is actually required.

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