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

readOnlyHint=true already tells the agent this is a safe read, so the description's job is lower. It does add real value by disclosing return content (waits, downtime, tactical advice) that the empty schema and absent output schema cannot convey, but says nothing about refresh cadence, data staleness, or whether advice is model-generated.

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?

One front-loaded sentence with no filler; the core act and data types come first. The ten-attraction parenthetical is long but earns its place by defining scope that no structured field provides.

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 zero-param read tool with no output schema, the description covers what comes back (waits, downtime, advice) well enough to call it correctly. The main gap is that 'drop tactical advice' is undefined — the agent cannot tell whether that is a precomputed recommendation or a raw data field.

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?

Zero parameters, so the schema imposes no semantic burden and baseline 4 applies. There is nothing an agent could mis-supply.

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?

Specific verb (Get) plus enumerated resources (live wait times, downtime status, drop advice) scoped to a named list of ten tier-1 Disney headliners. The scope is unusually precise, but the description never names the obvious sibling get_live_waits, so the agent must infer the distinction itself.

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?

Usage is only implied: the enumerated attraction list signals 'use this for major rides,' and 'live' signals a real-time fetch. There is no explicit when-to-use / when-not clause and no mention of get_live_waits as the broader alternative.

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