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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds two useful non-obvious traits: it will not generate forward-looking predictions and it does not consume quota/credits. It leaves the async polling semantics vague, e.g. whether a not-yet-finished job returns partial progress or requires re-calling.

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?

A single front-loaded sentence with semicolon-delimited clauses, each carrying a distinct fact (what it reads, the precondition, and two exclusions). Dense but no filler; a slightly clearer separation of the two return modes would improve it.

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 a one-parameter read-only retrieval tool with annotations and no output schema, the description states scope, precondition, and exclusions well enough to invoke it correctly. The remaining gap is what the agent should expect back (analysis payload vs. progress state) and how to handle an incomplete or expired job.

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?

With one parameter and 0% schema description coverage, the description carries the burden; it does clarify that job_id must already exist, implying provenance from a prior query, which is genuine added meaning. It does not describe the format, lifetime, or validity of job_id, so compensation is partial.

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 definition opens with a specific verb (读取/read) and a concrete resource: the historical analysis for a market quote the user just queried, or the supplementary-collection progress for public quotes. It does not, however, name the sibling that actually initiates such a job (e.g. search_quotes or get_market_card), so an agent must infer where job_id comes from.

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 clause '仅已有job_id' gives a real precondition: call this only after a job already exists, i.e. for polling or retrieval rather than initiating. Beyond that it gives no explicit alternative or when-not guidance, and it never points to the tool that creates the job, so the routing decision is only implied.

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