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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, so the risk profile is known structurally; the description adds genuinely new context by disclosing the OAuth scope requirement and that a local owner approval prompt may appear, which the agent must plan for. It also warns that startup actions or external services may be triggered. It stops short of saying what specifically is destructive or what happens if 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?

Three short sentences, front-loaded with the action, then the exclusion, then the auth requirement. No redundant restatement of the title or schema, and nothing that could be cut without losing information.

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 single-parameter, no-output-schema tool with rich annotations, the description covers action, scope, exclusion, and auth/approval prerequisites, which is nearly everything needed to call it. Minor gaps remain around failure behavior and whether launching an already-running app focuses it instead of spawning a duplicate.

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 100%, so the baseline is 3, but the description adds the meaningful constraint that the name must refer to an *approved* application, implying the value should come from the approved-apps listing rather than free text. That is real semantic value beyond the schema's 'exact selected application, window or folder name; avoid guesses'.

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 (Launch) and resource (a named approved desktop application), and explicitly demarcates the scope from the enumeration sibling with 'Do not use just to enumerate installed apps', which maps to exza_list_desktop_apps. An agent can distinguish this from the other desktop tools (focus_desktop_window, send_desktop_shortcut, type_desktop_text) without opening any schema.

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?

Gives a clear negative condition ('Do not use just to enumerate installed apps') and states the prerequisite (account-bound computer:write OAuth plus local owner approval). It does not name the alternative tool by name, nor does it say when launching is preferable to e.g. exza_open_browser_url or exza_focus_desktop_window for an already-running app, so it falls short of full routing guidance.

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