outdoorithm

Server Details

Campground search, live availability, weather, safety, and gear for 10,000+ US campgrounds.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 61 days
Last Tested: 2026-10-17 12:49
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-27 19:10 across 13 tools

Disambiguation4/5

Most tools have clearly distinct targets, but the four gear-related tools (search_gear, compare_gear, get_gear_for_campground, build_packing_list) require reading descriptions to separate catalog search from personalized recommendations from comparison. Campground tools (search/get/find_similar) and availability vs. reservation are otherwise well-differentiated.

Naming Consistency5/5

Nearly all tools follow a clean snake_case verb_noun pattern (search_campgrounds, get_weather, check_availability, build_packing_list). Only health_check deviates slightly as a noun_verb form, but this is a conventional, readable exception.

Tool Count5/5

13 tools is well within the ideal range and each maps to a distinct planning need: discovery, details, availability, safety, weather, gear, logistics, and booking handoff. No obviously redundant or filler tools.

Completeness4/5

The surface covers a full trip-planning lifecycle: search, details, similarity, availability, safety, weather, gear, packing, drive times, and reservation handoff. The main gap is the absence of review-writing or user-contributed data operations, but read-only coverage is otherwise strong.

Available Tools

13 tools

build_packing_listBuild Packing ListA

Read-only

Inspect

Generate a context-aware packing checklist for a camping trip.

Returns categorized items from the gear catalog, adjusted for campground amenities, activities, weather, and group size.

ParametersJSON Schema

Name	Required	Description	Default
`adults`	No	Number of adults (default 2)
`nights`	No	Number of nights (default 2)
`season`	No	spring, summer, fall, or winter (optional)
`children`	No	Number of children (default 0)
`has_pets`	No	Whether bringing pets (default false)
`trip_type`	No	car_camping, backpacking, rv, or glamping (default car_camping)	car_camping
`activities`	No	Planned activities (hiking, fishing, swimming, kayaking, biking, beach)
`campground_id`	No	Optional CUID to personalize based on campground amenities

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already establish that this is a safe, non-destructive, non-open-world read, so the bar is lower. The description adds real behavioral context beyond them: the output is categorized, derived from the gear catalog, and personalized by campground amenities, activities, weather, and group size.

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?

Two tight sentences, front-loaded with the purpose and followed by the output shape, with no filler. The second sentence lists factors that partially restate the schema, a minor redundancy rather than waste.

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?

An output schema exists and all parameters are self-documented, and no parameters are required, so the definition is nearly complete for an 8-param generator. What is missing is how the optional campground_id interacts with the data source and how this tool relates to the gear-search siblings.

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 every parameter is already documented in structured form, making 3 the baseline. The description's mention of amenities, activities, weather, and group size loosely maps to the parameters but adds no semantics, format, or interaction detail the schema lacks.

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?

Specific verb ('Generate') plus a concrete resource ('context-aware packing checklist for a camping trip'), and it names the inputs that shape the output. It does not distinguish itself from gear-catalog siblings such as search_gear or get_gear_for_campground, so an agent must infer the boundary from the verb alone.

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 description says what the tool produces but never states when to pick it over the sibling gear tools, nor any prerequisites such as whether campground_id should be supplied first. Usage is only implied by the trip-planning framing.

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

calculate_drive_timesCalculate Drive TimesA

Read-only

Inspect

Calculate realistic drive times from an origin to multiple campgrounds using Mapbox routing with live traffic.

Uses the Mapbox Matrix API for traffic-aware routing. Maximum 9 destinations per request.

ParametersJSON Schema

Name	Required	Description
`destinations`	Yes	List of {campground_id: str, latitude: float, longitude: float} (max 9)
`origin_latitude`	Yes	Latitude of starting location
`origin_longitude`	Yes	Longitude of starting location

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the external dependency (Mapbox Matrix API), that results are traffic-aware/live, and the hard cap of 9 destinations per request.

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?

Two tight sentences, front-loaded with the outcome and followed by the implementation/limit detail. No filler.

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?

With an output schema present, return values need no explanation, and the description covers inputs, method, and the 9-destination limit. It could say what happens on over-limit requests or whether failures are per-destination, but nothing essential to a correct call is missing.

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%, covering origin_latitude, origin_longitude, and the destinations item shape. The description repeats the max-9 constraint but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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 verb and resource ("Calculate realistic drive times"), the input shape (origin to multiple campgrounds), and the mechanism (Mapbox routing with live traffic). No sibling tool offers routing or travel-time computation, so the agent can place it immediately.

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 by the purpose (call it when you need travel times between a point and campgrounds) but the description never states when to prefer it or what to do when the destination limit is exceeded. No alternatives exist among siblings, so the gap is modest, but there is no explicit guidance.

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

check_availabilityCheck AvailabilityA

Read-only

Inspect

Check real-time campground availability for specific dates.

Queries the camply-service to check live campsite availability against reservation systems. Supports 30+ providers including RecreationDotGov, ReserveCalifornia, state parks, and county parks.

ParametersJSON Schema

Name	Required	Description
`end_date`	Yes	Check-out date in YYYY-MM-DD format
`min_nights`	No	Minimum consecutive nights required (1-7, default 1)
`start_date`	Yes	Check-in date in YYYY-MM-DD format
`campground_id`	Yes	Campground CUID (e.g., "ReserveCalifornia:uuid:725")

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: queries hit live reservation systems in real time and cover 30+ named providers, which tells an agent this is a network-dependent lookup with provider-dependent coverage. It omits latency/rate-limit and failure behavior, so not a 5.

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?

