Skip to main content
Glama

outdoorithm

by io.github.outdoorithm
OverviewDiscussionsAdmin

Prepare Reservation

prepare_reservation
Read-only

Prepare a one-tap booking handoff for the user's chosen campground/dates.

Returns a pre-filled deep link to the operator's reservation page plus the booking-window context (release date/time, ToS-compliant guidance, alert suggestion) the agent needs to advise the user. Does NOT book on behalf — third-party booking is prohibited by Recreation.gov, ReserveCalifornia, ReserveAmerica, and every other supported public-land operator.

Pair with check_availability first to confirm the dates are reservable and to surface site-specific booking_url values when available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_dateYesCheck-out date (YYYY-MM-DD).
party_sizeNoOptional group size. Surfaced in the user-facing summary; most operators don't accept this in URL params, so it isn't embedded in the deep link.
start_dateYesCheck-in date (YYYY-MM-DD).
campground_idYesOutdoorithm CUID (e.g. ``RecreationDotGov:232447``).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / campground_id / description
      Added value: +"Outdoorithm CUID (e.g. ``RecreationDotGov:232447``)."
    • addedInput schema / properties / end_date / description
      Added value: +"Check-out date (YYYY-MM-DD)."
    • addedInput schema / properties / party_size / description
      Added value: +"Optional group size. Surfaced in the user-facing summary;\nmost operators don't accept this in URL params, so it isn't\nembedded in the deep link."
    • addedInput schema / properties / start_date / description
      Added value: +"Check-in date (YYYY-MM-DD)."
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by stating the tool does not actually book (citing third-party booking prohibitions) and returns a deep link plus booking-window context, which are useful beyond the annotation hints.

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

Conciseness5/5

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

The description is concise and front-loaded, starting with the main purpose and then explaining return value and usage pairing. Every sentence adds meaningful detail; no wasted words.

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?

The tool has an output schema, so return values need not be elaborated. The description supplies crucial context: it never books, it provides ToS-compliant guidance, and it should be used after check_availability. This is complete for the tool's complexity.

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%, with each parameter including meaningful descriptions (e.g., 'Check-out date (YYYY-MM-DD)', 'Optional group size...'). The tool description itself does not add parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.

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?

The description clearly states it 'prepares a one-tap booking handoff' for chosen campground/dates, with a specific verb and resource. It distinguishes itself from siblings by explicitly noting it 'does NOT book on behalf' and by referencing 'check_availability' for pre-confirmation.

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?

The description provides explicit usage guidance: 'Pair with check_availability first to confirm the dates are reservable' and specifies when not to use it ('Does NOT book on behalf'). It also names a specific alternative tool, satisfying the when/when-not/alternatives requirement.

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

All outdoorithm toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources