Parky — Park Planning

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds real value beyond them by disclosing that results are limited to Parky's current Disney and Universal release scope and that wait times are not returned. It does not say how matching behaves (exact vs. fuzzy), how ambiguity is returned, or what shape the result takes, which matters since there is no output schema.

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?

Four short sentences, front-loaded with the triggering condition, followed by the sibling exclusion, the scope constraint, and the non-capability. Every sentence carries routing or scoping information; there is no 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?

For a two-parameter, read-only lookup with full schema coverage and no output schema, the description covers purpose, routing, and domain scope well. The remaining gap is that it never indicates what a successful result contains (IDs plus names? a list of candidates?), which an agent would need to interpret an ambiguous match.

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%, so both parameters are already documented in the schema and a 3 baseline applies. The phrase 'names or describes a ride' hints that the query is matched loosely rather than as an exact ID, but the optional park_id narrowing parameter is never mentioned in the description, so no meaning is added 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 states a specific verb and resource: resolve a named or described ride/park to its Parky ID, plus check park coverage. It also explicitly separates this tool from 'park tools', which take a park name directly, so an agent can distinguish it from parky_list_parks or parky_get_park_ride without opening schemas.

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 a clear positive trigger (visitor names or describes a ride and you need the ID) and an explicit negative rule (skip this for park tools, which accept a park name directly), plus a scoping exclusion (no current wait times). The alternatives are described by category rather than named siblings like parky_get_waits or parky_list_parks, so routing is slightly inferential.

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

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

Annotations already declare readOnlyHint and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the 30-day horizon, park-local time, and the caveat that results are estimates rather than guarantees. It does not discuss rate limits, payload size, or what happens for dates outside the window.

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?

Three sentences, front-loaded with the trigger condition, then the prerequisite, then the return contents and caveat. The first sentence is dense but carries real information; nothing is redundant.

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?

There is no output schema, and the description compensates by enumerating the returned components and noting the park-local timezone and estimate caveat. For a two-parameter read tool this is nearly complete; only edge-case behavior (invalid ride, out-of-range date) is unaddressed.

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 both parameters are already fully documented, including the date range and ride ID sources. The description reinforces the 30-day constraint and the ride-resolution order but adds no syntax or format detail beyond the schema; 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?

States a specific verb and resource ('when to ride') and explains exactly what the tool produces: hourly predicted waits with bounds, weekday baselines, and best/worst windows. The word 'predicted' implicitly separates it from actual-wait siblings like parky_get_waits, but no sibling is named explicitly.

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?

Gives a clear triggering condition (a visitor asking when to ride to avoid long waits on a specific day) plus a hard prerequisite: 'Resolve the ride ID first.' It stops short of naming alternatives or when-not conditions, e.g. pointing to actual-wait or crowd-outlook tools for other questions.

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

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

Annotations already cover read-only, non-destructive and closed-world, so the bar is lower, but the description still adds real context: results are predictions sourced from Disney's own bus tracking (i.e., estimates, not guaranteed schedules), and omitting the stop switches the tool into a stop-listing mode rather than failing. It does not describe freshness, refresh cadence, or how far ahead predictions run.

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?