Two sentences, purpose front-loaded in the first, with the provider detail second. Efficient overall, though the provider enumeration is slightly broader than strictly necessary for invoking the tool.

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?

With a complete input schema, an existing output schema, and rich annotations, the description is sufficient to call the tool correctly. Minor gaps remain around sequencing with siblings and behavior on unavailable/unrecognized campground IDs, but nothing essential is missing.

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 formats, defaults, and ranges documented for campground_id, start_date, end_date, and min_nights. The description adds nothing parameter-specific, 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 and resource ('Check real-time campground availability') plus the scoping constraint ('for specific dates'), which is clearly distinct from siblings like search_campgrounds or get_campground_details. It never names an alternative tool explicitly, so it stops short of full sibling differentiation.

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 by 'real-time availability for specific dates,' and the provider list hints at the domain of applicability, but there is no explicit when-to-use vs alternatives (e.g., search_campgrounds first, or prepare_reservation after). No exclusions or prerequisites are stated.

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

check_safetyCheck SafetyA

Read-only

Inspect

Check campgrounds for safety issues, community atmosphere, and active alerts.

Checks:

Greenbook community safety (vibe scores, discrimination reports, flag status)
Active campground alerts (closures, restrictions) from enriched data
Red flag detection (prevents recommending unsafe campgrounds)

ParametersJSON Schema

Name	Required	Description	Default
`campground_ids`	Yes	List of campground CUIDs to check

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered. The description adds real domain substance beyond that: greenbook vibe scores, discrimination reports, flag status, and closure/restriction alerts, which tells the agent what data surfaces in the result.

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 one-sentence summary is front-loaded and the three bullets are tight and non-redundant. Slightly list-heavy for a single-parameter tool, but every line carries information.

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?

Output schema exists, so return values need not be explained, and annotations cover the read-only safety profile. The main residual gap is that 'Greenbook' is unexplained niche terminology, though the parenthetical glosses mostly mitigate it.

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 coverage is 100% with a single campground_ids array already described as 'List of campground CUIDs to check'. The description adds no format, batching, or ordering guidance for that parameter, so a 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?

States a specific verb (check) and resource (campgrounds) and enumerates the three things it assesses: safety issues, community atmosphere, and active alerts. No sibling tool overlaps this domain, so an agent can distinguish it immediately from search_campgrounds or get_campground_details.

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: the red-flag line ('prevents recommending unsafe campgrounds') hints this is a screening step, but there is no explicit when-to-use, no prerequisites, and no named alternative. An agent must infer the workflow position.

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

compare_gearCompare GearA

Read-only

Inspect

Compare 2-3 gear items side-by-side with specs, pros/cons, verdicts, and comparison summary.

Supports lookup by unique_id with slug fallback.

ParametersJSON Schema

Name	Required	Description	Default
`gear_ids`	Yes	List of 2-3 gear item identifiers (unique_id or slug)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context about the comparison output contents and the unique_id-with-slug-fallback resolution, but says nothing about item limits beyond 2-3, error behavior for unknown IDs, or latency.

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?

Two short sentences, output shape front-loaded, zero filler. Every clause carries information and nothing is repeated.

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?

With an output schema present, the description needn't detail return values, and it still sketches them. For a single-parameter read-only tool this is nearly complete; the only gap is any guidance on routing from search_gear into this tool.

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% and the single gear_ids parameter is already documented as 'unique_id or slug' in the schema. The description's 'unique_id with slug fallback' restates rather than extends that, so 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 (Compare) and resource (gear items) plus the scope (2-3 items side-by-side) and the shape of the output (specs, pros/cons, verdicts, summary). It is clearly distinguishable from read-oriented siblings like search_gear, but it never names an alternative to route against.

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 only implied by 'compare 2-3 gear items' — an agent can infer this is the post-search comparison step, but there is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as search_gear for discovering items first.

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

find_similar_campgroundsFind Similar CampgroundsA

Read-only

Inspect

Find campgrounds similar to a given campground using vector embedding similarity.

Uses pre-computed embeddings combining review text (semantic) and structured attributes (amenities, terrain, activities) for nuanced similarity matching.

ParametersJSON Schema

Name	Required	Description
`result_limit`	No	Number of results (1-50, default 20)
`campground_id`	Yes	CUID of the target campground to find similar ones for
`max_distance_km`	No	Optional max distance in km (omit for nationwide search)
`semantic_weight`	No	Weight for text/review similarity (0-1, default 0.6)
`structured_weight`	No	Weight for attribute similarity (0-1, default 0.4)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety and scope are clear. The description adds meaningful behavioral context beyond annotations: it explains that similarity is computed from pre-computed embeddings combining review text and structured attributes, which helps the agent interpret results.

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?

Two tightly written sentences with zero waste. The core purpose is front-loaded, and the second sentence adds useful mechanism without padding.

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?

Given the read-only annotations, full output schema, and complete parameter descriptions, the definition is nearly self-sufficient. The main gap is the absence of sibling differentiation against search_campgrounds, which slightly hinders tool selection despite the otherwise complete picture.

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 description coverage is 100%, so the baseline is 3. The description adds conceptual meaning to the semantic_weight and structured_weight parameters by explaining that embeddings combine review text (semantic) and structured attributes (amenities, terrain, activities), clarifying what those weights control beyond the schema's terse descriptions.

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?

