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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds only the forward-looking time window ('from today forward') and the home-park default — useful but minimal context beyond the structured fields; nothing about freshness, caching, or how closures are represented.

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 with no filler: what it returns, the time window, the default, and the planning use case, all front-loaded. Every clause earns its place and nothing is repeated 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 parameterless-required, read-only lookup with no output schema, the description tells the agent what comes back (open/close times), the temporal range, and the default target. Nothing an agent needs in order to call 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 description coverage is 100%, so both 'days' and 'park' are fully documented in the schema, and the description matches the schema's default-park note without adding range or format detail. Baseline 3 is appropriate when the schema carries the parameter burden.

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 pair ('Get operating hours (open/close times) for a Six Flags park') with the added temporal scope 'from today forward'. The resource is inherently disjoint from every sibling (wait times, shows, attractions, park list), so an agent can route here without ambiguity, though 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 concrete use case ('plan what time to arrive and how long you have') and discloses the default-park behavior, which is a real selection signal. It stops short of stating when NOT to use it or pointing to a complementary sibling like sixflags_get_wait_times for same-day planning.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuine operational context beyond that: the default to the home park (Carowinds) and the caveat that showtimes are only populated on operating days, which pre-explains empty results. It stops short of 5 because it says nothing about coverage scope or what happens outside operating days.

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, front-loaded with the core action and result, followed by the default and the operating-day caveat. Every clause carries information; nothing is padding.

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, so the description carries return-value burden; it names the payload ('showtimes') and the show categories, and flags the operating-day condition that determines whether results exist. That is sufficient for a single-optional-param read tool, though it could say more about the shape of a showtime entry.

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?

