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

Annotations already declare readOnly/idempotent/non-destructive and open-world, so the safety profile is covered. The description adds real value beyond that: the data coverage window (2019-01-01 to roughly yesterday), the found:false-not-an-error behavior for empty periods, and that the source is keyless.

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 payload is front-loaded with what is returned, followed by how to scope it and what edge cases to expect. It is dense but every sentence carries information; the only mild redundancy is restating the 2019-2026 span already in the schema.

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 carries the burden of describing returns, and it does list the aggregates and the found:false sentinel. It stops short of specifying the exact response shape (field names, units), which leaves a small gap for a data-returning tool.

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 100%, so the baseline is 3, but the description adds a semantic not in the schema: passing nothing defaults to current-year-to-date. It also reinforces the acceptable range for `year` and that dates form an inclusive range.

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 the specific resource (TSA daily airport checkpoint screening counts) and the exact statistics computed (max, min, average, total), which distinguishes it from the sibling tsa_checkpoint_volumes that presumably returns raw series. Two concrete example queries make the intended output unambiguous.

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 clearly states the three invocation modes — a `year`, a `start_date`/`end_date` range, or nothing for year-to-date — and gives example phrasings that map to those modes. It does not explicitly contrast with tsa_checkpoint_volumes, so the alternative-selection guidance is implied rather than stated.

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