Campiamo Campsites

Start a booking

start_booking

Start a booking and get a secure checkout link for the guest. Nothing is reserved until the guest pays on that link (valid 24 hours). Only works at campsites that take payment online (assistant_can_book is true); elsewhere send the guest to the booking_url to book themselves. Requires the guest's name and email, which the campsite uses for the confirmation. Confirm every detail with the guest first. Rate limited.

Input Schema

Name	Required	Description
`dogs`	No	Number of dogs.
`guest`	Yes
`notes`	No	A message for the campsite (arrival time, requests).
`adults`	Yes	Number of adults.
`extras`	No	Optional extras from get_campsite (electric hook-up, firewood, late checkout...).
`answers`	No	Answers to the campsite's booking_questions from get_campsite, keyed by question id. Required questions must be answered.
`infants`	No	Number of infants, only at campsites whose age_policy has infants_under_age. Infants are never charged.
`campsite`	Yes	The campsite slug, as returned by search_campsites.
`check_in`	Yes	Arrival date, YYYY-MM-DD.
`children`	No	Number of children. Which ages count as a child varies by campsite: see age_policy on get_campsite (default: everyone under 18).
`check_out`	Yes	Departure date, YYYY-MM-DD. Must be after check_in.
`child_ages`	No	One age per child, if known.
`voucher_code`	No	A gift voucher code, if the campsite sells them.
`discount_code`	No	A promotional code the guest has, if the campsite accepts them.
`club_membership`	No	Required when get_campsite lists a members-only club under club_memberships. status "member" with the guest's membership identifier in "number" (a membership number, or where the club's identifier is "email", such as the Greener Camping Club, the email address the membership is registered to), or "join" where the club allows joining at booking (the fee is added to the total).
`accommodation_id`	Yes	accommodation_id from check_availability or get_campsite.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 29, 2026

changedInput schema / properties / club_membership / description

Previous value: -"Required when get_campsite lists a members-only club under club_memberships. status \"member\" with the guest's membership number, or \"join\" where the club allows joining at booking (the fee is added to the total)."New value: +"Required when get_campsite lists a members-only club under club_memberships. status \"member\" with the guest's membership identifier in \"number\" (a membership number, or where the club's identifier is \"email\", such as the Greener Camping Club, the email address the membership is registered to), or \"join\" where the club allows joining at booking (the fee is added to the total)."

addedInput schema / properties / club_membership / properties / number / description

Added value: +"Membership number, or membership email for clubs whose identifier is email."

changedInput schema / properties / club_membership / properties / number / maxLength
```
Previous value: -40New value: +255
```

Changed2 schema fields changedSep 28, 2026

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"
+}

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / club_membership

Added value: +{
+  "description": "Required when get_campsite lists a members-only club under club_memberships. status \"member\" with the guest's membership number, or \"join\" where the club allows joining at booking (the fee is added to the total).",
+  "properties": {
+    "club": {
+      "description": "The club key from club_memberships.",
+      "type": "string"
+    },
+    "number": {
+      "maxLength": 40,
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "member",
+        "join"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "club",
+    "status"
+  ],
+  "type": "object"
+}

First observedSep 24, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Although annotations already declare readOnlyHint=false and idempotentHint=false, the description adds context annotations cannot express: deferred commitment ('Nothing is reserved until the guest pays'), the 24-hour link expiry, the downstream use of the guest's email for confirmation, and an explicit rate limit. These are exactly the behavioral traits an agent must know before calling.

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?

Six short sentences, each carrying a distinct fact (capability, deferred payment, eligibility, fallback path, guest prerequisites, confirmation instruction, rate limit). The most decision-relevant constraint (nothing reserved until payment) is front-loaded; there is 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?

For a 16-parameter, nested, non-idempotent mutation with no output schema, the description covers eligibility, prerequisites, guest confirmation, and the return artifact (checkout link), so return values need not be explained. It omits any instruction to verify availability/price first (e.g. via check_availability or get_quote), a workflow step an agent would otherwise have to infer.

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 94%, so the schema already documents nearly every parameter in depth. The description only restates the guest name/email requirement, which the schema already explains ('Where the confirmation is sent'), and adds nothing about extras, answers, children/age_policy, or club_membership. Baseline 3 is correct when the schema does the heavy lifting.

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 ('Start a booking') plus the concrete artifact produced ('a secure checkout link for the guest'), and clarifies that nothing is reserved until payment. It does not explicitly differentiate itself from the sibling get_quote, which an agent could reasonably confuse it with, so it falls short of a 5.

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?

Explicit when-to-use conditions ('Only works at campsites that take payment online (assistant_can_book is true)'), an explicit alternative path for when it does not apply ('send the guest to the booking_url to book themselves'), plus a prerequisite ('Confirm every detail with the guest first'). This is close to textbook routing guidance.

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

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