Skip to main content
Glama

Campiamo Campsites

by com.campiamo
OverviewDiscussionsAdmin

Check availability

check_availability
Read-onlyIdempotent

Live availability at one campsite for a stay and party. Returns the accommodation types that can take the party with the total price and the amount due at checkout, and explains why the others cannot (fully booked, minimum stay, adults only, no dogs).

Input Schema

NameRequiredDescriptionDefault
dogsNoNumber of dogs.
adultsNoNumber of adults.
infantsNoNumber of infants, only at campsites whose age_policy has infants_under_age. Infants are never charged.
campsiteYesThe campsite slug, as returned by search_campsites.
check_inYesArrival date, YYYY-MM-DD.
childrenNoNumber of children. Which ages count as a child varies by campsite: see age_policy on get_campsite (default: everyone under 18).
check_outYesDeparture date, YYYY-MM-DD. Must be after check_in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / children / description
      Previous value: -"Number of children (under 18)."New value: +"Number of children. Which ages count as a child varies by campsite: see age_policy on get_campsite (default: everyone under 18)."
    • addedInput schema / properties / infants
      Added value: +{
+  "default": 0,
+  "description": "Number of infants, only at campsites whose age_policy has infants_under_age. Infants are never charged.",
+  "maximum": 20,
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the description's real contribution is behavioral detail it adds beyond them: it returns not just availability but pricing (total price, amount due at checkout) and explains negative results by reason (fully booked, minimum stay, adults only, no dogs). That is genuinely useful for interpreting an empty result, though it says nothing about rate limiting or how 'live' data may change.

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?

A single dense sentence with the purpose front-loaded and the explanatory parenthetical at the end; every clause carries information about scope or output. It is long and slightly run-on, but no sentence is 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 no output schema, the description carries the return-value burden and does so adequately, enumerating the result categories and the reason codes for non-availability. It stops short of covering error conditions (bad slug, check_out before check_in) but covers what an agent needs to interpret a normal response.

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 all seven parameters (including the age-policy nuance for children and the infants constraint) are already documented in the schema. The description adds only the word 'party' and echoes the dog/adult restrictions as exclusion reasons; it contributes no format, default, or interaction detail beyond the schema. 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 ('Live availability at one campsite for a stay and party') and immediately scopes it to a single campsite, which separates it from search_campsites and get_quote without naming them. It also discloses the substance of the result (accommodation types, total price, amount due), so an agent knows what it is asking for.

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 phrase 'for a stay and party' implies the pre-booking check context, but the description never says when to use this versus get_quote or start_booking, nor any prerequisite (e.g. campsite slug must come from search_campsites). Usage is inferable rather than stated.

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

All Campiamo Campsites 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