The description states a specific verb (Find) and resource (campgrounds similar to a given campground), and adds the method (vector embedding similarity). It distinguishes itself from a generic search by requiring a target campground, but does not explicitly name the sibling search_campgrounds 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 Guidelines2/5

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

The description gives no guidance on when to use this tool versus alternatives like search_campgrounds. There are no exclusions, conditions, or named alternatives; the agent must infer usage entirely from the purpose statement.

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

get_campground_detailsGet Campground DetailsA

Read-only

Inspect

Get comprehensive details for a specific campground including amenities, reviews, safety, and seasonal ratings.

Returns ~80 curated fields (not the raw 214-column dump) including:

Identity, location, fees, site info
All amenity and activity booleans + descriptions
Review summaries, best campsites, common complaints, tips
Greenbook community safety (vibe score, flag status)
Seasonal LLM ratings (spring/summer/fall/winter)
Sentiment trend direction
Hero image with credits

Data coverage: a missing or empty field means the attribute isn't in our records, not that the feature is absent at the campground. Coverage varies by provider; the campground operator is the authoritative source.

ParametersJSON Schema

Name	Required	Description	Default
`campground_id`	Yes	Unique campground identifier (CUID format, e.g., "RecreationDotGov:232447:1074")

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely behavioral context beyond that: it returns ~80 curated fields rather than the raw 214-column dump, and it explains that a missing/empty field means absence from the records, not absence of the feature — an important interpretation caveat for an agent.

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 purpose sentence is front-loaded, and the bulleted field list plus the data-coverage note are scannable. The field enumeration is partly redundant with the existing output schema and runs long, but each block still serves a purpose, so it stops short of waste.

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?

With an output schema present, the description needn't explain return values, yet it summarizes them helpfully and adds the data-coverage caveat that the schema cannot convey. The only real gap is orientation on obtaining a campground_id, which is a minor omission for a single-input read tool.

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% and the single campground_id parameter is documented in the schema with format and an example ('RecreationDotGov:232447:1074'). The description adds nothing about the identifier itself, so the baseline of 3 for a fully documented single parameter 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 and resource ('Get comprehensive details for a specific campground') and enumerates the field families returned. It clearly distinguishes the tool as a detail-fetch (singular, ID-based) versus list/search cousins, but never names a sibling such as search_campgrounds to route the agent explicitly.

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?

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'for a specific campground' weakly implies the tool is invoked after a search has produced a campground_id, but the description never says where the ID comes from or which sibling to call first.

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

get_gear_for_campgroundGet Gear for CampgroundB

Read-only

Inspect

Get personalized gear recommendations for a specific campground.

Returns pre-computed recommendations across slot types: essential (must-have), activity (activity-matched), comfort (nice-to-have), amenity_gap (compensates for missing amenities). Each includes product details and purchase links.

ParametersJSON Schema

Name	Required	Description	Default
`slot_type`	No	Optional filter — one of essential/activity/comfort/amenity_gap
`campground_id`	Yes	Campground CUID

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by explaining that recommendations are pre-computed and what each slot bucket means (essential = must-have, amenity_gap = compensates for missing amenities), which is behavioral context beyond the annotations.

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?

Two sentences, front-loaded with the purpose and followed by a tightly packed parenthetical list. No filler. It loses a point only because most of the space is spent on return-value detail that the output schema already carries.

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

Completeness3/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 explaining return values is redundant effort. The description compensates with slot semantics but leaves the genuine gap — when to use this instead of search_gear or compare_gear — unaddressed.

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 description coverage is 100%, so the baseline is 3. The description goes slightly beyond it by giving semantics for the optional slot_type filter values — essential/activity/comfort/amenity_gap are each defined — which the schema only enumerates as strings.

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: 'Get personalized gear recommendations for a specific campground.' An agent can tell what it returns, but the description never names the sibling tools (search_gear, compare_gear) it is distinct from, so sibling differentiation is left 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?

No when-to-use, when-not-to-use, or alternative guidance. The phrase 'for a specific campground' hints that a campground_id must already be known, but nothing routes the agent between this and search_gear/compare_gear, and no prerequisites are stated.

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

get_weatherGet WeatherA

Read-only

Inspect

Get camping-specific 7-day weather forecast with suitability ratings and gear recommendations.

Uses Open-Meteo's commercial API to provide:

Daily high/low temps, conditions, precipitation, wind
Camping suitability rating per day (excellent/good/fair/poor/not_recommended)
Gear recommendations based on conditions
Safety warnings for extreme weather
Best camping days in the forecast period

Forecast data is from Open-Meteo, licensed under CC BY 4.0. Every successful forecast includes an attribution field carrying the required credit.

ParametersJSON Schema

Name	Required	Description
`latitude`	Yes	Campground latitude
`longitude`	Yes	Campground longitude
`check_in_date`	No	Planned check-in date ISO format (optional)
`check_out_date`	No	Planned check-out date ISO format (optional)
`campground_name`	No	Campground name for context (optional)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description still adds meaningful context: the Open-Meteo commercial data source, the mandatory attribution field on every forecast, and the fixed 7-day horizon. It stops short of stating failure or rate-limit behavior.

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 lead sentence states the purpose up front and the bullet list enumerates outputs efficiently. The licensing/attribution sentence is slightly long but earns its place given the attribution requirement.

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?

