da_launch

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

Annotations are not provided, so the description carries the full burden. It mentions that argv[0] is required and that cwd, env, timeoutMs, and detached are optional, which adds some behavioral context. However, it does not disclose what happens on launch failure, whether the process is awaited or returns immediately, what the return value is (no output schema), whether timeoutMs default behavior is meaningful, or how detached mode affects the returned result. For a process-launch tool this is a notable transparency gap.

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?

The description is a single, efficient sentence that front-loads the core purpose and then lists parameter requirements. It wastes no words and is appropriately sized for the 5-parameter tool. It could arguably add a sentence on failure behavior, but as written, it earns its place.

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?

The description lacks essential context for a process-launch tool: no output schema exists, so return behavior is undocumented. It doesn't explain whether launch is synchronous or asynchronous, what happens on exit code non-zero, whether timeoutMs causes process kill, or how detached affects the process lifetime. While the schema and complexity are moderate (5 params, 1 required, nested env object), the description doesn't cover behavioral expectations that an agent would need to interpret results correctly.

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%, so the description must compensate. The description does mention argv, cwd, env, timeoutMs, and detached by name and notes that argv is required while others are optional. This adds meaning beyond the bare schema of required/properties. However, it provides no detail on semantics of related parameters (e.g., how env interacts with inherited environment, what detached means behaviorally, what timeoutMs default is). With nested objects present (env) and no per-parameter docs, this is only marginal compensation over a 0% coverage schema.

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 states the purpose clearly: 'Launch a program by name or absolute path.' It uses a specific verb (launch) and resource (program), and distinguishes from siblings like da_move_mouse, da_type, etc. which are all desktop automation actions. However, it doesn't explicitly name alternative tools for process management (none exist among siblings), so it doesn't differentiate at a sibling level, but the distinction from the listed action tools is obvious.

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 says when to use it ('Launch a program by name or absolute path'), which gives a clear context. However, it provides no guidance on when NOT to use it or any alternatives. It doesn't mention prerequisites (e.g., if the program must exist in PATH), behavior when the program is already running, or whether the tool waits for process completion. The guidance is implied but there are no explicit exclusions or alternative tool references.

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