Threshold

Request to book

request_booking

Request a stay from a quote. Set house_rules_accepted only after the guest has seen and agreed to the quote's house_rules. If the quote's payment.collected_by is "threshold", the booking starts as awaiting_payment and the response includes payment_url: the guest must open payment_url and add a card within 60 minutes, after which the host gets the request (status pending_host_confirmation). Otherwise the request goes to the host immediately and the host arranges payment after accepting. Returns the booking and a status link to give the guest; poll get_booking for changes.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	The guest's email: confirmations, the payment link and the host's messages go there.
`phone`	No	The guest's phone number in international format, e.g. +15551234567. Optional.
`quote_id`	Yes	The quote being booked, from get_quote (starts with quo_).
`last_name`	Yes	The guest's last name.
`first_name`	Yes	The guest's first name.
`special_requests`	No	Anything the guest wants the host to know, in their words (arrival time, a question). Optional, up to 500 characters.
`house_rules_accepted`	Yes	True only after the guest has seen and agreed to the quote's house_rules.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`booking`	No	The booking.
`payment_url`	No	When present, the guest opens this to add a card; the request reaches the host only after that.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 14, 2026

addedInput schema / properties / email / description

Added value: +"The guest's email: confirmations, the payment link and the host's messages go there."

addedInput schema / properties / first_name / description
```
Added value: +"The guest's first name."
```

addedInput schema / properties / house_rules_accepted / description

Added value: +"True only after the guest has seen and agreed to the quote's house_rules."

addedInput schema / properties / last_name / description
```
Added value: +"The guest's last name."
```

addedInput schema / properties / phone / description

Added value: +"The guest's phone number in international format, e.g. +15551234567. Optional."

addedInput schema / properties / quote_id / description

Added value: +"The quote being booked, from get_quote (starts with quo_)."

addedInput schema / properties / special_requests / description

Added value: +"Anything the guest wants the host to know, in their words (arrival time, a question). Optional, up to 500 characters."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "A booking or booking request.",
+  "properties": {
+    "booking": {
+      "additionalProperties": true,
+      "description": "The booking.",
+      "properties": {
+        "check_in": {
+          "type": "string"
+        },
+        "check_out": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "property_id": {
+          "type": "string"
+        },
+        "status": {
+          "description": "e.g. awaiting_payment, pending_host_confirmation, confirmed, declined, cancelled.",
+          "type": "string"
+        },
+        "total": {
+          "description": "An amount in cents with its currency.",
+          "properties": {
+            "amount": {
+              "type": "integer"
+            },
+            "currency": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "payment_url": {
+      "description": "When present, the guest opens this to add a card; the request reaches the host only after that.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare this is a non-destructive open-world write; the description goes far beyond that by disclosing two distinct post-call state machines (awaiting_payment → pending_host_confirmation, or straight to host), the hard 60-minute card window, the payment_url hand-off obligation, and who collects payment in each branch.

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?

Front-loads the action, then the consent rule, then the conditional payment path, then the return/polling note. Every sentence carries operational information; nothing is repeated from the schema or annotations.

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 7-param booking mutation with an output schema, the description covers the precondition, the divergent async flows, the guest-facing deadline, and the polling tool for status changes. Nothing an agent needs to call it correctly or set expectations downstream 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 most parameter meaning is already structured (email routing, phone format, quote_id prefix, special_requests length). The description still adds real semantics for the trickiest field, house_rules_accepted: it must only be true after the guest has reviewed and agreed to the quote's house_rules, which is an ordering constraint the schema alone does not convey.

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+resource ('Request a stay from a quote') and scopes it to a quote object, which cleanly separates it from get_quote, check_availability, and search_stays. An agent can pick this tool without opening any schema.

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?

Gives explicit preconditions (must come from a quote; house_rules_accepted only after the guest has seen and agreed to the rules) and names the follow-up alternative: 'poll get_booking for changes' rather than re-calling this tool. It even branches usage on quote state (payment.collected_by == 'threshold' vs. otherwise).

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

All Threshold 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?