An output schema exists, so return values need not be re-explained, and the description still covers data source, licensing obligations, and output categories. The only real gap is guidance on how the optional date parameters shape the forecast window.

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 every parameter is documented in the schema already. The description adds only the implicit 7-day window and mentions no syntax for the optional check-in/check-out dates or campground_name, so it stays at the baseline.

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 names a specific verb and resource ("Get camping-specific 7-day weather forecast") and adds distinctive scope: suitability ratings, gear recommendations, safety warnings, and best days. No sibling tool offers weather, so it is easily disambiguated from search_campgrounds, check_safety, or get_gear_for_campground.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling tool is named as an alternative or complement. The camping context implies trip planning, but the agent is left to infer that itself.

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

health_checkHealth CheckA

Read-only

Inspect

Check server health and connectivity.

Returns: Dictionary with health status including: - status: "healthy" or "unhealthy" - version: Server version - environment: Current environment (dev/staging/prod)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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, so the safety profile is covered. The description adds value by disclosing the return structure (status, version, environment) and the connectivity check behavior, which goes beyond the annotation-only information.

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 extremely concise, front-loaded with the purpose, and follows with a clear bulleted list of return fields. No filler or redundant content.

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 zero-parameter health check tool, the description fully covers its purpose and return data. The output structure is described, and no additional context is needed given the tool's simplicity and the supporting annotations.

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?

The input schema has zero parameters, so schema coverage is 100%. There is nothing for the description to add about parameters. Baseline for zero-param tools is 4, and no explanation is needed.

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 'Check server health and connectivity' with a specific verb and resource. This uniquely distinguishes it from sibling tools, which all focus on funder/nonprofit data operations.

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

Usage Guidelines4/5

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

The purpose is unambiguous and provides clear context for when to use this tool: when you need to verify server health or connectivity. It does not explicitly list alternatives or exclusions, but the domain differentiation from siblings makes the usage context evident.

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

prepare_reservationPrepare ReservationA

Read-only

Inspect

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, operator rules, alert suggestion). Does NOT book on behalf: third-party booking is prohibited by Recreation.gov, ReserveCalifornia, ReserveAmerica, and every other supported public-land operator.

ParametersJSON Schema

