Skip to main content
Glama

Create a route alert

create_itinerary

Watch a MULTI-NIGHT TRAVERSE — a trip needing a different zone each night, which create_alert cannot express. Use this whenever the user describes moving camp: 'four nights across the Rockwall', 'the Skyline end to end'.

TWO WAYS TO SPECIFY IT:

  1. PLANNED (prefer this). Call list_routes, pass the chosen variant's id as route_id, and OMIT nights — they are filled in from the route. park_id comes with it too.

  2. CUSTOM. Pass nights yourself: an ordered list, one entry per night, each naming a campground_id and the zone site_ids that would satisfy it. A night's site_ids are an OR-set — 'night 2 can be Numa Creek OR Tumbling Creek' is one alert, not two. 'all' is refused: a route needs explicit zones.

THE WINDOW IS A SEARCH WINDOW, not the trip. Every start day between window_start and window_end is tried, so a wider window is more chances to fire. It must span at least as many days as the route has nights, or nothing could ever match.

A route counts as ONE alert against quota however many nights it runs, and its legs never appear in list_my_alerts.

REFUSALS ARE INFORMATIVE, not retryable. A custom route can be refused as not walkable (non-adjacent zones), as mixing accommodation types that are booked separately, or as mixing single-permit traverses — a permit is one booking for the whole trip. Re-sending the same nights will be refused again: offer a planned route, or nights the provider can actually sell together.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nightsNoCustom route only. Ordered, one per night; omit when passing route_id.
park_idNoRequired for a custom route; implied by route_id.
route_idNoA variant id from list_routes. Supplies the nights and the park, and skips the adjacency check.
tent_padsNoParks Canada zone backcountry: pads the party needs. Feeds the capacity gate on every night.
notify_smsNoPro tier only, needs a verified phone, and it is the one channel that costs real money per send — it stays off unless the user has asked for texts.
party_sizeNoPeople in the party. Where inventory is per bed or per person (huts, some backcountry zones) an opening must fit this many.
window_endYesYYYY-MM-DD — latest day the trip may still be running. Must leave room for every night.
notify_pushNoSend a push notification to the account holder's phone when something opens.
notify_emailNoPaid tiers only; silently dropped otherwise.
window_startYesYYYY-MM-DD — earliest start day to try.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
legsNo
nightsNo
park_idNo
providerNo
route_idNo
is_activeNo
park_nameNo
tent_padsNo
created_atNo
notify_smsNo
party_sizeNo
scan_countNo
window_endNo
booking_urlNo
created_viaNo
notify_pushNo
open_routesNo
notify_emailNo
window_startNo
last_checked_atNo
created_by_agentNo
last_notified_atNo
notification_countNo
distinct_zone_countNo
availabilities_foundNo
night_openings_latestNo
night_openings_recentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / notify_push / description
      Added value: +"Send a push notification to the account holder's phone when something opens."
    • addedInput schema / properties / party_size / description
      Added value: +"People in the party. Where inventory is per bed or per person (huts, some backcountry zones) an opening must fit this many."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare it is a non-read, non-destructive, non-idempotent, open-world writer, but the description adds traits annotations cannot carry: the window is a search window rather than the trip itself, a route counts as one alert against quota, its legs never surface in list_my_alerts, and refusals are non-retryable. That is material behavior a caller needs before invoking.

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?

Front-loaded with the core distinction and split into labeled sections (two ways, window, quota, refusals) so nothing important is buried. It is on the long side with heavy capitalization and emphasis, but nearly every sentence carries decision-relevant information rather than filler.

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

Completeness5/5

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

For a 10-parameter, open-world mutation tool with an output schema covering returns, the description supplies exactly the missing pieces: the two invocation modes, window semantics, quota accounting, notification cost caveats, and refusal behavior. Nothing an agent needs to call it correctly is absent.

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

Parameters4/5

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

Schema coverage is 100% and the per-field descriptions are already strong (OR-set site_ids, notify_sms cost, inventory-matching party_size). The description still adds real meaning the schema lacks: the planned-vs-custom decision, that nights are omitted when route_id is given, and that route_id skips the adjacency check.

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

Purpose5/5

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

States a specific resource and scope ('a MULTI-NIGHT TRAVERSE — a trip needing a different zone each night') and explicitly distinguishes itself from the sibling create_alert, which 'cannot express' this. An agent can route between this and create_alert without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('use this whenever the user describes moving camp' with quoted examples), then ranks the two specification modes with 'PLANNED (prefer this)', and names the fallback when a custom route is refused. Alternatives, preferences, and failure handling are all spelled out.

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