Search curated Bangkok, Thailand tours, activities, hotels, restaurants, nightlife and services.
Scored across 5 tools
Tools are mostly distinct: get_listing retrieves a single item, list_categories and list_filters provide metadata, and search_tools search different domains. However, search_listings and search_tours both cover 'activities', which could cause minor confusion about which to use for activity-related queries.
All tool names follow a consistent snake_case verb_noun pattern: get_listing, list_categories, list_filters, search_listings, search_tours. The prefix get_, list_, and search_ clearly indicate the action, and there is no mixing of conventions.
Five tools are well-scoped for a read-only Bangkok directory. The set covers discovery (categories, filters), search (listings, tours), and detail (listings) without redundancy or missing core functionality.
The surface fully covers the domain: discovery via list_categories and list_filters, search via search_listings and search_tours, and detail retrieval via get_listing. No critical gaps are apparent for a read-only directory, as tours are handled externally via booking_url.
Read-only. Full details for one BangkokVacay 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; BangkokVacay 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 readOnly/idempotent/non-destructive, but the description adds real behavioral context: the exact return payload (description, FAQ, hours, photos with credits, booking links), the affiliate:true flag semantics, and the NOT_FOUND failure mode. It duplicates 'Read-only' from the annotations but goes well beyond them.
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?
A single dense sentence block front-loaded with the read-only and resource statement, then progressively narrower detail. Every clause carries information; only the restated 'Read-only' is redundant given the annotations.
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 enumerate return values, yet it usefully summarizes them, and annotations cover the safety profile. The notable gap is the three optional parameters, whose role in a by-id lookup is never explained.
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% – just the id field is documented. The description mentions 'by id' and the affiliate flag, but says nothing about adults, check_in, or check_out, leaving three query parameters (presumably for availability/pricing) unexplained in both the schema and the description.
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 with scope: 'Full details for one BangkokVacay listing by id.' The 'by id' framing plus the id parameter's note that it comes 'from search_listings' distinguishes this from search_listings, though the description itself never names the sibling.
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 implied rather than stated: fetch by id after searching, and the id source is given in the schema. There is no explicit when-to-use/when-not statement or named alternative for retrieving multiple or filtered listings.
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 BangkokVacay 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?
The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the leading 'Read-only.' mostly restates structured data. The description does add that the result is scoped to top-level (not nested) categories and includes counts, which is modest extra context but not deep behavioral disclosure.
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 'Read-only.' fragment is largely redundant with readOnlyHint=true, which is the only thing keeping it from a 5.
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?
A zero-parameter, read-only list tool with an output schema is nearly self-describing; the description covers what is returned (categories plus counts) and annotations cover safety. Nothing essential is missing, though a note on result shape (e.g., flat list) would round it out.
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 no parameters, so per the rubric the baseline is 4. The description correctly signals a parameterless enumeration and adds nothing misleading about inputs.
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') plus the payload detail ('with listing counts'), which is enough to distinguish it from search_listings and get_listing. It does not explicitly contrast with list_filters, but the resource noun is 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?
Usage is only implied: an agent can infer this is the discovery call for enumerating categories before drilling into listings. There is no statement of when to prefer it over list_filters or search_listings, and no exclusions.
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 BangkokVacay's curated directory of Bangkok, Thailand businesses (hotels, restaurants, bars, activities, attractions, shops and services). Read-only. Filters: keyword, category, area/neighborhood, price tier, amenities (e.g. pool, spa, river_view, rooftop, michelin), 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 BangkokVacay 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. 'rooftop bar', 'temple', 'tasting menu' | |
| tag | No | Exact listing tag, see list_filters | |
| area | No | Area/neighborhood, e.g. 'Pathum Wan', 'Sukhumvit', 'Riverside', 'Bang Rak'. 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?
Beyond the readOnly/idempotent annotations, it discloses genuinely useful behavior: booking links are provider paths, not ads; affiliate:true marks commission links; BangkokVacay may earn a commission at no extra cost; results are not commission-ranked; and live rates appear on Expedia, not in the result. This is exactly the kind of non-obvious context an agent needs.
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 purpose and filters before the return-format and booking-link disclosures. The affiliate/commission explanation runs a bit long, but each sentence carries decision-relevant information, so waste is minimal.
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-param search tool, the description covers purpose, filter surface, return shape, sibling routing, and the booking/affiliate caveats. With an output schema present it needn't detail return fields, yet it still summarizes them usefully, leaving no gap that would cause a mis-call.
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 59% schema coverage across 17 params, the description compensates by naming the filter dimensions (keyword, category, area, price tier, amenities with examples, tag, distance from lat/lng or another listing) and the check_in/check_out date-link behavior. It leaves page/sort/limit/adults/has_booking_link semantics to the schema, which is acceptable but not exhaustive.
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 (Search) and a well-scoped resource (BangkokVacay's curated Bangkok business directory), enumerating the covered verticals. It also names the sibling relationship, pointing to get_listing for full text, so an agent can distinguish it from adjacent tools without opening schemas.
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?
Clearly frames when to use it (directory search across multiple filter dimensions) and when to escalate to get_listing for full text, hours and FAQ. It doesn't explicitly contrast with search_tours or explain when list_filters/list_categories should precede it, so it stops short of full when/when-not coverage.
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 Bangkok, Thailand 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: BangkokVacay 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. 'floating market', 'food tour', 'Ayutthaya' | |
| 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 cover read-only/idempotent/open-world safety, but the description adds genuinely new behavioral context: the affiliate-link commission disclosure, that Viator confirms final price/availability/cancellation terms before payment, and that dates filter to Viator-listed availability. Minor redundancy in restating 'Read-only.'
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 the core purpose, and each sentence carries information (dates, sorting, affiliate disclosure, price confirmation). The middle return-field enumeration is a dense run-on and partially duplicates the output schema, but nothing is truly wasted.
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 field list is redundant yet harmless, and the description still covers the commercially important details (affiliate link, third-party price confirmation, date-based availability). It omits pagination/limit behavior, which is the main remaining gap for a 10-parameter search tool.
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 coverage is only 40% across 10 parameters, so the description must carry weight; it does add meaning for sort/date interactions and the 'featured' ordering, plus concrete q examples. However it says nothing about the other undocumented parameters (limit, page, currency, max_price, min_rating, free_cancellation), so it only partially compensates.
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 specific verb and resource ('Live search of bookable tours and activities in Bangkok, Thailand from Viator's partner API'), and the data source plus geographic scope implicitly separate it from generic siblings like search_listings. It never names the sibling it differs from, so the differentiation is inferable rather than explicit.
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 implied by the Bangkok-tours scope, and it explains when start_date/end_date narrow results and how the default order behaves. There is no explicit 'use this instead of X' routing against search_listings or any when-not condition, leaving the agent to infer the boundary.
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.
get_listinglist_categories2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "categories": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "description": "Category id; null for categories that exist only as listing group names (filter by name instead)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "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. 'Pathum Wan', 'Sukhumvit', 'Riverside', 'Bang Rak'. 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. 'temple' or 'rooftop'"New value: +"Keywords, e.g. 'rooftop bar', 'temple', 'tasting menu'"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 bangkokvacay.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.
Bangkok boutique planner: live Thailand journeys, prices, FAQs, and enquiry handoff.
Search & compare prices for tours, activities and tickets across multiple providers.
Search Asia travel tours, browse guides, request quotes, find upcoming group departures.
Add one secure layer between your agents and this server.
