adobe_launchApp

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

Annotations already declare a non-read-only, non-destructive, closed-world operation, so the lower bar applies; the description still adds genuine behavior: it blocks until the app accepts scripts, and wait:false makes it return immediately rather than block. It does not disclose the timeout default, what happens if the app never becomes script-ready, or whether a call is idempotent when the app is already running.

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 sentence with the action front-loaded and zero filler; parentheticals carry the optional-parameter hints efficiently. The trailing fragment 'No computer-use needed' is a slightly awkward add-on but is relevant framing rather than waste.

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 five-parameter launch tool with no output schema, the description covers the core blocking/readiness semantics that an agent most needs before calling. It stops short of return value, failure behavior, and the timeoutSec unit/default, which an agent would want given there is no output schema.

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 only 20% (only 'version' is documented inline), so the description must compensate and largely does: it explains that wait controls blocking vs immediate return, that files are projects/images, and that version is a year. The app enum values gain meaning from the ordered app list. timeoutSec is left completely unexplained, which is the remaining gap.

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 an Adobe app') and enumerates the exact five applications covered, which also implicitly decodes the app enum values in order (ae/pr/ps/ai/ame). It is clearly a launch operation rather than the sibling file-opening tools (adobe_openFile, ps_openFile, ai_openFile), though it never names a sibling explicitly to draw that contrast.

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 conveys implied usage ('optionally with files... and a specific version year') and gives one explicit conditional: wait:false to return immediately. It never says when to prefer this over adobe_openFile or when a session is already running, and gives no prerequisites or exclusions.

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