Name	Required	Description
`end_date`	Yes	Check-out date (YYYY-MM-DD).
`party_size`	No	Optional 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_date`	Yes	Check-in date (YYYY-MM-DD).
`campground_id`	Yes	Outdoorithm CUID (e.g. ``RecreationDotGov:232447``).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare a read-only, non-destructive, non-open-world tool. The description adds meaningful behavioral context beyond that: it returns a deep link and booking-window details, and it explicitly does not book on behalf because third-party booking is prohibited by major operators.

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 tightly structured and front-loaded: purpose first, return contents second, and the key prohibition last. Every sentence earns its place and there is no redundant 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?

Given full schema coverage, an output schema, and safety annotations, the description supplies everything an agent needs. It explains the handoff behavior, the return contents, and the non-booking boundary, completing the picture without over-explaining.

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 schema already documents all four parameters. The description refers generally to 'chosen campground/dates' but adds no syntax, format, or constraint details beyond what the schema provides, so the baseline of 3 applies.

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 specific verb and resource: 'Prepare a one-tap booking handoff' and returns a pre-filled deep link plus booking-window context. It clearly distinguishes itself from booking tools by stating it does not book on behalf, which separates it from any sibling that mutates reservations.

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?

It implies the tool is used once the user has already chosen a campground and dates. However, it does not explicitly say when to use this versus alternatives like check_availability, nor does it list prerequisites beyond the implied post-selection context.

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

search_campgroundsSearch CampgroundsA

Read-only

Inspect

Search for campgrounds with 40+ filters including location, amenities, activities, and community safety.

Requires at least one location constraint: near_location, campground_name, latitude+longitude, or states.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum results (1-50, default 20)
`states`	No	US state codes to filter by (e.g., ["CA", "OR"])
`latitude`	No	Latitude coordinate
`longitude`	No	Longitude coordinate
`allows_pets`	No	Only show pet-friendly campgrounds
`camping_type`	No	Camping type (tent/rv/primitive/group/cabin/glamping)
`near_location`	No	City, park, address, or landmark (e.g., "Oakland, CA", "Yosemite")
`prefers_beach`	No	Prefer beach settings
`prefers_quiet`	No	Prefer quiet campgrounds
`prefers_desert`	No	Prefer desert settings
`prefers_forest`	No	Prefer forested settings
`prefers_hiking`	No	Prefer hiking trails
`campground_name`	No	Name, or the start of the name, of a specific campground (e.g., "Jumbo Rocks", "Upper Pines"). Matching campgrounds are returned first; with no other location given, the search centers on the best match.
`prefers_boating`	No	Prefer boating access
`prefers_fishing`	No	Prefer fishing access
`prefers_privacy`	No	Prefer private campsites
`min_review_count`	No	Minimum number of reviews
`preferred_season`	No	Preferred season (summer/fall/winter/spring)
`prefers_kayaking`	No	Prefer kayaking access
`prefers_mountain`	No	Prefer mountain settings
`prefers_secluded`	No	Prefer secluded/private campgrounds
`prefers_swimming`	No	Prefer swimming areas
`requires_showers`	No	Require shower facilities
`min_avg_sentiment`	No	Minimum average sentiment (0-5)
`preferred_carrier`	No	Preferred carrier (verizon/att/tmobile)
`prefers_adventure`	No	Prefer adventure-oriented campgrounds
`prefers_lakefront`	No	Prefer lakefront locations
`max_distance_miles`	No	Maximum distance from location in miles
`min_seasonal_score`	No	Minimum seasonal score (1-5)
`prefers_oceanfront`	No	Prefer ocean/beach locations
`prefers_relaxation`	No	Prefer relaxation-focused campgrounds
`prefers_riverfront`	No	Prefer riverside locations
`prefers_stargazing`	No	Prefer dark sky areas
`sentiment_trending`	No	Filter by trend (improving/stable/declining)
`max_price_per_night`	No	Maximum price filter
`min_price_per_night`	No	Minimum price filter
`requires_dump_station`	No	Require RV dump station
`require_greenbook_safe`	No	Only show campgrounds with OK safety status
`requires_accessibility`	No	Require wheelchair/ADA accessible features
`requires_cell_coverage`	No	Require cell phone coverage
`requires_flush_toilets`	No	Require flush toilets
`requires_potable_water`	No	Require potable water
`requires_water_hookups`	No	Require water hookups
`min_cell_coverage_score`	No	Minimum cell coverage score (1-5)
`prefers_family_friendly`	No	Prefer family-friendly campgrounds
`min_greenbook_vibe_score`	No	Minimum community vibe score (0-100)
`only_improving_sentiment`	No	Only show campgrounds with improving reviews
`no_discrimination_reports`	No	Exclude campgrounds with discrimination reports
`requires_electric_hookups`	No	Require electric hookups

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds one genuine behavioral constraint beyond that — the mandatory location input — but says nothing about result ranking, pagination, or the semantics of the 40+ soft 'prefers_*' hints versus hard 'requires_*' filters.

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?

Two sentences, zero waste, and the purpose is front-loaded ahead of the precondition. '40+ filters' efficiently conveys the breadth of the schema without enumerating it.

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?

With 100% schema description coverage, an existing output schema, and annotations covering the read-only/open-world profile, the description only needs to supply purpose and the binding input constraint — both are present. Minor gap: it does not clarify the distinction between soft preference flags and hard requirement flags, which matters at this parameter count.

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 baseline is 3, but the description contributes a cross-parameter rule the schema cannot express: that at least one of near_location, campground_name, latitude+longitude, or states is mandatory despite all 49 parameters being optional. It also groups the filter space into location/amenities/activities/community safety, giving an agent a map of an otherwise overwhelming 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?

The description states a specific verb and resource ('Search for campgrounds') and characterizes the filter surface ('40+ filters including location, amenities, activities, and community safety'), which separates it from siblings like get_campground_details and find_similar_campgrounds. It stops short of explicitly naming a sibling it is not, so it lands at clear-but-undifferentiated.

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

Usage Guidelines4/5

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

It states a hard precondition that an agent must satisfy — 'Requires at least one location constraint: near_location, campground_name, latitude+longitude, or states' — which is exactly the kind of usage rule that prevents a failed call. It does not, however, say when to prefer this tool over alternatives such as get_campground_details or find_similar_campgrounds.

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

search_gearSearch GearA

Read-only

Inspect

Search the Outdoorithm gear catalog by keyword, category, price range, kit, necessity, or recommendation tier.

Returns matching products with prices, verdicts, and purchase links.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (1-20, default 10)
`query`	No	Text search across product name, manufacturer, keywords, and description
`kit_name`	No	Filter by kit (e.g., Basics, Camp Kitchen, Hiking, Cold Weather)
`max_price`	No	Maximum price in USD
`min_price`	No	Minimum price in USD
`necessity`	No	Filter by level — Essential, Helpful, or Optional
`category_name`	No	Filter by category (e.g., Shelter, Sleeping Gear, Furniture, Electronics)
`recommendation_tier`	No	Filter by tier — Our Pick, Value Pick, or Comfort Pick

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds that matching products include prices, verdicts, and purchase links, which is useful output context, but does not disclose result ordering, pagination behavior beyond the limit param, or how absent filters behave.

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?

Two tight sentences, front-loaded with the action and resource, followed by the return summary. No wasted words.

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?

With a full output schema, complete parameter documentation, and safety annotations already present, the description covers what an agent needs to select and call the tool. It stops short of the 5 mark only because filter-combination behavior (AND vs OR across facets) is left unspecified.

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 8 well-documented parameters, so the schema carries the parameter burden. The description's facet list mirrors the schema fields (keyword, category, price, kit, necessity, tier) without adding any syntax, precedence, or combination semantics beyond it.

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 verb (Search) and resource (Outdoorithm gear catalog) and enumerates the searchable facets. It is clearly distinguishable from siblings like search_campgrounds, compare_gear, and get_gear_for_campground without needing their schemas.

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?

The facet list implies usage but gives no explicit when-to-use guidance, no statement of when to prefer this over compare_gear or get_gear_for_campground, and no note that all filters are optional. Adequate but with clear gaps.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 27, 2026

Changedsearch_campgrounds2 fields changed

addedInput schema / properties / campground_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Name, or the start of the name, of a specific campground\n(e.g., \"Jumbo Rocks\", \"Upper Pines\"). Matching campgrounds are returned\nfirst; with no other location given, the search centers on the best match."
+}

changedInput schema / properties / near_location / description

Previous value: -"City, address, or landmark (e.g., \"Oakland, CA\", \"Yosemite\")"New value: +"City, park, address, or landmark (e.g., \"Oakland, CA\", \"Yosemite\")"

4 tool updatesAug 2, 2026
- Removedcreate_alert
- Removeddelete_alert
- Removedlist_alerts
- Removedtoggle_alert
17 tool updatesJul 27, 2026
- Changedbuild_packing_list9 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / activities / description
```
Added value: +"Planned activities (hiking, fishing, swimming, kayaking, biking, beach)"
```
  - addedInput schema / properties / adults / description
```
Added value: +"Number of adults (default 2)"
```
  - addedInput schema / properties / campground_id / description
```
Added value: +"Optional CUID to personalize based on campground amenities"
```
  - addedInput schema / properties / children / description
```
Added value: +"Number of children (default 0)"
```
  - addedInput schema / properties / has_pets / description
```
Added value: +"Whether bringing pets (default false)"
```
  - addedInput schema / properties / nights / description
```
Added value: +"Number of nights (default 2)"
```
  - addedInput schema / properties / season / description
```
Added value: +"spring, summer, fall, or winter (optional)"
```
  - addedInput schema / properties / trip_type / description
```
Added value: +"car_camping, backpacking, rv, or glamping (default car_camping)"
```
- Changedcalculate_drive_times4 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / destinations / description
```
Added value: +"List of {campground_id: str, latitude: float, longitude: float} (max 9)"
```
  - addedInput schema / properties / origin_latitude / description
```
Added value: +"Latitude of starting location"
```
  - addedInput schema / properties / origin_longitude / description
```
Added value: +"Longitude of starting location"
```
- Changedcheck_availability5 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / campground_id / description
```
Added value: +"Campground CUID (e.g., \"ReserveCalifornia:uuid:725\")"
```
  - addedInput schema / properties / end_date / description
```
Added value: +"Check-out date in YYYY-MM-DD format"
```
  - addedInput schema / properties / min_nights / description
```
Added value: +"Minimum consecutive nights required (1-7, default 1)"
```
  - addedInput schema / properties / start_date / description
```
Added value: +"Check-in date in YYYY-MM-DD format"
```
- Changedcheck_safety2 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / campground_ids / description
```
Added value: +"List of campground CUIDs to check"
```
- Changedcompare_gear2 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / gear_ids / description
```
Added value: +"List of 2-3 gear item identifiers (unique_id or slug)"
```
- Changedcreate_alert13 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / api_key / description
```
Added value: +"User's Outdoorithm API key from their dashboard settings."
```
  - addedInput schema / properties / campground_ids / description
```
Added value: +"List of campground CUIDs to monitor. All must use the same\nreservation provider. Get CUIDs from search_campgrounds or get_campground_details.\nExample: [\"RecreationDotGov:232447:2991\"]"
```
  - addedInput schema / properties / date_type / description
```
Added value: +"How dates are interpreted. \"range\" monitors a specific date window (default),\n\"perpetual\" monitors rolling 6 months from start_date,\n\"specific_months\" monitors only certain months each year."
```
  - addedInput schema / properties / days_of_week / description
```
Added value: +"Preferred check-in days as integers (0=Monday through 6=Sunday). Omit for any day."
```
  - addedInput schema / properties / end_date / description
```
Added value: +"Latest check-out date (YYYY-MM-DD). Required when date_type is \"range\"."
```
  - addedInput schema / properties / max_nights / description
```
Added value: +"Maximum consecutive nights (1-14, must be >= min_nights). Omit for no max."
```
  - addedInput schema / properties / min_nights / description
```
Added value: +"Minimum consecutive nights needed (1-14, default 1)."
```
  - addedInput schema / properties / name / description
```
Added value: +"Display name for this alert. Auto-generated from campground and dates if omitted."
```
  - addedInput schema / properties / notify_email / description
```
Added value: +"Send email when availability found (default true)."
```
  - addedInput schema / properties / notify_sms / description
```
Added value: +"Send SMS when availability found (default false, requires phone on account)."
```
  - addedInput schema / properties / specific_months / description
```
Added value: +"Month numbers 1-12 to monitor. Required when date_type is \"specific_months\"."
```
  - addedInput schema / properties / start_date / description
```
Added value: +"Earliest check-in date to monitor (YYYY-MM-DD). Required for all date types."
```
- Changeddelete_alert3 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / alert_id / description
```
Added value: +"UUID of the alert to delete. Get this from list_alerts."
```
  - addedInput schema / properties / api_key / description
```
Added value: +"User's Outdoorithm API key from their dashboard settings."
```
- Changedfind_similar_campgrounds6 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / campground_id / description
```
Added value: +"CUID of the target campground to find similar ones for"
```
  - addedInput schema / properties / max_distance_km / description
```
Added value: +"Optional max distance in km (omit for nationwide search)"
```
  - addedInput schema / properties / result_limit / description
```
Added value: +"Number of results (1-50, default 20)"
```
  - addedInput schema / properties / semantic_weight / description
```
Added value: +"Weight for text/review similarity (0-1, default 0.6)"
```
  - addedInput schema / properties / structured_weight / description
```
Added value: +"Weight for attribute similarity (0-1, default 0.4)"
```
- Changedget_campground_details2 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / campground_id / description
```
Added value: +"Unique campground identifier (CUID format, e.g., \"RecreationDotGov:232447:1074\")"
```
- Changedget_gear_for_campground3 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / campground_id / description
```
Added value: +"Campground CUID"
```
  - addedInput schema / properties / slot_type / description
```
Added value: +"Optional filter — one of essential/activity/comfort/amenity_gap"
```
- Changedget_weather6 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / campground_name / description
```
Added value: +"Campground name for context (optional)"
```
  - addedInput schema / properties / check_in_date / description
```
Added value: +"Planned check-in date ISO format (optional)"
```
  - addedInput schema / properties / check_out_date / description
```
Added value: +"Planned check-out date ISO format (optional)"
```
  - addedInput schema / properties / latitude / description
```
Added value: +"Campground latitude"
```
  - addedInput schema / properties / longitude / description
```
Added value: +"Campground longitude"
```
- Changedhealth_check1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedlist_alerts3 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / api_key / description
```
Added value: +"User's Outdoorithm API key from their dashboard settings."
```
  - addedInput schema / properties / status / description
```
Added value: +"Filter by alert status. One of: \"active\", \"paused\", \"expired\",\n\"error\", or \"permanent_error\". Omit to return all alerts."
```
- Changedprepare_reservation5 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)."
```
- Changedsearch_campgrounds49 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / allows_pets / description
```
Added value: +"Only show pet-friendly campgrounds"
```
  - addedInput schema / properties / camping_type / description
