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

Annotations already declare readOnlyHint and non-destructive, so safety is covered. The description adds real behavioral detail beyond that: the entry type taxonomy, that rides are always listed and reported as 'unavailable' rather than 'closed' when there is no live value, and that experiences/shows/meets appear only while reported. That is genuinely useful for interpreting results, though field-level return shape is still unstated.

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?

Front-loaded with the use case, then structured as a scope statement, a parameter note, a return-shape note, and an exclusion. Some of the park enumeration is padding, but no sentence is wasted overall.

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 return-value explanation and does so at the entry-type level, which is what an agent needs to reason about the response. It never mentions the optional ride_id parameter's effect, which is a minor gap for a two-parameter 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% and the schema already documents park_id shorthands and the optional ride_id. The description only reiterates that a park name can be passed directly with no lookup, adding convenience but no new meaning. Baseline 3 applies.

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 gives a specific verb and resource ('current posted waits') scoped to Disney/Universal parks and enumerates example parks. It also explicitly distinguishes itself from predictive siblings by stating 'This tool does not predict future waits', which separates it from parky_get_best_time and similar 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 states the triggering user questions ('current wait times, how long the lines are, what is open or down') and gives an explicit exclusion for future-wait prediction. It does not name sibling tools directly, so routing to parky_get_ride_outages or parky_get_showtimes is left implicit.

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