Search Revamp's live Armenia catalog: stays, tours, restaurants; check availability; plan trips.
Scored across 5 tools
Each tool has a mostly distinct role: search_listings for discovery, get_listing for detail, get_quote for pricing/terms, plan_trip for itineraries. The one fuzzy boundary is check_availability versus get_quote, both of which answer date-based availability; the descriptions mitigate this by framing check_availability as a quick yes/no and get_quote as the itemised price, but an agent could still reasonably pick either.
All five names follow a clean verb_noun pattern (search_listings, get_listing, get_quote, check_availability, plan_trip) in consistent snake_case. The verb choice matches the action type (get for retrieval, search for discovery, check for verification, plan for generation).
Five tools is well-scoped for a read-only travel discovery surface: search, detail, availability, quote, and itinerary planning each earn their place with no filler. Nothing appears redundant enough to cut, and nothing essential feels absent from the count itself.
The read-only browsing lifecycle is well covered: discover, inspect, check availability, price, and plan. The main gaps are the deliberate absence of any booking/hold operation (stated as out of scope) and no review or map/nearby capability, which agents will have to work around when users want to actually reserve.
Check whether a stay is available for a date range, or which time slots a tour or experience has on a date. Dates are YYYY-MM-DD; for stays endDate is the check-out day. Returns available (true/false, or null with a reason when it can't be confirmed here, e.g. hotels where a room type is chosen on the page). Use get_quote for the price.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug. | |
| guests | No | Party size (default 2). | |
| endDate | No | Stays: check-out, YYYY-MM-DD. | |
| startDate | Yes | Check-in (stays) or activity date, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral detail by explaining that the result can be null with a reason when availability cannot be confirmed here, including the hotel room-type case.
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 description is front-loaded with the core availability check, then adds only the date and return-value details needed to invoke it correctly. Every sentence carries useful information, with no filler.
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 four-parameter read-only tool with no output schema, the description is complete enough: it explains the two availability modes, date semantics, the shape of the result including null cases, and when to use get_quote instead. Annotations and schema cover the remaining safety and parameter details.
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 100%, so all four parameters are already documented in the input schema. The description restates the YYYY-MM-DD format and endDate check-out semantics, but does not add much parameter meaning beyond what the schema already provides.
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 names a specific verb and resource: checking availability for a stay date range or for tour/experience time slots. It clearly distinguishes these two modes and routes pricing to get_quote, so an agent can tell what this tool is for without opening the 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?
It gives clear usage context for stays versus tours/experiences and explicitly says to use get_quote for price rather than this tool. It does not cover every sibling alternative, but the primary when-to-use guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for one listing by its slug (from search_listings): description, amenities, highlights, facts, capacity, the host's answers to common guest questions (faq — use them to answer questions about this listing), the page link, and the listing's own photos (with captions) — use these photos when showing it.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug, e.g. 'forest-house-dilijan'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds substantive context the annotations cannot: there is no output schema, so enumerating the returned sections and telling the agent how to use the faq and photo fields is genuine value. Minor gaps: no error behavior for an unknown/invalid slug.
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 dense sentence with the core action and provenance front-loaded, and no filler. It is long and dashes-and-parentheses heavy, which makes it slightly hard to scan, but every clause carries information.
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 single-parameter read tool with full annotation coverage and no output schema; the description supplies the return-value inventory and the acting instructions that the absent output schema would otherwise leave unknown. Nothing needed to call it correctly 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?
Schema coverage is 100% and the slug parameter is already documented with an example, so the baseline is 3. The description goes further by stating where the slug originates (search_listings), which disambiguates it from a listing ID or free-text query.
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?
Specific verb and resource: fetch full details for a single listing by slug. It enumerates the returned facets (description, amenities, highlights, facts, capacity, faq, link, photos) and names the sibling that produces the slug (search_listings), so an agent can distinguish it from search/availability 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?
It anchors usage to a workflow — the slug comes from search_listings — and gives downstream instructions for two payloads ('use them to answer questions about this listing', 'use these photos when showing it'). It does not state exclusions (e.g., that it should not be used for browsing or that check_availability/get_quote are needed for pricing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact availability and all-in price for one stay, tour or experience. Stays: checks the dates against the host's calendars, existing bookings, minimum stay and capacity, and returns the itemised total (accommodation, discounts, fees, tax) in AMD. Tours and experiences: returns the open time slots with seats left for that date and the total for the party. Also returns the cancellation terms, how payment works, and a link to book. Hotels list their room types (rooms are chosen on the listing page). Read-only: nothing is held or booked.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug (from search_listings). | |
| guests | No | Party size (default 2). | |
| endDate | No | Stays only: check-out date, YYYY-MM-DD (the night before is the last night). | |
| startDate | Yes | Check-in date for stays, or the activity date; YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real semantics: a quote holds nothing ('nothing is held or booked'), what the price breakdown contains (accommodation, discounts, fees, tax, in AMD), and that cancellation terms, payment mechanics and a booking link come back too. It does not mention quote expiry, auth, or failure behaviour when dates are unavailable.
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-loads the core purpose in the first sentence, then segments by listing type and finally the shared extras (cancellation, payment, booking link). Dense with specifics such as currency and slot-with-seats detail; no filler sentences.
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 no output schema, the description carries return-value explanation and does so thoroughly across both listing types. Minor gaps remain: nothing about what happens when dates are unavailable (error vs. empty result) or whether the quoted price is guaranteed for any period.
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 100%, so the baseline is 3, but the description adds meaning: startDate is check-in for stays versus the activity date for tours, dates are validated against host calendars/minimum stay/capacity, and guests drives 'the total for the party'. That clarifies how the parameters interact rather than restating field docs.
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 ('Exact availability and all-in price for one stay, tour or experience') and immediately splits the behaviour by listing type, including what is returned for each (itemised total in AMD vs. open time slots with seats). It also carves out the boundary with get_listing ('Hotels list their room types (rooms are chosen on the listing page)') and points to search_listings as the source of the slug.
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?
Provides clear context for when this applies: per-listing exact quoting for stays vs. tours, with the slug sourced 'from search_listings' and a note that hotels require a separate room choice. It does not explicitly contrast with the sibling check_availability (e.g., browse-then-quote vs. exact quote) or state exclusions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a suggested day-by-day Armenia itinerary using Revamp's published listings (stays, tours, experiences, restaurants). Returns a structured plan with listing links; it doesn't check dates or book anything — use get_quote for that.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | Trip length in days. | |
| pace | No | Default 'balanced'. | |
| budget | No | Default 'mid-range'. | |
| interests | No | e.g. ['hiking','wine','history','food']. | |
| startCity | No | Base city (default 'Yerevan'). | |
| travelers | No | Number of travelers (default 2). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, openWorld=false, but the description adds context annotations cannot: output is a 'suggested' plan with listing links and that no date validation or booking occurs. That negative capability is the highest-value disclosure here, since check_availability is a sibling an agent might otherwise assume is invoked internally. It stops short of saying how deterministic or personalized the plan is, so not a 5.
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 sentences, front-loaded with what is produced, followed by the scope limitation and the redirect. No filler, no restatement of the title.
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 no output schema, the description does state the return shape qualitatively ('structured plan with listing links'), and it closes the biggest ambiguity (no dates, no booking). Minor gap: it does not say whether pricing or availability status appears in the plan, though openWorld=false and readOnly=true suggest published static data.
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 100% with enums and defaults already documented for pace, budget, travelers, and startCity. The description adds no parameter-level guidance (e.g., how interests influence selection or what day-count means at the 14-day max). Baseline 3 applies when the schema carries the load.
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 — 'Generate a suggested day-by-day Armenia itinerary' — and names the data source (Revamp's published listings) plus the output form (structured plan with listing links). It is clearly distinguishable from get_quote, check_availability, and search_listings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly bounds the tool: it 'doesn't check dates or book anything — use get_quote for that,' naming both the exclusion and the alternative sibling. An agent knows both when to call this and where to route follow-up booking/availability work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Revamp Vacations' published listings in Armenia: places to stay, tours, experiences, restaurants (eat) and places to visit. Returns each match's slug, type, location, headline price in AMD, short description, page link, and the listing's own cover photo (image) — use that photo when showing the result. When the user gives dates, pass startDate (and endDate for stays) and guests: the search then returns only listings that are actually available for those dates, each with its exact all-in total (fees and tax included), cheapest first. For one listing's full price breakdown and terms, use get_quote.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Limit to one listing type. | |
| limit | No | Max results (default 10). | |
| query | No | Free-text match on title, description, tags, cuisine, city. | |
| guests | No | Party size (default 2) — used with dates. | |
| region | No | Armenian region or city, e.g. 'Yerevan', 'Tavush', 'Dilijan'. | |
| cuisine | No | For restaurants: a cuisine/venue type, e.g. 'Armenian', 'Fast food'. | |
| endDate | No | Stays: check-out date, YYYY-MM-DD (with startDate). | |
| startDate | No | Optional. Check-in date for stays, or the activity date, YYYY-MM-DD — returns only listings available then, with totals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, non-destructive, and closed-world, so the description does not need to repeat safety semantics. It adds substantial behavior beyond annotations by explaining return fields, that results include cover images to display, and that date-filtered searches only return available listings with exact all-in totals sorted cheapest first.
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 description is front-loaded with the tool's scope and resource types, then moves efficiently through return values, date-based availability behavior, and the get_quote alternative. The detail is dense but each sentence contributes to correct selection or invocation.
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 an eight-parameter search tool with no output schema, the description is complete enough: it explains the domains searched, the shape of returned results, the availability and pricing behavior when dates are provided, and when to use get_quote instead. Remaining details such as defaults and matching fields are adequately covered by the 100%-described input schema.
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 100%, so the baseline is 3, and the description adds meaningful semantics for the date and guest parameters: dates trigger availability filtering and exact all-in pricing. It also explains how to use the returned image field, but it leaves query, region, cuisine, type, and limit semantics mostly to the schema.
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 clear verb and resource: searching published listings in Armenia across stay, tour, experience, eat, and place types. It distinguishes the tool from get_quote by naming that sibling for full price breakdowns, but it does not explicitly contrast with check_availability, get_listing, or plan_trip.
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?
It gives practical selection guidance: pass startDate/endDate/guests when dates are supplied, and use get_quote for a single listing's full price breakdown and terms. It does not explicitly state when to avoid this tool or when to prefer check_availability or get_listing instead.
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.
search_listings1 field changedInput schema / properties / startDate / descriptionPrevious value: -"Optional. Check-in date for stays, or the activity date, YYYY-MM-DD — returns only listings free then, with totals."New value: +"Optional. Check-in date for stays, or the activity date, YYYY-MM-DD — returns only listings available then, with totals."search_listings3 fields changedInput schema / properties / endDateAdded value: +{
+ "description": "Stays: check-out date, YYYY-MM-DD (with startDate).",
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}Input schema / properties / guestsAdded value: +{
+ "description": "Party size (default 2) — used with dates.",
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / startDateAdded value: +{
+ "description": "Optional. Check-in date for stays, or the activity date, YYYY-MM-DD — returns only listings free then, with totals.",
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}check_availability5 fields changedInput schema / properties / endDate / descriptionPrevious value: -"Check-out, YYYY-MM-DD (exclusive)."New value: +"Stays: check-out, YYYY-MM-DD."Input schema / properties / guestsAdded value: +{
+ "description": "Party size (default 2).",
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / slug / descriptionPrevious value: -"The stay's slug."New value: +"The listing slug."Input schema / properties / startDate / descriptionPrevious value: -"Check-in, YYYY-MM-DD."New value: +"Check-in (stays) or activity date, YYYY-MM-DD."Input schema / requiredPrevious value: -[
- "slug",
- "startDate",
- "endDate"
-]New value: +[
+ "slug",
+ "startDate"
+]get_quotecheck_availabilityget_listingplan_tripsearch_listingsTravel search: 1.3M hotels and apartments, owner homes, tours, flights, taxi, car rental.
Search hotels worldwide, compare live room rates, and create booking payment links.
Book shared or private rides between Tbilisi and Yerevan: live prices, schedule, booking requests.
Live hotel rates worldwide: search stays, property detail, all-in room prices, human phone desk.
Add one secure layer between your agents and this server.