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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds real context beyond that: the message is delivered as a human operator would send it, and the call may block for minutes before returning a command id, which is crucial for an agent's timeout and retry strategy. It does not explicitly warn that the agent may take destructive actions on its behalf.

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?

Two sentences, front-loaded with the action and its return value, followed by the one edge case that matters (long-running tasks). No filler and no restatement of the title.

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?

With no output schema, the description correctly explains both return paths (reply text vs. command id) and the latency involved, and annotations handle the safety hints. It stops short of describing the reply format or how long a command id remains valid, which would be useful for the polling flow.

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 50%: agent_id is well documented in the schema with its pattern and a pointer to get_account, but message has no description beyond length bounds. The description says nothing about what a good message looks like (instructions vs. questions, length, expected format), so it does not fully compensate for the gap — though a free-text message parameter is largely self-explanatory.

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 ("Sends a message to a running agent") plus the interaction model ("as its human would in the console chat"). It also distinguishes itself from the sibling get_reply by naming the conditions under which control passes there, so an agent can choose between the two without opening either 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?

The second sentence gives concrete guidance on the async path: long tasks take minutes and yield a command id to poll with get_reply. It does not spell out exclusions (e.g. when to use boot_agent first to get a running agent), but the "running agent" qualifier implies the prerequisite.

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