```
Added value: +"Camping type (tent/rv/primitive/group/cabin/glamping)"
```
  - addedInput schema / properties / latitude / description
```
Added value: +"Latitude coordinate"
```
  - addedInput schema / properties / limit / description
```
Added value: +"Maximum results (1-50, default 20)"
```
  - addedInput schema / properties / longitude / description
```
Added value: +"Longitude coordinate"
```
  - addedInput schema / properties / max_distance_miles / description
```
Added value: +"Maximum distance from location in miles"
```
  - addedInput schema / properties / max_price_per_night / description
```
Added value: +"Maximum price filter"
```
  - addedInput schema / properties / min_avg_sentiment / description
```
Added value: +"Minimum average sentiment (0-5)"
```
  - addedInput schema / properties / min_cell_coverage_score / description
```
Added value: +"Minimum cell coverage score (1-5)"
```
  - addedInput schema / properties / min_greenbook_vibe_score / description
```
Added value: +"Minimum community vibe score (0-100)"
```
  - addedInput schema / properties / min_price_per_night / description
```
Added value: +"Minimum price filter"
```
  - addedInput schema / properties / min_review_count / description
```
Added value: +"Minimum number of reviews"
```
  - addedInput schema / properties / min_seasonal_score / description
```
Added value: +"Minimum seasonal score (1-5)"
```
  - addedInput schema / properties / near_location / description
