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

Annotations only declare the generic safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description adds material context beyond that: the vault key is used server-side and never returned, two specific grants are required (executor.run and secrets.use on the key binding), the call returns either inline output or a job_id, and it warns "Can affect the remote system" — which usefully flags real side effects despite destructiveHint=false. Nothing here conflicts with the annotations.

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 sentences, front-loaded with what it does, then security/grants, then the wait-vs-poll decision — no filler. The wait parenthetical ("seconds, 0-120, for example 120: the call stays open on the server, which is cheaper than polling") is slightly tangled but each clause carries 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?

Return behavior is well covered for a tool with no output schema (inline output vs job_id), as are auth requirements and side-effect warning. However, given six parameters with zero schema documentation and a default-to-destructive action against remote systems, leaving host_ref/target_id/result_offset unexplained means an agent cannot reliably construct the destination or paginate results from this description alone.

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 carry parameter meaning, and it only does so for wait (range 0-120, semantics of blocking, a cost rationale). The two destination-selection parameters, host_ref and target_id, are never explained or distinguished, and result_offset is unmentioned — three of six parameters remain opaque, which is a serious gap for a tool whose key decision is which destination the command lands on.

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 ("Queue ONE non-interactive SSH command on a declared destination through the executor") and the 'ONE'/'non-interactive' qualifiers scope it tightly. It is distinguishable from executor_job (the polling sibling it names) and from session/target management siblings like executor_ssh_sessions and executor_targets.

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?

It gives a concrete decision rule: set wait to get output in the same call, otherwise poll the returned job_id with executor_job, and explains why (server-side waiting is cheaper than polling). It also states the required grants. What it lacks is differentiation from close siblings such as executor_run, executor_sandbox, or executor_ssh_sessions — an agent has no explicit 'use this instead of that' for the non-polling alternatives.

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