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

The annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is largely covered. The description still adds real value beyond them: the run is asynchronous with a run_id, it costs 20 credits only after a usable memo is produced, and the output is explicitly informational rather than verified fact. It stops short of describing memo scope, length, or what happens on failure or refund.

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?

Four short sentences, each carrying distinct information: identity, async mechanics, cost, and the informational disclaimer. The most actionable fact for an agent, the run_id and polling loop, is just one sentence in and nothing is padded.

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 discloses the return value (a run_id) and the exact next step needed to retrieve results, plus the billing implication and a liability disclaimer. For a small three-parameter asynchronous tool that is close to complete; only the content or length of the memo itself is left unstated.

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 100% for all three parameters, including the required target with examples of accepted entity types. The description adds no meaning about focus or context beyond what the schema already documents, so the baseline 3 applies.

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: it 'starts a short memo' and returns a run_id, which tells an agent exactly what action it performs. It does not, however, differentiate itself from related research siblings such as sourced_brief or the deep-intelligence tools, so an agent must infer how 'quick' compares to those.

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 async workflow is spelled out precisely: call check_report_status with the returned run_id until status is completed. What is missing is when to choose this over the sibling brief/research tools, and there are no exclusions or prerequisites stated. Usage is therefore implied through the follow-up workflow rather than through selection guidance.

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