start_execution

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

With no annotations, the description carries the full behavioral burden. It usefully discloses durable idempotency, bounded output, no shell, and no remote targets. It does not explain whether execution is synchronous or asynchronous, what the return value contains, how output is retrieved, or what permissions/security context apply beyond the schema's owner note.

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 tight sentence with no wasted text. The core purpose is front-loaded, followed by key constraints: no shell and no remote targets.

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 execution-start tool with no annotations, low schema description coverage, five parameters, and no output schema, the description is too sparse. It omits lifecycle behavior, return/status semantics, output retrieval, cancellation, and the meaning of most parameters, leaving the agent to infer critical invocation details.

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 only 20%, so the description must compensate for undocumented parameters. It does not explain program, args, cwd, or idempotencyKey semantics, and only indirectly hints at idempotency. The owner parameter's bearer-secret meaning appears only in the schema, not in the description.

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 a specific verb and resource: 'Start a local executable directly.' It also scopes the tool by excluding shell execution and remote targets, which distinguishes it from run_powershell and ssh_exec/winrm_exec. However, it does not distinguish itself from the sibling run_program, so sibling differentiation is incomplete.

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 gives useful exclusions: 'No shell; remote targets unsupported.' This implies the tool is for local, non-shell executables. But it does not explicitly say when to use this instead of run_program, run_powershell, or remote execution siblings, so the usage guidance remains implied rather than routed.

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