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

Annotations already mark the tool as readOnlyHint=true, so the description need not repeat safety. It adds valuable behavioral context by disclosing the data source (TSA checkpoint passenger volumes), weekly update cadence, and the formula (30-day throughput vs 7-year history plus momentum). It also lists the returned fields, which is helpful given no output schema exists.

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 two sentences: the first leads with the primary output and its composition, the second provides explicit usage triggers and update frequency. Every word earns its place, with no tautology or filler, making it highly scannable and informative.

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 tool with one optional param and no output schema, the description covers the main behavior, use cases, data source, update cadence, and all output field names. It does not define each field's exact meaning, but the field names are largely self-explanatory and the schema covers parameter behavior, leaving only minor gaps.

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 the sole parameter `days`, including its optionality, purpose, range, and tier requirement. The description adds no additional parameter detail, so the baseline 3 is appropriate given the schema fully handles parameter semantics.

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 ('Returns a 0-100 US tourism-demand pulse') and resource/scope (US TSA checkpoint volumes), and enumerates the exact output fields (score, trend, confidence, etc.). This provides a clear, distinct purpose that differentiates it from the many sibling adw tools, even without naming an alternative.

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?

Explicitly lists when to call the tool: when the user asks about US travel demand, air passenger traffic, airport throughput, tourism recovery, hospitality occupancy, or dynamic pricing/discount decisions. It lacks a when-not-to-use clause or direct comparison to alternatives, so it falls short of a 5, but the stated triggers offer strong guidance.

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