Skip to main content
Glama

SupaPark — Walt Disney World live data

Lightning Lane Multi Pass price

get_multi_pass_price
Read-only

The Lightning Lane Multi Pass price for a Walt Disney World park on a given date (defaults to today).

Input Schema

NameRequiredDescriptionDefault
dateNoYYYY-MM-DD; defaults to today.
parkYesPark to price.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is already covered and the description does not contradict it. The description adds no extra behavioral context beyond the date default, such as whether the price is date-dynamic or subject to availability; with annotations present, this is adequate but thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the resource named first and the qualifying scope immediately after; nothing is wasted, though it is short enough that it earns no special credit for structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a trivial two-parameter read tool with no output schema, the description conveys the resource, the scoping inputs, and the default well enough to invoke correctly. The missing pieces are the returned price's format/currency and the distinction from get_lightning_lane_prices, both minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both parameters carry descriptions and 'park' has a full enum. The description's mention of the date default merely restates what the schema already says, adding no new semantic detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (the Lightning Lane Multi Pass price) scoped to a Walt Disney World park and date, which is concrete and unambiguous. It does not, however, differentiate itself from the sibling get_lightning_lane_prices, leaving the boundary between the two to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical '(defaults to today)' gives a small practical hint, but there is no when-to-use guidance, no prerequisites, and no routing to or away from the sibling get_lightning_lane_prices that clearly overlaps in topic.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources