Search 355+ curated Vail Valley, Colorado restaurants, hotels, activities, shops and services.
Scored across 5 tools
The two search tools (search_listings, search_tours) are distinct in source and purpose: one searches VailVacay's curated directory, the other queries Viator's live API for bookable tours. get_listing, list_categories, and list_filters are clearly separate read operations. A user might briefly conflate listings and tours, but the descriptions make the boundary clear.
All tool names follow a consistent verb_noun pattern: get_listing, list_categories, list_filters, search_listings, search_tours. There are no style deviations or mixed conventions.
Five tools form a well-scoped set for a directory server: retrieval, browsing metadata, and two search modes. Each tool earns its place, and the count matches the domain without bloat.
The surface covers core read operations: full listing details, category/filter discovery, and search for both directory listings and live tours. No write operations exist, which is appropriate for a read-only directory, but lacking pagination controls or a direct get_tour tool for a specific tour is a minor gap.
Read-only. Full details for one VailVacay listing by id: complete plain-text description, FAQ, hours, up to 10 gallery photos with captions and credits (e.g. 'Photo via Expedia'), listing page URL, and booking links (the path to book with the named provider, not ads). Links marked affiliate:true are affiliate links; VailVacay may earn a commission at no extra cost to the user. Returns NOT_FOUND for an unknown id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id from search_listings | |
| adults | No | ||
| check_in | No | ||
| check_out | No |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| listing | Yes | |
| affiliate_disclosure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint, so the leading 'Read-only.' is partly redundant, but the description adds real behavioral context the annotations do not: NOT_FOUND on an unknown id and the affiliate-link/commission semantics. It still does not explain pagination or how the booking-link 'path' behaves, so it is not fully rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The payload is packed into a single front-loaded sentence led by the operation and its return contents, with zero filler. It is long but each clause enumerates a distinct returned field, so the length is largely earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because an output schema exists, the description does not need to enumerate return values, yet it does so thoroughly; the real gap is that three of four parameters remain undefined. Combined with sibling routing being only implicit, the definition is adequate but leaves clear holes for a tool that accepts availability-style parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%; only id is documented, and the description merely echoes that by referring to lookup 'by id'. The adults, check_in, and check_out parameters, which are presumably needed to shape booking links, are left entirely unexplained in both schema and description, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Full details for one VailVacay listing by id') and enumerates what it returns (description, FAQ, hours, photos, URL, booking links), which cleanly separates it from the sibling search_listings. An agent can distinguish the detail-fetch from the search tools without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the id parameter's schema description says it comes from search_listings, and the description notes NOT_FOUND for an unknown id, hinting at a lookup-after-search flow. There is no explicit statement of when to use this versus search_listings or the other siblings, and no exclusions or prerequisites beyond that implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. List the VailVacay directory's top-level categories with listing counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| total | No | |
| status | Yes | |
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description's 'Read-only' simply repeats that. It adds only the mild behavioral detail that results include listing counts, which the output schema likely covers anyway; nothing contradictory, but little new context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the leading 'Read-only' is redundant against the annotations, which is the only wasted fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a zero-parameter schema, rich annotations and an output schema, the description only needs to convey purpose and scope, which it does. Minor unstated details (ordering of categories, whether counts include unpublished listings) do not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies and there is nothing for the description to disambiguate. No parameter guidance is needed or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List ... top-level categories') and adds useful scope detail ('top-level', 'with listing counts') so an agent knows what comes back. It does not differentiate itself from the closest sibling, list_filters, which an agent could easily confuse with a category listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no alternative named, despite list_filters being a plausible substitute for browsing the directory. The description only implies usage through its verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Values usable in search_listings: areas/neighborhoods, price tiers, amenities and tags, each with listing counts, plus notes on how each is derived.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tags | No | |
| areas | No | |
| status | Yes | |
| amenities | No | |
| price_tiers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the leading 'Read-only.' is redundant. The description does add genuine value with 'each with listing counts, plus notes on how each is derived', disclosing the shape/nature of the returned data 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the content categories and their consumers. The opening 'Read-only.' wastes a few words by repeating the annotation, but otherwise every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not explain return values, and it does enough by naming the filter categories and the derived counts/notes. For a zero-parameter read-only reference tool, an agent has what it needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to compensate for. Schema coverage is 100% and the description correctly does not invent arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete resource — filter values (areas/neighborhoods, price tiers, amenities, tags) with listing counts — and ties it to the sibling tool search_listings, so an agent can tell it is the metadata/reference lookup rather than a search. It never uses an explicit verb like 'list', but the enumeration of contents makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Values usable in search_listings' implies the usage context (discover valid filter values before searching), which is reasonable guidance. However, it never states when to call this versus list_categories or search_listings directly, and gives no prerequisites or ordering advice, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search VailVacay's curated directory of Vail, Colorado businesses (hotels and lodging, restaurants, bars and après-ski, activities, ski shops, shopping, services and spas). Read-only. Filters: keyword, category, area/neighborhood, price tier, amenities (e.g. ski_in_ski_out, walk_to_lifts, hot_tub, pool, pet_friendly), tag, and distance from a lat/lng or from another listing. Returns compact plain-text listings (description shortened; use get_listing for the full text, hours and FAQ) with the listing page URL, address, phone, website, up to 2 credited photos, and booking links. Booking links are the path to book with the named provider (Expedia for hotels, plus Viator/Klook where the listing has one), not ads; those marked affiliate:true are affiliate links, and VailVacay may earn a commission if the user books, at no extra cost to them. Results are not ranked by commission. Pass check_in/check_out to get date-specific Expedia hotel links (live rates are shown on Expedia, not in this result).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keywords, e.g. 'steak', 'ski rental', 'hot tub condo' | |
| tag | No | Exact listing tag, see list_filters | |
| area | No | Area/neighborhood, e.g. 'Vail Village', 'Lionshead', 'Golden Peak', 'Cascade Village'. See list_filters. | |
| page | No | ||
| sort | No | ||
| limit | No | ||
| adults | No | ||
| category | No | Category name or id from list_categories, e.g. 'Hotels' | |
| check_in | No | YYYY-MM-DD (hotels) | |
| near_lat | No | ||
| near_lng | No | ||
| amenities | No | All must match | |
| check_out | No | YYYY-MM-DD | |
| radius_km | No | Max distance (km) when near_* is set | |
| price_tier | No | ||
| near_listing_id | No | Rank by distance from this listing | |
| has_booking_link | No | Only listings with a booking link |
| Name | Required | Description |
|---|---|---|
| page | No | |
| total | Yes | |
| status | Yes | |
| has_more | No | |
| listings | Yes | |
| per_page | No | |
| returned | No | |
| data_fetched_at | No | |
| affiliate_disclosure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, but the description adds substantial behavior beyond them: booking links are direct provider paths rather than ads, affiliate:true items carry a commission disclosure at no extra cost, results are explicitly not ranked by commission, live rates appear only on Expedia, and results are compact plain-text. These are decision-relevant traits an agent could not infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with scope, then filters, then result shape and booking disclosure — a sensible order with little filler. The single long sentence on booking links/affiliate status is dense but every clause is decision-relevant, so only mild tightening is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter, zero-required search tool with an output schema, the description covers scope, filter surface, result payload (compact text, URL, address, phone, website, photos, booking links), and the affiliate/ranking caveat that an agent must relay to users. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 59% across 17 params, the description compensates by enumerating the filter families (keyword, category, area, price tier, amenities with concrete examples, tag, distance from lat/lng or another listing) and clarifies that check_in/check_out drive date-specific Expedia links. It adds real meaning for the date params and near_listing_id, though it does not explain sort/limit/adults or pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search VailVacay's curated directory of Vail, Colorado businesses') and enumerates the covered categories, so the agent knows exactly what corpus this searches. It also distinguishes itself from get_listing ('use get_listing for the full text, hours and FAQ') and points to list_filters/list_categories, making it separable from siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear routing context: use get_listing when full description, hours and FAQ are needed, and pass check_in/check_out to get date-specific hotel links. It does not, however, state when to prefer this over search_tours or any exclusion on when this tool is inappropriate, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Live search of bookable tours and activities in Vail, Colorado from Viator's partner API. Returns title, live starting ('from') price and currency, rating, review count, duration, free-cancellation flag, image and a booking_url. Optional start_date/end_date return only products Viator lists as available on those dates. Default order: keyword relevance when q is given, otherwise traveler rating; 'featured' uses Viator's own default order. booking_url is the Viator booking page and a Viator affiliate link: VailVacay may earn a commission if the user books, at no extra cost to them. Viator confirms the final price, availability and cancellation terms before payment.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keywords, e.g. 'jeep tour', 'fly fishing', 'mountain bike' | |
| page | No | ||
| sort | No | Default: relevance to q when q is given (Viator keyword match), otherwise rating (highest traveler rating first). featured = Viator's own default order. | |
| limit | No | ||
| currency | No | USD | |
| end_date | No | YYYY-MM-DD | |
| max_price | No | ||
| min_rating | No | ||
| start_date | No | YYYY-MM-DD | |
| free_cancellation | No |
| Name | Required | Description |
|---|---|---|
| total | No | |
| tours | Yes | |
| status | Yes | |
| prices_checked_at | No | |
| affiliate_disclosure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, but the description adds genuinely new behavioral context: results are live, the booking_url is a Viator affiliate link carrying a commission disclosure, and Viator confirms the final price, availability and cancellation terms before payment. It doesn't cover rate limits or pagination behavior, but the third-party/affiliate caveats are meaningful value beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with read-only and the core purpose, then return fields, filters, ordering and the affiliate disclaimer. Dense but mostly earns its space; the sentence restating the default sort order duplicates the schema's own sort description almost verbatim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and an output schema existing, the description's job is largely framing; it is complete enough to call the tool correctly and even over-delivers by enumerating return fields. The only real gap is the absence of sibling differentiation against search_listings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description carries added burden. It does explain start_date/end_date semantics (return only products available on those dates) and the sort defaults, but it largely restates the enum description already in the schema and leaves currency, max_price, min_rating, free_cancellation, page and limit semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Live search'), resource ('bookable tours and activities'), geography (Vail, Colorado) and data source (Viator partner API). However, it never distinguishes this tool from the sibling search_listings, which an agent could plausibly confuse with tour search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by 'Live search of bookable tours'; there is no explicit when-to-use statement, no exclusions, and no routing to siblings such as search_listings, get_listing, list_categories or list_filters for browsing or detail lookups. The sorting defaults hint at how results are ordered but not when to pick this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_categories2 fields changedOutput schema / properties / categories / items / properties / id / descriptionAdded value: +"Category id; null for categories that exist only as listing group names (filter by name instead)"Output schema / properties / categories / items / properties / id / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]search_tours3 fields changedInput schema / properties / sort / defaultRemoved value: -"featured"Input schema / properties / sort / descriptionPrevious value: -"featured = Viator's default ranking"New value: +"Default: relevance to q when q is given (Viator keyword match), otherwise rating (highest traveler rating first). featured = Viator's own default order."Input schema / properties / sort / enumPrevious value: -[
- "featured",
- "rating",
- "price_low",
- "price_high"
-]New value: +[
+ "relevance",
+ "rating",
+ "price_low",
+ "price_high",
+ "featured"
+]get_listinglist_categories2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "categories": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "listing_count": {
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "status",
+ "categories"
+ ],
+ "type": "object"
+}list_filterssearch_listings22 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / adultsAdded value: +{
+ "default": 2,
+ "maximum": 14,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / amenitiesAdded value: +{
+ "description": "All must match",
+ "items": {
+ "enum": [
+ "ski_in_ski_out",
+ "walk_to_lifts",
+ "pool",
+ "hot_tub",
+ "spa",
+ "fitness_center",
+ "pet_friendly",
+ "parking",
+ "shuttle",
+ "family_friendly",
+ "breakfast",
+ "kitchen",
+ "rooftop",
+ "river_view",
+ "outdoor_seating",
+ "apres_ski",
+ "live_music",
+ "free_entry",
+ "michelin",
+ "wheelchair_accessible"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / areaAdded value: +{
+ "description": "Area/neighborhood, e.g. 'Vail Village', 'Lionshead', 'Golden Peak', 'Cascade Village'. See list_filters.",
+ "type": "string"
+}Input schema / properties / category / descriptionPrevious value: -"Category name filter, e.g. 'Restaurants'"New value: +"Category name or id from list_categories, e.g. 'Hotels'"Input schema / properties / check_inAdded value: +{
+ "description": "YYYY-MM-DD (hotels)",
+ "type": "string"
+}Input schema / properties / check_outAdded value: +{
+ "description": "YYYY-MM-DD",
+ "type": "string"
+}Input schema / properties / has_booking_linkAdded value: +{
+ "description": "Only listings with a booking link",
+ "type": "boolean"
+}Input schema / properties / limit / descriptionRemoved value: -"Max results (1-50)"Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / near_latAdded value: +{
+ "type": "number"
+}Input schema / properties / near_listing_idAdded value: +{
+ "description": "Rank by distance from this listing",
+ "type": "string"
+}Input schema / properties / near_lngAdded value: +{
+ "type": "number"
+}Input schema / properties / page / descriptionRemoved value: -"Page number"Input schema / properties / page / minimumAdded value: +1Input schema / properties / price_tierAdded value: +{
+ "enum": [
+ "budget",
+ "moderate",
+ "upscale",
+ "luxury"
+ ],
+ "type": "string"
+}Input schema / properties / q / descriptionPrevious value: -"Keyword search, e.g. 'steak' or 'ski rental'"New value: +"Keywords, e.g. 'steak', 'ski rental', 'hot tub condo'"Input schema / properties / radius_kmAdded value: +{
+ "description": "Max distance (km) when near_* is set",
+ "type": "number"
+}Input schema / properties / sortAdded value: +{
+ "enum": [
+ "relevance",
+ "distance",
+ "name"
+ ],
+ "type": "string"
+}Input schema / properties / tagAdded value: +{
+ "description": "Exact listing tag, see list_filters",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "affiliate_disclosure": {
+ "type": "string"
+ },
+ "data_fetched_at": {
+ "type": "string"
+ },
+ "has_more": {
+ "type": "boolean"
+ },
+ "listings": {
+ "items": {
+ "properties": {
+ "address": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "amenities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "area": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "booking": {
+ "items": {
+ "properties": {
+ "affiliate": {
+ "type": "boolean"
+ },
+ "label": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "booking_link": {
+ "description": "First affiliate booking link, if any",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "description": "Plain text",
+ "type": "string"
+ },
+ "distance_km": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "lon": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "phone": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "photo_details": {
+ "items": {
+ "properties": {
+ "caption": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "credit": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "photos": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "price_tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "description": "Listing page on vailvacay.com",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "website": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "page": {
+ "type": "integer"
+ },
+ "per_page": {
+ "type": "integer"
+ },
+ "returned": {
+ "type": "integer"
+ },
+ "status": {
+ "type": "string"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "status",
+ "total",
+ "listings"
+ ],
+ "type": "object"
+}search_tourslist_categoriessearch_listingsSearch curated Boston, MA tours, activities, hotels, restaurants, nightlife and services.
Search curated Bangkok, Thailand tours, activities, hotels, restaurants, nightlife and services.
Daily-verified Colorado kids' camps & after-school programs: real availability, ages, prices.
Search nearly 20,000 verified restaurants and bars across 24 cities plus the New Mexico region, with venue detail and curated lists.
Add one secure layer between your agents and this server.
