PermitSnag

Set up a PermitSnag alert

create_alert

Idempotent

Set up an opening alert in the person's own linked PermitSnag account, for ONE permit (give permit, startDate, endDate, partySize) or ONE campground (give campground, checkInStart, checkInEnd, nights, and optionally sitesNeeded). PermitSnag then sends the person an alert when a matching opening appears. Use the permit or campground id from search_permits or search_campgrounds. Starting areas, night-by-night plans and groups of trailheads are set up on the website instead. The same request sent twice sets up one alert. It never books, pays or enters a lottery. When the account needs a purchase for this alert, the answer may hold the alert and give payment links for the person to open and pay on a checkout page; the alert then turns on by itself once paid. Nothing is ever charged from this tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_alert"
  }
}

Input Schema

Name	Required	Description
`nights`	No	Campground alert: nights in a row.
`permit`	No	The permit id or slug. Give this or campground, not both.
`endDate`	No	Permit alert: the last day the person could start, YYYY-MM-DD.
`partySize`	No	Permit alert: number of people.
`startDate`	No	Permit alert: the first day the person could start, YYYY-MM-DD.
`campground`	No	The campground id. Give this or permit, not both.
`checkInEnd`	No	Campground alert: the last acceptable check-in day, YYYY-MM-DD.
`sitesNeeded`	No	Campground alert: sites needed together. Default 1.
`checkInStart`	No	Campground alert: the first acceptable check-in day, YYYY-MM-DD.

Output Schema

Name	Required	Description
`alert`	No
`holdId`	No	awaiting_payment only: the held alert. It turns on by itself when one of paymentLinks is paid.
`reason`	No	Why the request was refused, as a short code.
`status`	Yes
`pageUrl`	No	The PermitSnag page for this place.
`paymentLinks`	No
`linksExpireAt`	No	awaiting_payment only: when the payment links stop working.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses key behavior: idempotency (same request twice sets up one alert), safety boundaries (never books, pays, or enters a lottery), and the payment-link flow when the account needs a purchase. This is substantial context that the annotations alone do not provide.

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?

The description is front-loaded and logically structured: purpose, parameter modes, id source, exclusions, idempotency, safety, and payment behavior. It is somewhat long and repeats the no-charge idea, but every major sentence carries useful operational information.

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?

Given the tool's complexity, nine parameters, rich annotations, and an output schema, the description covers what an agent needs: the two alert modes, required id sources, idempotency, scope exclusions, and the payment-link branch. Nothing essential is missing.

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%, so the baseline is 3. The description earns additional credit by grouping parameters into mutually exclusive permit and campground modes and telling the agent which parameters belong to each, which helps correct invocation even though the schema already documents individual fields.

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 states a precise verb and resource (set up an opening alert in the person's linked PermitSnag account) and immediately distinguishes the two supported alert shapes: one permit or one campground. It also differentiates itself from sibling search tools by directing the agent to use ids from search_permits or search_campgrounds.

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?

It gives explicit when-to-use guidance, naming the exact parameter sets for permit alerts and campground alerts. It also routes out-of-scope cases (starting areas, night-by-night plans, groups of trailheads) to the website, so an agent can tell when not to call this tool.

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

All PermitSnag tools Inspect

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

Need Help?