Three short sentences, front-loaded with the trigger condition, then the argument behavior, then the data provenance. Nothing is redundant and no sentence lacks a purpose.

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 single-optional-parameter read tool with annotations covering safety and no output schema, this covers trigger, parameter behavior and data source adequately. It leaves the return shape (e.g., whether times are grouped per destination park) implicit, which the missing output schema would otherwise have carried.

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 'Bus stop ID or name; a resort name works ... Omit to list the stops' semantics are already documented in the schema. The description restates the same stop/no-stop dichotomy without adding format, casing, or ambiguity-resolution detail beyond it, so 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 names a specific verb and resource: retrieving the next Walt Disney World bus departure from a resort or stop toward a park or Disney Springs. The purpose is unmistakable and clearly distinct from sibling tools covering waits, hours, crowds and showtimes, though it never names a sibling explicitly to route against.

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 opens with an explicit trigger ('Use this when a visitor asks when the next ... bus leaves'), which is stronger than most definitions, and it explains the no-argument path ('without one, it lists the stops'), giving the agent a discovery fallback. It stops short of stating when-not to use it or pointing to an alternative tool.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds that results are per-park and retrospective. It does not describe the return shape, the crowd scale, pagination, or how forecast-vs-actual comparison is surfaced, which matters because there is no output schema.

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 sentence, front-loaded with the trigger condition and zero filler. Both clauses (actual crowds, forecast accuracy) add distinct information.

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 two-parameter read tool this is nearly adequate, but the second advertised capability (forecast accuracy) is unexplained: with no output schema, an agent cannot tell whether the response includes prediction deltas, a crowd index, or raw values.

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 schema already documents park_id formats, the shorthand examples, and the 1-60 day window. The description only hints at the same concepts ('one supported park', 'recent days') without adding format or default detail, so the baseline of 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 names the specific resource (observed crowds at a single supported park over recent days) and a second capability (forecast-accuracy comparison). It distinguishes itself from the forecast sibling parky_get_crowd_outlook through the phrase 'actually was', though it neither states a verb directly nor names the sibling.

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 a concrete trigger ('when a visitor asks how crowded one supported park actually was on recent days') plus a secondary use case (checking forecast accuracy). There are no explicit exclusions or named alternatives, so an agent must infer when the forecast tool is preferable.

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

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

Annotations already declare read-only, non-destructive, closed-world behavior, so the bar is lower; the description still adds real value by framing the output as a forecast with a range rather than a guarantee. No output schema exists, and the forecast/no-guarantee caveat is the key behavioral nuance an agent needs.

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?

Two sentences with zero filler; the usage trigger is front-loaded and the disclaiming clause follows immediately. Nothing could be removed without losing meaning.

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 correctly characterizes the return as a forecast plus range. Combined with a fully documented schema and safety annotations, an agent has enough to invoke it correctly, though a pointer to the actuals/live-waits alternatives would close the last gap.

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%, with date, days, and park_id all fully documented in the schema, so the baseline is 3. The description reinforces the 30-day horizon and single-park scope but adds no format, default, or edge-case detail 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?

States a specific verb+resource (crowd forecast for one park) and scopes it to the next 30 park-local days. It implicitly separates itself from live/actual data ('not a guarantee or a live wait'), though it never names the siblings parky_get_crowd_actuals or parky_get_waits explicitly.

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?

Gives a clear trigger condition ('when a visitor asks how crowded one supported park may be') and an implicit exclusion via 'not a guarantee or a live wait'. It stops short of naming the alternative tool an agent should call for actuals or live waits.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that the description adds real behavioral context: a ~60-day coverage window and the explicit inability to transact tickets, which prevents an agent from promising a purchase. It stops short of describing the response shape in any detail.

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?

