Threshold

Search vacation rentals

search_stays

Read-only

Find verified independent vacation rentals. Filters are strict: every listed amenity must be present. With dates, results include a cached availability signal and an indicative all-in total (no guest service fee). Maps to GET /v1/search.

Input Schema

TableJSON Schema

Name	Required	Description
`pets`	No	Number of pets. Only places that allow that many are returned. Service animals don't count as pets.
`limit`	No	Most results to return, 1 to 50. Default 8.
`place`	No	Town and state/country, e.g. 'Asheville, NC'. Use near_lat/near_lng instead when you have coordinates.
`adults`	No	Number of adults. Default 2.
`infants`	No	Number of infants under 2.
`check_in`	No	Arrival date, YYYY-MM-DD. With check_out, only places free for the whole stay are returned, with an indicative total.
`children`	No	Number of children aged 2 to 12.
`near_lat`	No	Latitude to search around, with near_lng. Use instead of place when you have coordinates.
`near_lng`	No	Longitude to search around, with near_lat.
`amenities`	No	Amenity codes, e.g. hot_tub, wifi, ev_charger, dedicated_workspace, pool, fireplace_wood.
`check_out`	No	Departure date, YYYY-MM-DD (the morning the guests leave).
`radius_km`	No	How far from near_lat/near_lng to search, in kilometres. Default 30.
`instant_only`	No	True to return only places that confirm instantly, without waiting for the host.
`min_bedrooms`	No	Fewest bedrooms the place must have.
`max_total_usd`	No	Maximum all-in total in dollars. Requires dates.
`min_wifi_mbps`	No	Lowest Wi-Fi download speed needed, in megabits per second.
`step_free_entrance`	No	True to return only places with a step-free way in.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`results`	No
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 14, 2026

addedInput schema / properties / adults / description
```
Added value: +"Number of adults. Default 2."
```

addedInput schema / properties / check_in / description

Added value: +"Arrival date, YYYY-MM-DD. With check_out, only places free for the whole stay are returned, with an indicative total."

addedInput schema / properties / check_out / description

Added value: +"Departure date, YYYY-MM-DD (the morning the guests leave)."

addedInput schema / properties / children / description
```
Added value: +"Number of children aged 2 to 12."
```
addedInput schema / properties / infants / description
```
Added value: +"Number of infants under 2."
```

addedInput schema / properties / instant_only / description

Added value: +"True to return only places that confirm instantly, without waiting for the host."

addedInput schema / properties / limit / description

Added value: +"Most results to return, 1 to 50. Default 8."

addedInput schema / properties / min_bedrooms / description
```
Added value: +"Fewest bedrooms the place must have."
```

addedInput schema / properties / min_wifi_mbps / description

Added value: +"Lowest Wi-Fi download speed needed, in megabits per second."

addedInput schema / properties / near_lat / description

Added value: +"Latitude to search around, with near_lng. Use instead of place when you have coordinates."

addedInput schema / properties / near_lng / description

Added value: +"Longitude to search around, with near_lat."

addedInput schema / properties / pets / description

Added value: +"Number of pets. Only places that allow that many are returned. Service animals don't count as pets."

changedInput schema / properties / radius_km / default
```
Previous value: -25New value: +30
```

addedInput schema / properties / radius_km / description

Added value: +"How far from near_lat/near_lng to search, in kilometres. Default 30."

addedInput schema / properties / step_free_entrance / description

Added value: +"True to return only places with a step-free way in."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Matching places, best match first.",
+  "properties": {
+    "next_cursor": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "results": {
+      "items": {
+        "additionalProperties": true,
+        "description": "A place.",
+        "properties": {
+          "bedrooms": {
+            "type": "integer"
+          },
+          "booking_mode": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "indicative_total": {
+            "description": "An amount in cents with its currency.",
+            "properties": {
+              "amount": {
+                "type": "integer"
+              },
+              "currency": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "locality": {
+            "type": "string"
+          },
+          "max_guests": {
+            "type": "integer"
+          },
+          "region": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          },
+          "verified": {
+            "type": "boolean"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

First observedOct 2, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare read-only, non-destructive, closed-world behavior, yet the description adds real context: amenity filters are conjunctive, and supplying dates yields a cached (not live) availability signal plus an indicative all-in total excluding guest service fees. That 'cached'/'indicative' qualifier is exactly the kind of caveat an agent needs and is not in 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with purpose, then the two highest-value behavioral facts (strict amenity matching, date-driven signals). Nothing is padded; even the endpoint mapping is a single clause.

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-value explanation is not owed. For a 17-parameter, zero-required search tool the description covers purpose, filter strictness and date behavior adequately, though it omits any note on empty-result behavior or how limit/pagination affects result shaping.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: every listed amenity must be present (AND, not OR), and the interaction between dates and the returned total/availability signal. It does not, however, clarify priority between place and near_lat/near_lng or radius behavior beyond what the schema states.

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 ('Find verified independent vacation rentals') and the word 'search' plus 'verified independent' distinguishes it from the single-property sibling get_property. It never names a sibling or explicitly contrasts with check_availability/get_quote, so it stops short of full 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 the search framing and by 'With dates, results include a cached availability signal', which hints when date filters are worthwhile. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as check_availability or get_property.

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?