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

Annotations already declare non-readonly, idempotent, non-destructive, open-world. The description adds genuinely new behavior: the version and request key must be fixed/pinned, and the backend keeps executing after the reply, which explains why the call returns before work completes. It does not say what the answer affects or what errors occur on version mismatch.

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 short clauses, front-loaded with the action and followed by the key behavioral trait; nothing is padded. It is arguably too terse rather than verbose.

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?

An output schema exists and annotations cover the safety profile, and the description adds the crucial asynchronous-execution note and the pinned version/request-key expectation. With six fully required, entirely undocumented parameters, however, the definition still leaves the caller short of what it needs to invoke 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% for six required parameters, so the description carries the full burden, yet it only alludes to version and request_key ('版本和请求编号固定') without format, constraint, or concurrency semantics. answer, credential, service_id, and interaction_id receive no explanation at all.

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 names a specific action (answering a persistent delivery question) but never uses the tool's core concept 'run', so the link to siblings like get_run_result or get_run_events is only inferable from the name. It is vague about what entity is being answered.

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?

There is no statement of when to call this instead of get_run_events, get_run_result, or prepare_task, nor any prerequisite or exclusion. The agent must guess the routing from the tool name alone.

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