```
Added value: +"City, address, or landmark (e.g., \"Oakland, CA\", \"Yosemite\")"
```
  - addedInput schema / properties / no_discrimination_reports / description
```
Added value: +"Exclude campgrounds with discrimination reports"
```
  - addedInput schema / properties / only_improving_sentiment / description
```
Added value: +"Only show campgrounds with improving reviews"
```
  - addedInput schema / properties / preferred_carrier / description
```
Added value: +"Preferred carrier (verizon/att/tmobile)"
```
  - addedInput schema / properties / preferred_season / description
```
Added value: +"Preferred season (summer/fall/winter/spring)"
```
  - addedInput schema / properties / prefers_adventure / description
```
Added value: +"Prefer adventure-oriented campgrounds"
```
  - addedInput schema / properties / prefers_beach / description
```
Added value: +"Prefer beach settings"
```
  - addedInput schema / properties / prefers_boating / description
```
Added value: +"Prefer boating access"
```
  - addedInput schema / properties / prefers_desert / description
```
Added value: +"Prefer desert settings"
```
  - addedInput schema / properties / prefers_family_friendly / description
```
Added value: +"Prefer family-friendly campgrounds"
```
  - addedInput schema / properties / prefers_fishing / description
```
Added value: +"Prefer fishing access"
```
  - addedInput schema / properties / prefers_forest / description
```
Added value: +"Prefer forested settings"
```
  - addedInput schema / properties / prefers_hiking / description
```
Added value: +"Prefer hiking trails"
```
  - addedInput schema / properties / prefers_kayaking / description
```
Added value: +"Prefer kayaking access"
```
  - addedInput schema / properties / prefers_lakefront / description
```
Added value: +"Prefer lakefront locations"
```
  - addedInput schema / properties / prefers_mountain / description
```
Added value: +"Prefer mountain settings"
```
  - addedInput schema / properties / prefers_oceanfront / description
```
Added value: +"Prefer ocean/beach locations"
```
  - addedInput schema / properties / prefers_privacy / description
```
Added value: +"Prefer private campsites"
```
  - addedInput schema / properties / prefers_quiet / description
```
Added value: +"Prefer quiet campgrounds"
```
  - addedInput schema / properties / prefers_relaxation / description
```
Added value: +"Prefer relaxation-focused campgrounds"
```
  - addedInput schema / properties / prefers_riverfront / description
```
Added value: +"Prefer riverside locations"
```
  - addedInput schema / properties / prefers_secluded / description
```
Added value: +"Prefer secluded/private campgrounds"
```
  - addedInput schema / properties / prefers_stargazing / description
```
Added value: +"Prefer dark sky areas"
```
  - addedInput schema / properties / prefers_swimming / description