With a single optional parameter and 100% schema description coverage, the schema fully documents 'park' (name, slug, or id, defaults to home park). The description restates the same default without adding format, resolution-order, or invalid-park behavior, so baseline 3 is appropriate.

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 ('Get today's live show schedule (showtimes)') and enumerates the content types covered — parades, stunt shows, character meets. That content scoping implicitly separates it from siblings like sixflags_get_park_schedule and sixflags_list_attractions, but it never names or contrasts an alternative explicitly, so it falls short of the 5 bar.

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 implied rather than stated: the agent can infer it should call this when it wants showtimes, and the note about the default home park clarifies the no-argument case. However, there is no explicit when-to-use/when-not guidance and no named alternative (e.g., get_park_schedule for broader scheduling), which the closely-related sibling makes a real gap.

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 readOnly/idempotent/openWorld, so the safety profile is handled. The description goes beyond them by disclosing sort order (longest-wait first), the status vocabulary (operating/closed/down), the presence of standby + single-rider waits, and an aggregate crowd-level summary — useful output-shape context not available in annotations or 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?

A single dense sentence that front-loads the core action before detail, with no filler. Slightly over-packed (statuses, two wait types, sorting, crowd summary in one breath) but 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?

With no output schema, the description carries the burden of describing return values and does so well: per-attraction status plus standby/single-rider waits, ordering, and a crowd-level summary. An agent knows what it will get and how to constrain it via openOnly.

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 documented with defaults. The description restates the park default and that closed/down rides are included by default, which is mild reinforcement rather than new meaning — baseline 3 is appropriate.

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 ('Get current ride wait times for a Six Flags park') and clearly separates itself from siblings like sixflags_list_attractions by emphasizing live waits and status. The default-home-park behavior is stated up front.

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 word 'current' implies the when (live conditions rather than schedules or attraction metadata), and the Carowinds default gives context. However, it never explicitly names an alternative (e.g. sixflags_get_park_schedule or sixflags_list_attractions) or states when not to use it, leaving 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 readOnly, openWorld, and idempotent, so the safety profile is covered. The description adds genuinely new context: the upstream dependency (themeparks.wiki) and the return shape (ok/degraded plus park count), which is valuable given 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?

Two tight sentences: the check is front-loaded, followed by the return contract. No filler and nothing repeated 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 zero-param read-only probe with no output schema, the description covers the dependency, the possible status values, and the returned count. It could add guidance on interpreting 'degraded' or on how often to poll, but nothing essential 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?

Zero parameters, so per the rubric the baseline is 4. There is nothing further to document beyond confirming the tool is called with no arguments.

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 (check) and resource (upstream data source themeparks.wiki reachability plus Six Flags park data), and clearly distinguishes itself from the data-fetching siblings like sixflags_list_parks and sixflags_get_wait_times.

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 diagnostic nature of a healthcheck implies when it is useful, but the description never says when to call it (e.g., before other tools, on error, for troubleshooting) or how it relates to the sibling tools. Usage is only implied.

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, idempotentHint and openWorldHint, so safety is covered. The description adds genuinely useful context beyond that: this returns static metadata, not live status, and includes map coordinates — telling the agent the data can be stale by design.

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 compact clauses: what it lists, what it is not (with the alternative), and the default park. The scoping and routing information is front-loaded with 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, optional-argument list tool with rich annotations, the description covers purpose, data freshness, routing, and a hint at the return payload (map coordinates). With no output schema, a slightly fuller note on the returned fields would make it complete.

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 (park, type) are already documented, including the enum values for type. The description restates the home-park default but adds no syntax or format detail beyond the schema, 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 gives a specific verb and resource ('List the attractions... at a Six Flags park') and scopes it as the full directory with map coordinates. It distinguishes itself from sibling sixflags_get_wait_times by framing the output as static metadata rather than live status.

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 explicitly names the alternative for live data ('use sixflags_get_wait_times for current waits') and states the default park behavior. It does not address the apparent overlap with sibling sixflags_get_shows for the SHOW entity type, which is the one real routing ambiguity left.

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 readOnly, idempotent, and openWorld, so the safety profile is covered. The description goes beyond them by disclosing the return payload (id, name, owning destination) and the side behavior that the caller's configured home park is flagged, which is real context the annotations do not carry. It says nothing about rate limits or auth, so not 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?

Front-loaded with the verb and resource, then scope, then filter, then return shape—every sentence earns its place. The parenthetical park examples are slightly long but serve disambiguation, keeping it just short of a 5.

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 covers the return fields itself, which is the main gap it needed to fill. Remaining omissions (result ordering, pagination, or whether results can be empty) are minor for a small finite park 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% for the single 'search' parameter, so the schema already defines it as a case-insensitive substring. The description only restates the optional-substring filter and is slightly narrower than the schema, which also covers destination names. Baseline 3 for schema-driven parameters.

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 + resource ('List Six Flags parks') with the scope pinned down: the combined Six Flags/Cedar Fair chain, with named examples spanning parks and the Hurricane Harbor water parks. This lets an agent distinguish it from siblings like sixflags_list_attractions or sixflags_get_wait_times, which operate within a single park.

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 implied rather than stated: this is the entry-point lookup that a park-scoped sibling (list_attractions, get_wait_times) would depend on, and the optional substring filter is noted. There is no explicit when-to-use/when-not guidance or named alternative, so it stays at implied usage.

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, idempotentHint, and openWorldHint, so safety is covered; the description adds real behavioral detail beyond that: only currently-operating rides are considered, ranking is by standby wait, and the park defaults to the home park (Carowinds). It does not disclose return shape or how stale the underlying wait data may be, which for a live-crowd recommendation tool would be useful.

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 core action and its ranking rule before the usage tip and the default park. The middle sentence is mildly promotional but earns its place by conveying repeat-call semantics; there is no padding.

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 recommendation tool with no output schema, the description covers the action, ranking basis, filters, repeat-usage pattern, and the default park. The main gap is the shape of the response (e.g. ordered list of rides with waits), which an agent might want since no output schema is provided.

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 all four parameters are already documented in the schema, and the description largely restates them ('exclude rides you've already done and cap the wait' mirrors the schema's exclude and maxWaitMinutes descriptions). It adds no format or syntax detail beyond the schema, making the baseline 3 appropriate.

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 ('Recommend which attraction to ride next') and immediately specifies the ranking criterion ('ranks currently-operating rides by shortest standby wait'). This clearly separates it from data-fetching siblings like sixflags_get_wait_times or sixflags_list_attractions, which return raw data rather than a ranked recommendation.

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 repeatedly through the day to keep hopping to the lowest-wait ride' gives clear situational context for when to invoke it. It does not, however, name the alternative raw-data tools (get_wait_times, list_attractions) or state when NOT to use this tool, so it stops short of explicit routing.

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