Two sentences: the first front-loads the use trigger, examples, and output content; the second carries the two constraints. There is no filler and no repetition of structured fields.

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 must carry return-value meaning, and it does at a high level (nights on sale or sold out, lowest price). What is missing is any hint of response structure (per-event grouping, per-night entries) and how the stated 60-day coverage interacts with the schema allowing a 'from' date up to 365 days ahead, a mild ambiguity an agent may hit.

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%, with resort keys/shorthands and date semantics fully documented in the schema, so the baseline applies. The description's 'Covers up to 60 days' loosely reinforces the from/to window but adds no syntax, format, or enumeration meaning beyond what the parameters already state.

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 and resource ('separately ticketed event nights'), names concrete examples (Mickey's Not-So-Scary Halloween Party, Jollywood Nights, Halloween Horror Nights), and enumerates the data returned (on-sale/sold-out status, lowest price). This lets an agent distinguish it from siblings like parky_get_ticket_prices or parky_get_hours without opening a schema.

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 an explicit trigger ('Use this when a visitor asks about separately ticketed event nights at a supported resort') plus a scope limit ('Covers up to 60 days') and a capability boundary ('Parky cannot sell tickets'). It does not name a competing sibling for general ticket pricing, so the routing guidance is clear but not fully comparative.

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

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

Annotations already establish read-only and closed-world safety, and the description adds genuinely new behavior: a 14-night window within 120 days, data freshness caveat ('as last checked'), a hard capability limit (no booking), and a response-size warning for long ranges. These are exactly the traits an agent needs before invoking it.

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?

Three sentences, front-loaded with the trigger condition and followed by hard limits and the size caveat; no filler or restatement of the title. Every clause carries information the agent cannot get from the schema or annotations.

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 three-parameter read-only tool with a fully described schema and no output schema, the description covers scope, time window, freshness, response-size risk, and the no-booking boundary. A brief hint at the shape of the returned data (per-hotel list vs single rate) would close the last gap.

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 selection heuristic not present in the schema ('ask for the fewest days you need; long ranges are large') and restates the combined date/days window. That is meaningful guidance on how to choose values, not just a repeat of the field docs.

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 concrete query ('which hotels at a supported resort have rooms on given nights, or their lowest rates'), which pins down both the resource (hotels) and the returned information (availability plus lowest rate). It implicitly separates itself from park-availability siblings by scoping to hotels, though it never names an alternative tool outright.

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 a clear trigger ('Use this when a visitor asks which hotels...') and an explicit boundary ('Parky cannot book hotels'), plus a practical constraint ('Ask for the fewest days you need'). What is absent is any explicit contrast with a sibling such as park or ticket pricing lookups, so the routing guidance is inferred rather than stated.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds genuine domain context beyond that — that Early Entry is an eligibility-based window rather than a separately ticketed event, and that schedules are reported and operator-changeable. That caveat materially affects how an agent should relay results. It does not discuss response shape or pagination, keeping it below the top score.

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?

Three sentences, front-loaded with the usage trigger, then two compact caveats that each carry real interpretive value. Nothing is redundant with the schema or annotations.

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 read-only three-parameter tool with full schema coverage and no output schema, the description supplies the key interpretive context: guest-facing window categories and the eligibility nature of Early Entry. What a returned schedule record actually contains is only gestured at, which is the one remaining gap.

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%, with date, days and park_id each documented including the 60-day bound and accepted park_id formats. The description adds nothing about parameter syntax or interaction beyond what the schema already states, so the baseline of 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 names a specific verb and resource ('operating hours for one supported park') plus an explicit scope ('within the next 60 park-local days'), which separates it from siblings such as parky_get_showtimes or parky_get_park_conditions. It does not name an alternative tool outright, so it falls just short of the top band.

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?

'Use this when a visitor asks about operating hours' gives a clear trigger condition, and the 60-day horizon bounds when the tool is applicable. No explicit when-not condition or named alternative is offered, so the routing guidance is clear but not exhaustive.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, not open-world), so the description focuses on what those annotations cannot convey: data windows ('return times exist only for today; prices cover the next 30 park-local days') and the no-purchase limitation. It does not describe response shape or whether a full ride list is returned when ride_id is omitted.

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?

Three short sentences, front-loaded with the trigger condition and ending with the key limitation. Every sentence carries distinct information with no restated schema details in the body.

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 read-only, three-parameter lookup with no output schema, the description covers the essential decision inputs: what data exists, over what time horizon, and what the tool will not do. The one remaining gap is return-value expectations, e.g., whether omitting ride_id yields a ride-by-ride list.

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%, so the date window and park_id shorthand guidance are already documented in the schema. The description echoes the same date-window fact rather than adding new meaning, and says nothing extra about ride_id beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ('what Lightning Lane (or Universal Express) costs' and 'which rides have Lightning Lane return times available'), scoped to 'one supported park on a date'. This clearly separates it from sibling tools like parky_get_ticket_prices and parky_get_waits without needing to name them.

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?

Explicit trigger conditions are given: a visitor asking about cost on a date, or about current return-time availability and how soon. It also states a capability boundary ('Parky cannot buy or book Lightning Lane'), which is a useful when-not signal. No alternative sibling tool is named for standby waits or general ticket pricing, so routing is implied rather than fully specified.

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

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