```
Added value: +"Prefer swimming areas"
```
  - addedInput schema / properties / require_greenbook_safe / description
```
Added value: +"Only show campgrounds with OK safety status"
```
  - addedInput schema / properties / requires_accessibility / description
```
Added value: +"Require wheelchair/ADA accessible features"
```
  - addedInput schema / properties / requires_cell_coverage / description
```
Added value: +"Require cell phone coverage"
```
  - addedInput schema / properties / requires_dump_station / description
```
Added value: +"Require RV dump station"
```
  - addedInput schema / properties / requires_electric_hookups / description
```
Added value: +"Require electric hookups"
```
  - addedInput schema / properties / requires_flush_toilets / description
```
Added value: +"Require flush toilets"
```
  - addedInput schema / properties / requires_potable_water / description
```
Added value: +"Require potable water"
```
  - addedInput schema / properties / requires_showers / description
```
Added value: +"Require shower facilities"
```
  - addedInput schema / properties / requires_water_hookups / description
```
Added value: +"Require water hookups"
```
  - addedInput schema / properties / sentiment_trending / description
```
Added value: +"Filter by trend (improving/stable/declining)"
```
  - addedInput schema / properties / states / description
```
Added value: +"US state codes to filter by (e.g., [\"CA\", \"OR\"])"
```
- Changedsearch_gear9 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / category_name / description
```
Added value: +"Filter by category (e.g., Shelter, Sleeping Gear, Furniture, Electronics)"
```
  - addedInput schema / properties / kit_name / description
```
Added value: +"Filter by kit (e.g., Basics, Camp Kitchen, Hiking, Cold Weather)"
```
  - addedInput schema / properties / limit / description
```
Added value: +"Max results (1-20, default 10)"
```
  - addedInput schema / properties / max_price / description
```
Added value: +"Maximum price in USD"
```
  - addedInput schema / properties / min_price / description
```
Added value: +"Minimum price in USD"
```
  - addedInput schema / properties / necessity / description
```
Added value: +"Filter by level — Essential, Helpful, or Optional"
```
  - addedInput schema / properties / query / description
```
Added value: +"Text search across product name, manufacturer, keywords, and description"
```
  - addedInput schema / properties / recommendation_tier / description
```
Added value: +"Filter by tier — Our Pick, Value Pick, or Comfort Pick"
```
- Changedtoggle_alert3 fields changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
  - addedInput schema / properties / alert_id / description
```
Added value: +"UUID of the alert to toggle. Get this from list_alerts."
```
  - addedInput schema / properties / api_key / description
```
Added value: +"User's Outdoorithm API key from their dashboard settings."
```
1 tool updateJun 23, 2026
- Removedquery_database
18 tool updatesApr 28, 2026
- First observedbuild_packing_list
- First observedcalculate_drive_times
- First observedcheck_availability
- First observedcheck_safety
- First observedcompare_gear
- First observedcreate_alert
- First observeddelete_alert
- First observedfind_similar_campgrounds
- First observedget_campground_details
- First observedget_gear_for_campground
- First observedget_weather
- First observedhealth_check
- First observedlist_alerts
- First observedprepare_reservation
- First observedquery_database
- First observedsearch_campgrounds
- First observedsearch_gear
- First observedtoggle_alert

Related MCP Connectors

Ranger A
io.github.alexvesely18-dot
Live US campground availability, wildfire and river conditions, and trails on public land.
Travel & Transportation Weather Services Location Services
31
Camping Australia A
au.com.trip-planner
Search Australian campsites, caravan parks and free camps; weather, gear, road trips and booking.
Travel & Transportation Location Services Weather Services
182
alertcamp AOAuth
camp.alert
Catch campsite, cabin, permit and day-use cancellations at 1,600+ parks in Canada and the US.
Location Services Travel & Transportation
261
Outdoors B
com.theoutdoorsapp
US outdoor recreation: 37k+ trails, 30k+ campgrounds, parks, weather + wildfire safety. Read-only.
Weather Services Location Services Open Data
202

Related MCP Servers

parks-mcp
Travel & Transportation Search
jclement
F
license
Not graded
quality
D
maintenance
Enables AI clients to search and browse camping availability across Alberta Parks, BC Parks, and Parks Canada, including front-country and backcountry campgrounds, through a unified set of tools.
Updated 3 months ago (2026-07-10 15:00 UTC)
-
Tentahead MCP
Search Travel & Transportation Weather Services
enharper
A
license
A
quality
D
maintenance
Connects to the Tentahead API to facilitate campsite searching and group trip planning for Illinois state parks. It provides live availability, weather forecasts, safety alerts, and EV charging data to streamline outdoor adventure planning.
Updated 7 months ago (2026-03-24 01:55 UTC)
9
MIT
Campspot MCP
Travel & Transportation E-commerce & Retail
sanjibani
A
license
A
quality
D
maintenance
Enables AI agents to query and manage campground reservations, sites, and rate plans via the Campspot Online Booking API.
Updated a month ago (2026-09-16 07:53 UTC)
8
MIT
National Parks MCP Server
Government Data Travel & Transportation Location Services
geobio
A
license
Not graded
quality
D
maintenance
Provides access to the National Park Service API to search for U.S. national parks, view park details, check alerts and closures, find visitor centers, campgrounds, and upcoming events.
Updated 2 years ago (2025-03-21 03:42 UTC)
73 npm
MIT

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?