Skip to main content
Glama

Booking link for a permit or campground

get_booking_link
Read-onlyIdempotent

Returns the link to the official booking page for one US backcountry permit or one campground. For some permits the link also carries the first date and the number of people you give, but the booking site may not use them, so the person checks or picks the dates and group size on that page. For a campground, the person picks or checks the dates on the booking page. For some places it returns the agency's own page or the PermitSnag page instead of a booking page. It only returns a link and a sentence about it; it does not book, pay or enter a lottery.

Input Schema

NameRequiredDescriptionDefault
permitNoThe permit id or slug. Give this or campground, not both.
endDateNoOptional last date, YYYY-MM-DD. Sent in the link for a few booking sites; the site may ignore it.
partySizeNoOptional number of people. Sent in the link for some permit booking sites; the site may ignore it.
startDateNoOptional first date, YYYY-MM-DD. Sent in the link for some booking sites; the site may ignore it.
campgroundNoThe campground id. Give this or permit, not both.

Output Schema

NameRequiredDescriptionDefault
urlNoThe page to open.
foundNoPresent, and false, only when nothing matched.
subjectNo
datePrefillNoWhether the asked date reaches the booking page.
destinationNo
executesNothingNoThis tool only returns a link.
providerHomeUrlNoPermits only: the booking site's front page, when that is all we can name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / endDate / description
      Previous value: -"Optional last date, YYYY-MM-DD."New value: +"Optional last date, YYYY-MM-DD. Sent in the link for a few booking sites; the site may ignore it."
    • changedInput schema / properties / partySize / description
      Previous value: -"Optional number of people."New value: +"Optional number of people. Sent in the link for some permit booking sites; the site may ignore it."
    • changedInput schema / properties / startDate / description
      Previous value: -"Optional first date, YYYY-MM-DD."New value: +"Optional first date, YYYY-MM-DD. Sent in the link for some booking sites; the site may ignore it."
    • changedOutput schema / description
      Previous value: -"The official booking page for a permit or campground, or found: false. Nothing is booked."New value: +"A link to the booking page, the agency's page or the PermitSnag page for a permit or campground, or found: false. Nothing is booked."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "anyOf": [
      +    {
      +      "required": [
      +        "subject",
      +        "url",
      +        "destination",
      +        "datePrefill",
      +        "executesNothing"
      +      ]
      +    },
      +    {
      +      "required": [
      +        "found"
      +      ]
      +    }
      +  ],
      +  "description": "The official booking page for a permit or campground, or found: false. Nothing is booked.",
      +  "properties": {
      +    "datePrefill": {
      +      "description": "Whether the asked date reaches the booking page.",
      +      "enum": [
      +        "applied",
      +        "ignored",
      +        "unknown"
      +      ]
      +    },
      +    "destination": {
      +      "enum": [
      +        "booking_page",
      +        "official_page",
      +        "permitsnag_page"
      +      ]
      +    },
      +    "executesNothing": {
      +      "const": true,
      +      "description": "This tool only returns a link."
      +    },
      +    "found": {
      +      "const": false,
      +      "description": "Present, and false, only when nothing matched."
      +    },
      +    "providerHomeUrl": {
      +      "description": "Permits only: the booking site's front page, when that is all we can name.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "subject": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "id": {
      +          "type": "string"
      +        },
      +        "kind": {
      +          "enum": [
      +            "permit",
      +            "campground"
      +          ]
      +        },
      +        "name": {
      +          "type": "string"
      +        },
      +        "pageUrl": {
      +          "type": "string"
      +        },
      +        "slug": {
      +          "description": "Permits only.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "kind",
      +        "id",
      +        "name",
      +        "pageUrl"
      +      ],
      +      "type": "object"
      +    },
      +    "url": {
      +      "description": "The page to open.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Adds substantial context beyond the readOnly/idempotent/non-destructive annotations: it warns that passed dates and party size may be ignored by the destination site, and that the returned URL may be an agency page or a PermitSnag page rather than a booking page. It also explicitly rules out booking, payment, and lottery entry. It stops short of stating failure behavior for an invalid permit/campground id.

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 return value, followed by the caveats that matter. It is a touch repetitive — the campground date-picking behavior is stated twice in near-identical form — but no sentence is wasted.

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 zero-required-parameter read tool with full schema coverage, annotations, and an output schema, the description covers the essential behavioral quirks an agent needs. Only error/edge handling (unknown id, conflicting permit+campground) is left unaddressed.

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%, so the baseline is 3. The description's notes about startDate, endDate, and partySize being embedded in the link but possibly ignored largely restate what the schema already documents, and the permit/campground mutual exclusivity is also already in the schema.

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 and resource: 'Returns the link to the official booking page for one US backcountry permit or one campground.' The scope is unambiguous and the closing sentence bounds what it does ('only returns a link and a sentence about it'), but it never names a sibling tool (e.g. check_availability) to sharpen the contrast.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: by saying 'the person checks or picks the dates and group size on that page,' it implicitly signals this tool is not for date/availability checking. However, there is no explicit 'use X instead when you need Y' routing against check_availability, get_permit_details, or search_permits.

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