Annotations already establish readOnly, non-destructive, closed-world behavior, so the description's job is to add context — which it does by disclosing that results are broken out by segment and that long ranges produce large responses. It does not say how 'no availability' is represented, which is the main remaining gap.

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?

Three sentences, front-loaded with the usage trigger, then the return shape and limit, then the practical advice. Every sentence carries distinct information and there is no 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?

With no output schema, the description must sketch the return value, and it does (availability by segment for up to 31 days). It covers enough for a read-only lookup tool, though the absent/available states of the response are not described.

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; the description adds operational meaning for the days parameter by framing it as a response-size tradeoff ("Ask for the fewest days you need; long ranges are large"). The date range and resort formats are left entirely to 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 verb+resource is specific: it returns reservation/blockout-date availability for a ticket or pass type on given dates at a resort. That is clearly distinct from siblings like parky_get_ticket_prices, parky_get_hours, or parky_get_event_nights, though no sibling is named explicitly to force the contrast.

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?

"Use this when a visitor asks whether a park has reservations or blockout dates..." gives a concrete trigger condition an agent can match against a user question. There is no explicit when-not guidance or named alternative tool, so it stops short of full routing instruction.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely non-structured context: the weather source is the National Weather Service's latest observation and alerts, and the data is current conditions rather than a forecast, which prevents a common misuse.

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?

Two sentences with zero filler: the trigger condition comes first, and the data-source/currency clarification follows. Every clause earns its place.

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 single-parameter, read-only tool with no output schema, the definition covers the trigger, the data source, and the currency semantics. It leaves the response shape implicit (what exact weather fields and alert structure come back), but nothing essential to calling it correctly is missing.

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 park_id field already documents accepted keys, canonical IDs, names, and shorthands in detail. The description adds only the constraint of 'one supported park', which is marginal beyond what the schema provides, so the 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 states a concrete resource set: weather, storms, heat, lightning, weather alerts, and the count of downed rides at one park. That is specific enough to distinguish it from siblings like parky_get_waits or parky_get_crowd_actuals, but it never names a sibling, so an agent must infer that parky_get_ride_outages handles per-ride outage detail.

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?

