dast_delay_rate

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

With no annotations, the description carries the full burden and delivers strong contextual constraints: date window, required preconditions, and a detailed exclusion list. It does not disclose the response format or probability units, but for a read-only prediction query this is a minor omission.

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?

The description is dense but purposeful: every sentence adds either scope, constraints, or alternatives. It could be lightly restructured for scannability, but there is no redundant filler.

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?

The description is sufficiently complete for an agent to decide when to call the tool, what parameters to require, and which scenarios belong to sibling tools. The only missing piece is a statement about the output shape or format, but no output schema exists to compensate.

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?

The input schema already documents all four parameters with formats and requiredness at 100% coverage, so the description adds limited new parameter meaning. It reinforces the date window and mandatory nature of all fields, which is useful but not a substantial extension beyond the schema.

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 concrete operation—querying delay and cancellation probabilities for future flights—and lists exactly which user questions it serves. It also explicitly states what it is not for, distinguishing it from real-time status, airport lists, weather, pricing, and booking tools.

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 explicit when-to-use triggers such as '未来航班是否容易延误' and when-not-to-use direction, telling the agent to use the flight-number real-time status tool instead. It also instructs the agent to ask for missing required parameters and to avoid calling for out-of-range dates, leaving no ambiguity.

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