The opening clause 'Use this when a visitor asks about...' gives an explicit, concrete trigger list, including the 'right now' temporal constraint. It stops short of stating when NOT to use it or naming the alternative tool for forecasts and per-ride outage history.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral fact — output parity with parky_get_ride_facts — but says nothing about what happens when the ride name is ambiguous within the park or absent from it, and offers no return-shape hint (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?

A single sentence with the selection condition front-loaded before the mechanics, so the agent can stop reading once it recognizes the scenario. Slightly dense but free of 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?

For a two-parameter read tool with full schema coverage and complete annotations, the definition supplies the selection rationale and output expectation. The only soft spot is that 'same answer as parky_get_ride_facts' depends on the agent knowing that sibling, and error/not-found behavior is unstated.

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 both parameters are documented in detail, including accepted park shorthands and where ride IDs come from. The description's mention of ID, name or slug resolution merely restates what the schema already spells out, so 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 ('finds the ride by ID, name or slug within one park') and frames the disambiguating scenario where a ride exists at multiple parks, which separates it from the park-wide siblings. The trailing clause 'returns the same answer as parky_get_ride_facts' is a little ambiguous about why the tool exists separately, but the core purpose is unmistakable.

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 an explicit trigger: use when a visitor names a ride that exists at more than one park, and it names the sibling whose output it mirrors. It stops short of stating the negative case (use parky_get_ride_facts when the ride is unambiguous), so the agent must infer the routing rule rather than read it.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes something the annotations do not: it enumerates the returned fields (parks, time zone, aliases), which is valuable precisely because no output schema exists. It says nothing about behavior for an unknown or ambiguous resort key, which is the remaining gap.

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?

A single front-loaded sentence with a use-condition and the return content, with no filler or repetition. Every clause carries information.

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 one-parameter read tool with full annotation coverage, the description plus the rich schema description is nearly sufficient, and listing the returned fields compensates for the missing output schema. Only the error/ambiguity behavior for an unrecognized resort name is left unspecified.

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 description already lists example keys, canonical IDs, names and shorthands (wdw, dlr, uor, ush). The description adds no additional meaning about accepted input formats, so the schema does all the work here.

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 specific resource (one resort) and enumerates what it returns: parks, time zone and aliases. The word "one" implicitly separates it from parky_list_resorts, but no sibling is named explicitly, so differentiation is inferred rather than stated.

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?

The phrase "Use this when you need one resort's..." gives a clear triggering condition for the tool. It stops short of stating when not to use it or naming parky_list_resorts as the alternative for enumerating multiple resorts, so exclusions are absent.

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

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

Annotations already cover safety (readOnly, non-destructive, closed-world), so the marginal bar is low, and the description adds real value: it discloses that facts vary by ride and missing facts are omitted rather than guessed, and that live wait / 30-day reliability are conditional ('when available'). It does not describe units or formatting of returned facts, but the partial-response behavior is the important disclosure and it is present.

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?

Four short sentences, squarely front-loaded: trigger first, payload contents second, conditional fields third, and the no-guessing caveat last. No sentence restates the title or the parameter schema without adding context.

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?

No output schema exists, so the description must carry the return-value burden, and it does so by enumerating the fact categories plus the two dynamic fields and flagging that responses are partial. Combined with the single well-documented parameter and the read-only annotations, an agent has everything needed to call this correctly.

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 basline would be 3; the description earns the extra point by adding the 'resolve the ride ID first' prerequisite, which tells the agent to obtain the ID from a discovery tool rather than fabricate one. The name-or-slug fallback is already handled in the schema, so no further credit there.

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?

Names a specific resource (a ride's static facts) and enumerates the exact attributes returned: height requirement, ride length, top speed, biggest drop, ride type, land, Lightning Lane, plus live wait and 30-day reliability. That enumeration lets an agent separate it from wait-focused or history-focused siblings without opening the schema.

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?

Opens with an explicit trigger ('Use this when a visitor asks about a ride itself') and gives a prerequisite workflow step ('Resolve the ride ID first'). It stops short of naming when NOT to use it — e.g. that pure wait-time questions belong to parky_get_waits and outage questions to parky_get_ride_outages — which matters because this tool overlaps those domains.

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

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

Annotations already declare this a safe, read-only, closed-world read, so the description does not need to restate safety. It instead adds genuinely non-obvious data semantics: rows are emitted only on change, so a wait value carries forward until the next row, which changes how an agent must interpret results.

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?

Three short sentences, front-loaded with the usage trigger, then the prerequisite, then the result-shape caveat. Every sentence adds information and none repeats the schema or annotations.

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 two-parameter read tool with no output schema, the description covers the trigger, the prerequisite, and the shape of returned data well enough to call it correctly. It stops short of describing what fields a row contains (timestamp, wait, status), which matters slightly more given no output schema exists.

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 both ride_id and days are already documented including the 1-7 bound and default. The description reinforces the ride ID resolution step but never mentions the days parameter or how the 'last week' framing relates to its configurable window.

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 concrete verb and resource: how a ride's posted wait moved over the last week, which is clearly a historical series rather than a snapshot. It implicitly contrasts with the current-wait tools but never names a sibling such as parky_get_waits or parky_get_ride_reliability, so differentiation is left partially to inference.

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 a clear trigger condition (a visitor asks how a wait moved over the last week) plus a prerequisite step (resolve the ride ID first). There is no explicit when-not guidance or named alternative for adjacent questions like best time to visit or reliability.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes beyond them by disclosing the returned content (start and end times), the mode-dependent scope (per-ride history vs. park-wide today, including rides currently down), and the implicit fact that 'today' overrides the days window. It says nothing about result volume, limits, or behavior when a ride has no outages, so it is not fully complete.

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?

A single sentence that front-loads the usage trigger and then cleanly splits into the with-ride_id and without-ride_id branches. Every clause carries information; no filler or restatement of the title.

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 correctly compensates by describing the return shape (outages with start and end times) and the two result scopes. For a simple three-parameter read tool that is nearly sufficient, though it omits empty-result behavior and any indication of how far back the park-wide 'today' query can reach.

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 real meaning the schema does not: omitting ride_id switches the entire semantics to park-wide 'today' outages, and the days window only applies in the per-ride branch. That mode-switching framing is the most important parameter insight here and it is stated in plain language.

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 specific resource (ride outages) and explains both operating modes: per-ride outage history with start/end times when ride_id is given, and park-wide outages for today when it isn't. It is distinguishable from broadly named siblings like parky_get_ride_history and parky_get_ride_reliability by the 'broke down' framing, but it never explicitly contrasts itself with those tools, so it stops short of a 5.

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 an explicit trigger ('when a visitor asks whether or when a ride broke down'), which is exactly the kind of visitor-question framing an agent needs. There are no when-not conditions and no named alternatives for adjacent questions (e.g., overall reliability vs. specific outages), leaving some routing to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. Beyond that, the description adds genuinely useful behaviour: a 30-day measurement window, the specific metrics returned, and the sort order. It does not say how missing or sparse outage data is handled, which is the main residual gap.

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?

Two sentences, zero waste: the trigger condition leads and the payload description follows. Every clause carries either usage or return-value information, and nothing repeats the annotations or 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 must explain return values and does so by naming the three metric families and the ordering. For a read-only two-parameter reporting tool this is close to sufficient; only the handling of parks or rides with no outage history is left unstated.

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 park_id description is unusually thorough (accepts keys, canonical IDs, names, and shorthands with no lookup). The tool description itself adds no parameter meaning; the only extra information, 'least reliable first' ordering, describes output rather than input. Baseline 3 applies since the schema does the work.

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 uses a concrete verb-plus-resource ('Returns 30-day uptime percentage, outages per day, and average and longest outage') and frames the resource as ride reliability, which an agent can distinguish from a raw outage list. It does not name the neighbouring parky_get_ride_outages or parky_get_ride_history tools, so the distinction is inferred from the aggregate 30-day framing rather than stated.

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?

'Use this when a visitor asks how often a ride breaks down or which rides at a park are least reliable' gives a clear trigger condition tied to user intent. It stops short of exclusions — it never says to use the outage-list or history siblings for raw event detail — so the agent must infer that boundary.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety and scope are covered. The description adds one genuinely useful behavioral fact, that times are usually only published for today, which sets expectations about sparse future data. It stops there, saying nothing about the shape of results or what an empty response means.

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?

Two sentences, with the triggering condition front-loaded ahead of the availability caveat, and no redundant restatement of the tool name or parameters. Every sentence carries distinct information.

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 two-parameter read tool with full schema coverage and annotations, the description covers purpose, trigger, time window and a data-availability caveat, which is close to sufficient. The one real gap is the absence of any output schema, so the description should hint at what comes back (show names, times, venue), which it does not.

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%, and the park_id field already enumerates accepted keys and shorthands while date documents the today-through-6-days range. The description's 'at one supported park today or within the next week' merely restates that range, adding no syntax or format meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 resource set (shows, parades, fireworks, character meets) and the verb 'when ... happens', which is meaningfully distinct from sibling tools like parky_get_hours or parky_get_waits. It stops short of naming any sibling explicitly, so an agent must infer the boundary (e.g. vs. parky_get_best_time or parky_find_experience) on its own.

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?

'Use this when a visitor asks when a show, parade, fireworks or character meet happens' gives a clear, quotable triggering condition rather than vague context. It also scopes the acceptable window ('today or within the next week'), but names no alternatives or when-not conditions, so there is no explicit routing guidance against overlapping siblings.

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

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower, and the description still adds real context: prices are what the operator 'showed Parky on its last check', disclosing staleness/caching, plus the explicit no-booking capability boundary. It does not say what happens when the resort is unsupported or the date falls outside the 365-day window, so behavior at the edges is still undisclosed.

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?

Three short sentences, front-loaded with the trigger, then the return semantics, then the capability limit. Nothing is redundant and every clause constrains how the tool should be used.

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 the return, and it does say the result is the last-checked price rather than a live quote. It stops short of indicating what a price record contains (ticket tiers, adult/child, per-day versus per-ticket), which is the remaining gap for a two-parameter lookup.

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 the date format, time zone, default of today, and the resort key/shorthand options, so the description does not need to repeat them. It reinforces the one-year window and the resort vocabulary, which is mild corroboration rather than new meaning — baseline 3.

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?

States a specific verb and resource ('what park tickets cost'), names the supported resorts explicitly, and bounds the date range to the next year. No sibling tool covers ticket pricing, and the description makes that distinct scope obvious without opening the schema.

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?

Opens with an explicit trigger condition ('Use this when a visitor asks...') plus the two constraints that qualify a valid request: supported resort and start date within the next year. It also states an exclusion — Parky cannot sell or book — which steers the agent away from promising a purchase flow.

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

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.

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

Annotations already declare readOnlyHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing the data-fidelity behavior: facts vary per ride and missing facts are omitted rather than guessed, which tells the agent not to treat absence as a negative answer. It says nothing about result size or pagination, keeping it below a 5.

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?

Two sentences, no filler, with the primary use case front-loaded and the caveat about missing facts placed after it. Every clause carries information an agent can act on.

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 one-parameter read-only list tool with annotations and no output schema, the description covers when to call it and how to interpret gaps in the returned facts. It does not sketch what a ride entry contains beyond the comparison attributes, which leaves a small gap, but nothing essential to invocation is missing.

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?

There is a single parameter at 100% schema coverage, and the schema description already enumerates accepted forms (key, canonical ID, name, shorthand examples), so the description need not repeat it. The phrase 'one supported park' hints that unsupported parks are rejected, but no additional syntax or format meaning is added, making the baseline 3 correct.

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 specific verb and resource: returning every ride at one supported park, and it enumerates the comparable attributes (height requirement, length, speed, Lightning Lane). This separates it in spirit from the single-ride sibling parky_get_park_ride, though it never names that sibling, so the differentiation is implicit rather than explicit.

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 a clear triggering condition: use when a visitor wants all rides at one park, or wants to compare rides along the listed dimensions. There is no explicit when-not guidance or named alternative (e.g. for a single ride use parky_get_park_ride), so it stops short of the top band.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the shape of each returned record (key, time zone, Parky page), which matters because no output schema exists. It does not mention ordering, pagination, or caching, which keeps it below a 5.

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?

A single front-loaded sentence that states the trigger condition first and then the payload. Nothing is redundant or padded.

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 no-parameter, read-only listing tool with no output schema, the description supplies the essential information: the trigger, the scope (every park), and the fields returned. Only minor operational details such as result ordering or whether the list is paginated are absent.

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 tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to get wrong. The description's mention of returned fields is a bonus rather than a schema substitute.

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 specific verb (list) and resource (parks) and even enumerates what each entry contains (key, time zone, Parky page). That clearly separates it from siblings like parky_list_resorts and parky_list_park_rides, though it never explicitly contrasts with them.

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?

"Use this when you need every park Parky supports" gives a clear trigger condition for calling the tool. There are no exclusions or named alternatives, but for an unfiltered enumeration tool the selection decision is essentially trivial.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful context about what is returned (key, time zone, parks) but says nothing about result size, ordering, or caching, so it only modestly exceeds the annotation baseline.

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?

A single sentence that front-loads the usage trigger and then the payload contents; every clause carries information and there is no 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?

With no output schema, the description correctly compensates by naming the fields returned (key, time zone, parks). For a zero-parameter read-only listing this is nearly complete; only ordering or result-size expectations are unstated.

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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it is an unfiltered full listing. Baseline 4 applies for a parameterless tool.

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 ('list') and resource ('every resort Parky supports') and even previews the returned fields (key, time zone, parks), so the agent knows exactly what it gets. It does not explicitly contrast itself with the singular sibling parky_get_resort, but the 'every resort' phrasing makes the bulk-listing intent 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?

'Use this when you need every resort Parky supports' states the triggering condition clearly, which distinguishes it in practice from parky_get_resort and the park-specific parky_list_parks. No explicit exclusion or named alternative is given, so it stops short of the top score.

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