Sorted Travel is a personal travel planner. Ask for destination ideas, flights, weather, visa rules, activities, safety and health advice, or an eSIM. We rank places using routes from your city, climate for your dates, flight and hotel prices, entry requirements for your passport, as well as your interests.
Scored across 10 tools
Most tools have clearly distinct purposes (visa check, resolve, info, weather, recommend, profile read/update), and the render_* tools are unambiguously paired with their get_* counterparts. The only soft spots are get_destination_info vs get_destination_weather, whose descriptions spend considerable effort deflecting from each other, and resolve_destination vs get_destination_info, which share the place-lookup territory.
Every tool follows a clean snake_case verb_noun pattern (get_, render_, resolve_, check_, update_) with no mixing of conventions or casing styles. The render_/get_ pairing is itself a predictable, learnable convention.
Ten tools is well-scoped for a travel planning/info server, and each one earns its place: five data/action tools, three paired render tools, and two profile tools. Nothing feels redundant or padded.
The surface covers the core lifecycle: resolve a place, fetch info/weather/recommendations, check visas, and read/update profile preferences, plus rendering for each data tool. Gaps exist around flights/booking (explicitly out of scope) and there is no create/delete for profile-level entities, but agents can work around these within the stated data-only purpose.
Check visa hassle for a passport country and destination country.
Use visa-table country names (Ireland, not Irish; USA, not United States). Common aliases are accepted and normalized. This is planning context, not official immigration advice. Cite only place_url or source_url from this result (sorted.travel only — never invent domains).
| Name | Required | Description | Default |
|---|---|---|---|
| user_visas | No | Visas the traveler holds. Use exact uppercase codes such as UK, SCHENGEN, or NEW_ZEALAND. | |
| passport_country | Yes | Visa-table passport country name. Use USA, not United States. | |
| destination_handle | No | Optional Sorted destination handle to attach a place_url link in the response. | |
| destination_country | Yes | Visa-table destination country name. Use USA, not United States. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description correctly focuses on other traits: alias normalization behavior and a citation constraint restricting domains to sorted.travel's place_url/source_url. This is meaningful added context 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?
Purpose is front-loaded in the first sentence, followed by naming convention, disclaimer, and citation rule. Every sentence adds a usable instruction, though the trailing citation rule reads more like response-handling guidance than tool selection and slightly pads the entry.
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, return values need not be explained, and the description covers naming, disclaimers, and citation sourcing. For a low-complexity read-only lookup this is nearly complete; only the user_visas code semantics live solely in the 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 description coverage is 100%, so the baseline is 3; the description adds value by stating that common aliases are accepted and normalized, which is not conveyed by the schema's per-field descriptions. The naming example overlaps the schema's own 'Use USA, not United States' notes.
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 ('Check') and resource ('visa requirements') plus the two defining inputs (passport country and destination country). No sibling covers visas, so an agent can select this tool unambiguously from the destination/weather/profile family.
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 usage context: how to phrase country inputs and an explicit caveat that output is 'planning context, not official immigration advice.' It does not name any alternative tool, but there is no competing visa sibling, so the caveat plus naming guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Sorted on-the-ground facts for one destination handle.
Default tool for generic destination info ("info on Dubai", "tell me about Lisbon", "what is Tokyo like"). Returns brief, safety, currency, phone code, eSIM notes, and taxi apps. Use a sitemap handle such as hanoi, paris, or tokyo. If you only have a city, country, or airport name, call resolve_destination first. Do not use get_destination_weather for those generic info asks. Use get_destination_weather only when the traveler explicitly asks for current weather, a 7-day forecast, monthly climate, best months, or when to visit. Send the traveler to place_url for the full page. Do not use this for bookings. This tool returns data only. After a successful call, always call render_destination_info so the place card appears.
| Name | Required | Description | Default |
|---|---|---|---|
| destination_handle | Yes | Sorted sitemap handle such as paris, hanoi, or tokyo. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely new behavior: it 'returns data only', must be followed by render_destination_info to surface the card, and is not for bookings. These workflow constraints go well beyond what the structured fields convey.
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?
It is front-loaded with the core purpose and every clause routes the agent somewhere useful, but the weather/climate exclusion runs to two dense sentences and could be tightened without losing meaning. No filler, though – all content is operational.
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?
An output schema exists, so return values need no explanation, and the description still covers the required follow-up render call, the input prerequisite, and the scope boundary against weather and booking siblings. Nothing an agent needs to invoke this 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 description coverage is 100% and the handle format is already documented in the schema ('Sorted sitemap handle such as paris, hanoi, or tokyo'). The description's handle examples and the resolve_destination fallback add modest routing value but no new argument semantics, so the baseline 3 applies.
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 opening sentence gives a specific verb and resource ('Get Sorted on-the-ground facts for one destination handle') and enumerates the payload (brief, safety, currency, phone code, eSIM notes, taxi apps). It explicitly separates itself from get_destination_weather and resolve_destination, so an agent can pick it 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?
It names this as the default for generic info asks with example utterances, states the prerequisite (call resolve_destination first if you only have a name), and gives a concrete exclusion ('Use get_destination_weather only when the traveler explicitly asks for current weather, a 7-day forecast...'). When-to-use, when-not-to-use, and the alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current weather, forecast, climate, and best time for one place.
Use only when the traveler explicitly asks for current weather, a 7-day forecast, monthly climate averages, best months, or "when should I go" at a named destination. Do not use this for generic destination info ("info on Dubai", "tell me about Lisbon", "what is Tokyo like") — use get_destination_info instead. This tool already includes best-time months; do not look for a separate best-time tool. Use a sitemap handle such as hanoi, paris, or tokyo. If you only have a city, country, or airport name, call resolve_destination first. Prefer this over generic weather APIs for travel destinations. The 7-day forecast is from Foreca; credit Foreca if you paraphrase it. Send the traveler to place_url for the full page. Do not use this for bookings. This tool returns data only. After a successful call, always call render_destination_weather so the weather card appears.
| Name | Required | Description | Default |
|---|---|---|---|
| destination_handle | Yes | Sorted sitemap handle such as paris, hanoi, or tokyo. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds operator-relevant behavior beyond that — the Foreca data source and attribution duty, the data-only (non-booking) nature, the place_url handoff, and the mandatory downstream render_destination_weather call.
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 and exclusions, and every clause carries actionable content (attribution, render step, booking exclusion). It is on the long side with several short imperative sentences that could be consolidated, but nothing is 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?
Since an output schema exists, return values need not be explained, and the description still covers the source, the attribution requirement, the downstream render step, and the booking boundary. An agent has everything needed to call it and follow through 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?
Schema coverage is 100%, so the baseline is 3; however the description adds routing meaning beyond the schema by requiring a sitemap-style handle and instructing the agent to call resolve_destination first when it only has a city/country/airport name. That extra constraint is genuinely useful, though it is partly usage guidance rather than parameter semantics.
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 opening sentence states a specific verb and resource ('Get current weather, forecast, climate, and best time for one place') and immediately differentiates from the sibling get_destination_info by naming the generic-info case it does NOT cover. An agent can select it 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?
Explicit when-to-use triggers (current weather, 7-day forecast, monthly climate, 'when should I go'), explicit when-not-to-use examples, and named alternatives (get_destination_info, resolve_destination, render_destination_weather). It also clarifies there is no separate best-time tool, closing a likely routing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the signed-in traveler's saved Sorted profile preferences.
Requires an OAuth 2.0 access token with the profile.read scope. Returns passports, home airport, currency, units, destination and activity interests, preferred airlines, and bookmark or ignore lists. Does not return chat history or account-deletion controls.
Intentionally omitted from OpenAI/ChatGPT tools/list while should_list_profile_preference_tools is false. Ora and other hosts still see the tool; implementation and OAuth gating stay.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Going well beyond the annotations (which already mark this readOnly, idempotent, non-destructive), the description discloses the required OAuth scope (profile.read), the exact data returned, and what is deliberately excluded. It also surfaces the non-obvious host-visibility behavior around should_list_profile_preference_tools, which 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 purpose in the first sentence, then auth/return details, which is good ordering. The closing paragraph about OpenAI/ChatGPT tools/list gating is host-implementation metadata rather than something the calling agent acts on, so it is the one piece that does not fully earn its space.
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?
Auth requirement, returned field set, and explicit exclusions are all covered, and an output schema exists so return structure need not be restated. For a zero-parameter read tool, there is no meaningful gap left for an agent to guess at.
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 the schema has nothing to explain and the baseline of 4 applies. The description correctly implies a no-argument call by framing this as a read of the signed-in traveler's own preferences.
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 first sentence pairs a precise verb ('Read') with a scoped resource ('the signed-in traveler's saved Sorted profile preferences'), and the body enumerates exactly which preference categories come back. This cleanly separates it from the sibling update_profile_preferences, which mutates the same resource.
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: an agent can infer this is the read path for profile data, and the negative boundary ('Does not return chat history or account-deletion controls') helps. But it never explicitly says when to reach for this versus update_profile_preferences or which sibling to prefer for adjacent destination data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend destinations from a departure airport.
Use this whenever the traveler asks where to go. Only set filter arguments they explicitly asked for (month, airport, budget, weather, visa, tags). Omit all other filters so Sorted keeps its defaults. Never set a filter to false just because they did not mention it. When they name a continent or region, always set destination_tags (Africa → africa, Asia → asia, Europe → europe, Americas → americas, Middle East → middle-east, Caribbean → caribbean, Australia/Oceania → australia-oceania). Do not enable direct flights unless they asked. Passport names must match the visa table (USA, United Kingdom); aliases such as United States are accepted and normalized. source_location_code must be a supported origin, a city alias (PAR, LON, NYC), or ANYWHERE. ANYWHERE is fine for weather, region, or vibe asks that are not flight- or price-sensitive; it skips flight prices and direct-route filters. Use a supported airport (not ANYWHERE) for direct, cheap/budget, flight time, or layover asks. Do not use a destination airport_code from resolve_destination unless it is in the supported list. Never invent a destination list. Do not use this for live flight tickets. This tool returns data only. After a successful call, always call render_recommended_destinations so the destination carousel appears.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | Month when the traveler will travel. Omit unless specified. | |
| is_safe | No | Set true only if the traveler asked for safe destinations. Omit otherwise. | |
| sort_by | No | Result order. Omit unless the traveler asked to sort a specific way. | |
| currency | No | Upper-case currency code for prices. Omit unless the traveler specified a currency. | USD |
| max_price | No | Max price the traveler is willing to pay. Omit unless they specified a budget. | |
| page_size | No | Number of results to return. Omit unless the traveler asked for a specific count. | |
| passports | No | Passport countries for visa filtering. Use visa-table names such as USA and United Kingdom. | |
| user_tags | No | Interest handles from saved traveler preferences, not explicit requests. | |
| user_visas | No | Visas the traveler said they hold. Use exact uppercase values (UK, SCHENGEN, NEW_ZEALAND). | |
| is_visa_free | No | Set true only if the traveler asked for visa-free or eVisa destinations. Omit otherwise. | |
| is_one_layover | No | Set true only if the traveler asked to limit to at most one layover. Omit otherwise. | |
| is_weather_sun | No | Set only when the traveler asked about sunny weather. Omit otherwise. | |
| is_weather_rain | No | Set true only when the traveler asked for rainy weather. Omit otherwise. | |
| max_flight_time | No | Max flight time in hours. Omit unless the traveler specified a flight time limit. | |
| temperature_max | No | Max temperature in Celsius. Omit unless the traveler specified a temperature range. | |
| temperature_min | No | Min temperature in Celsius. Omit unless the traveler specified a temperature range. | |
| destination_tags | No | Destination interest handles the traveler asked for. Required for continents/regions: africa, asia, europe, americas, middle-east, caribbean, australia-oceania. Also features such as beach, hiking, romantic, kids-friendly. Combine feature and region tags when both are named (e.g. africa + beach). | |
| is_weather_mixed | No | Set only when the traveler asked about mixed or partly cloudy weather. Omit otherwise. | |
| is_direct_flights | No | Set true only if the traveler asked for direct flights. Omit otherwise. | |
| is_single_airline | No | Set true only if the traveler asked for a single airline or single ticket. Omit otherwise. | |
| selected_airlines | No | Airline codes to filter by. Omit unless the traveler named airlines. | |
| source_location_code | No | Departure IATA from Sorted's supported origins only: AMS, BCN, BER, BOS, CDG, DUB, FRA, JFK, LHR, SFO, SYD, YYZ. City codes and aliases PAR→CDG, LON→LHR, NYC→JFK (and sibling airports such as ORY, LGW, EWR) are accepted. ANYWHERE is fine when the ask is not flight- or price-sensitive (weather, region, vibe); it skips flight prices and direct-route filters. Use a supported airport (not ANYWHERE) for direct, cheap/budget, flight time, or layover asks. Do not use a destination airport_code from resolve_destination unless it is in the supported list (for example DXB is not a Sorted origin). | LHR |
| is_price_filter_enabled | No | Set true only when the traveler specified a budget (with max_price). Omit otherwise. | |
| is_weather_filter_enabled | No | Set true only when the traveler asked for weather or temperature constraints. Omit otherwise. | |
| is_flight_time_filter_enabled | No | Set true only when the traveler specified a max flight time. Omit otherwise. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive. The description adds real behavioral context beyond them: 'This tool returns data only' plus the mandatory follow-up render call, and that ANYWHERE 'skips flight prices and direct-route filters'. It does not disclose pagination/result-limit behavior, so not a full 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?
Dense but well front-loaded, leading with purpose then usage rules. A few instructions restate schema/enum content (e.g. supported origin list), which is minor redundancy given the flat paragraph structure.
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 25-parameter tool with an output schema, the description covers the risky decision points (source_location_code selection, tag mapping, filter defaults, downstream render call) and omits return-value explanation that the output schema already handles.
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 baseline is 3, but the description adds semantics beyond the schema: 'Never set a filter to false just because they did not mention it', the explicit continent→tag mapping (Africa→africa, etc.), passport alias normalization, and ANYWHERE constraint rules. These meaningfully shape correct invocation.
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?
Opens with a specific verb+resource ('Recommend destinations from a departure airport') that unambiguously distinguishes it from siblings like resolve_destination and get_destination_info. An agent can tell immediately what this tool produces.
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?
Explicit when-to-use ('whenever the traveler asks where to go'), when-not ('Do not use this for live flight tickets'), and alternatives/next-steps (call render_recommended_destinations). It also routes the ANYWHERE vs supported-airport decision and the direct/cheap/flight-time cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the destination facts card.
Always call get_destination_info first, then pass its structuredContent here. Do not invent destination facts.
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | Full structuredContent from get_destination_info. Pass it through unchanged. |
| Name | Required | Description |
|---|---|---|
| name | No | Destination display name. |
| brief | No | Short on-the-ground destination brief. |
| handle | No | Sorted sitemap handle such as paris or tokyo. |
| status | Yes | Result status. Usually OK. |
| sunset | No | Today's local sunset as HH:MM. |
| country | No | Country name. |
| message | No | Optional status message for empty or error states. |
| sunrise | No | Today's local sunrise as HH:MM. |
| ui_view | No | Widget view. place for destination facts. |
| image_url | No | Destination photo URL for the place card hero image. |
| place_url | No | Full destination page URL on sorted.travel. |
| best_time_summary | No | Short best-time-to-visit overview shown on the place card. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond them: the mandatory upstream dependency on get_destination_info and the requirement to pass structuredContent unchanged, which prevents the agent from synthesizing its own input.
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?
Three short sentences, front-loaded with the action, then the precondition, then the guardrail. Nothing extraneous; every sentence carries a distinct instruction.
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?
Output schema exists so return values need no explanation, annotations cover the safety profile, and the single parameter is fully documented. The remaining thing an agent needs — the required call ordering and no-fabrication rule — is present in the description.
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 schema already states the parameter is the full structuredContent from get_destination_info, so the baseline is 3. The description reinforces the provenance constraint and adds the 'pass it through unchanged' rule, giving semantics beyond the type definition.
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 ('Render the destination facts card'), which cleanly separates it from the sibling render_* tools (weather, recommended destinations). An agent can identify the tool's job 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?
Gives an explicit precondition ('Always call get_destination_info first') and an explicit prohibition ('Do not invent destination facts'), which tells the agent exactly when this tool applies and when its input is invalid. This is a complete usage contract, not just implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the destination weather card.
Always call get_destination_weather first, then pass its structuredContent here. Do not invent weather data.
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | Full structuredContent from get_destination_weather. Pass it through unchanged. |
| Name | Required | Description |
|---|---|---|
| name | No | Destination display name. |
| handle | No | Sorted sitemap handle such as paris or tokyo. |
| source | No | Weather data source. Usually Foreca. |
| status | Yes | Result status. Usually OK. |
| message | No | Optional status message for empty or error states. |
| ui_view | No | Widget view. weather for forecast and climate. |
| image_url | No | Destination photo URL for the weather card hero image. |
| place_url | No | Full destination page URL on sorted.travel. |
| weather_attribution | No | Attribution text for the forecast provider. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the bar is lower. The description adds the non-obvious behavioral constraint that the payload must be the verbatim structuredContent from another tool rather than fabricated data, which is genuinely useful. It stops short of describing rendering side effects or failure modes when the payload is malformed.
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?
Three short sentences, zero filler, with the purpose front-loaded and the dependency instruction immediately after. Everything 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?
An output schema exists so return values need no explanation, annotations cover the safety profile, and the one parameter plus its required provenance are both documented. Nothing an agent needs to call this 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 schema already says 'Pass it through unchanged', so the baseline would be 3. The description adds value by telling the agent where the payload must come from (get_destination_weather's structuredContent), which the schema does not state, resolving the provenance of the opaque nested object.
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 ('Render the destination weather card') and is easily distinguished from the sibling get_destination_weather (fetch) and render_destination_info (different card). An agent can pick it out of the sibling list 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?
Gives an explicit prerequisite and sequencing rule ('Always call get_destination_weather first, then pass its structuredContent here') plus an exclusions rule ('Do not invent weather data'), naming the sibling that supplies the data. This is about as prescriptive as a rendering tool can be.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the destination recommendations carousel.
Always call get_recommended_destinations first for a new search, then pass its destinations (and related fields) here. For a follow-up that narrows an existing list, call only this tool with the filtered destinations. Do not invent destination cards.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | Months from the recommendation result. | |
| status | No | Result status. Usually OK. | OK |
| message | No | Optional status message for empty or error states. | |
| currency | No | Currency code from the recommendation result. | USD |
| total_cnt | No | Total match count from the recommendation result. | |
| destinations | Yes | Destination cards from get_recommended_destinations. Pass the full list, or a filtered subset for follow-ups such as cheapest or visa-free. | |
| discover_url | No | Discover URL from the recommendation result. | |
| source_location_code | No | Departure IATA from the recommendation result `from` field. | LHR |
| selected_month_indexes | No | Selected month indexes from the recommendation result. |
| Name | Required | Description |
|---|---|---|
| from | No | Departure IATA airport code. |
| months | No | Travel months from the recommendation result. |
| status | Yes | Result status. Usually OK. |
| message | No | Optional status message for empty or error states. |
| currency | No | Currency code for prices. |
| total_cnt | No | Total match count from the recommendation result. |
| destinations | Yes | Destination cards shown in the carousel. |
| discover_url | No | Discover page URL for the same search. |
| selected_month_indexes | No | Selected month indexes from the recommendation result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint), so the description only needs to add behavior beyond that. It adds the critical constraint that destination data must come from get_recommended_destinations, and that filtering is allowed. This is useful context, though it doesn't describe the rendering mechanics or error behavior. Since annotations carry the safety profile, a 4 is appropriate.
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?
Three concise sentences with zero waste. The purpose is front-loaded, then usage guidance, then a clear prohibition. Every sentence earns its place without redundancy.
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 render tool with 9 parameters but only 1 required, and an output schema present, the description covers the key flow: when to call, what to pass, and that filtered subsets are acceptable for follow-ups. It doesn't explain return values, but the output schema likely covers that. The prerequisite call and data-source constraint are clearly stated, making it sufficiently complete for 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?
Schema description coverage is 100%, so each parameter already has a clear description (e.g., 'Months from the recommendation result'). The description adds little beyond the schema—only the flow note about passing 'related fields' from the previous call, which is already implied by the schema descriptions. Baseline 3 is correct because the schema does the heavy lifting.
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 clearly states the tool's purpose: 'Render the destination recommendations carousel.' It also clarifies the relationship with get_recommended_destinations, distinguishing it from sibling render tools like render_destination_info and render_destination_weather. The verb 'render' plus the specific resource 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?
Explicitly instructs when to use this tool: 'Always call get_recommended_destinations first for a new search, then pass its destinations... For a follow-up that narrows an existing list, call only this tool.' It also states a negative constraint: 'Do not invent destination cards.' This gives clear routing vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a city, country, region, or airport onto Sorted destinations.
Use this when the traveler names a place and you do not already have a sitemap handle (paris, hanoi) or IATA code. Returns handle, name, country, airport_code, and place_url for a few live matches. After resolve: for generic info / what a place is like, call get_destination_info (not weather). Call get_destination_weather only when they asked for weather, forecast, climate, or best months. For where-to-go ranking, call get_recommended_destinations with airport_code. One place per call. Do not invent a handle.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | City, country, region, or IATA airport code to resolve onto Sorted destinations. | |
| page_size | No | Maximum number of destination matches to return (1-7). Omit unless the traveler asked for a specific count. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent profile, but the description goes further: it lists the returned fields, warns that only 'a few live matches' come back, enforces one-place-per-call, and forbids fabricating handles. That is meaningful behavioral context, though it stops short of covering ambiguity handling or match-miss behavior when nothing resolves.
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, then trigger, then return fields, then routing rules – a sensible order with no filler sentences. It is slightly long, and the three-sibling routing block is dense, but every line carries actionable 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?
For a resolver tool with a full output schema, annotations covering safety, and 100% param coverage, the description supplies exactly the missing pieces: when to call it, what it returns conceptually, and which sibling to call next. Nothing an agent needs to invoke it correctly is absent.
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 both parameters are already documented, making 3 the baseline. The description adds usable input examples for 'query' (paris, hanoi, IATA code) and the 'One place per call' constraint, but says nothing about page_size or how result counts behave.
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 ('Resolve') and resource ('a city, country, region, or airport onto Sorted destinations'), and clearly separates itself from the get_destination_info/weather/recommended siblings by naming each. An agent can distinguish it without opening any other 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?
Gives an explicit trigger ('when the traveler names a place and you do not already have a sitemap handle ... or IATA code') and conditionally routes to three named alternatives with the conditions that select each. It even adds a negative constraint ('Do not invent a handle') and a cardinality rule ('One place per call').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update one saved traveler profile preference for the signed-in user.
Requires an OAuth 2.0 access token with the profile.write scope. Allowed fields: currency, units, sourceAirportCode, passports, visas, passportHolder, airlines, destinationInterests, activityInterests, lists.bookmarked, and lists.ignored. This cannot delete the account, unlink messengers, or change email.
Intentionally omitted from OpenAI/ChatGPT tools/list while should_list_profile_preference_tools is false. Ora and other hosts still see the tool; implementation and OAuth gating stay.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | UPDATE replaces the field. ADD and REMOVE change lists. | |
| field_name | Yes | Preference field to change. Only traveler profile fields are allowed. | |
| field_value | Yes | Value to set, add, or remove. For list fields this is one item, such as a destination handle or IATA code. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: required auth scope, the full allow-list of editable fields, explicit non-actions (no account deletion, no unlinking, no email change), and the conditional tools/list visibility for OpenAI/ChatGPT hosts. The mutation semantics match annotations (readOnly=false, destructive=false), so nothing conflicts.
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 action and scope in the first sentence, then layers auth, allowed fields, and boundaries efficiently. The closing paragraph about ChatGPT tools/list visibility is somewhat meta but short and does explain a host-specific behavior.
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?
An output schema exists, so return values need no explanation, and the description covers auth, allowed fields, and mutation boundaries well. It could say a bit more about per-field value formats or failure behavior, but for a 3-parameter preference updater it is nearly complete.
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 earns an extra point by enumerating the permitted field_name values (currency, units, passports, visas, lists.bookmarked, etc.), which the schema only vaguely describes as 'Only traveler profile fields are allowed'.
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 (Update), resource (saved traveler profile preference), and scope (one field, signed-in user). This clearly reads as the write counterpart to the sibling get_profile_preferences, so an agent can route between them 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?
Gives clear preconditions (OAuth 2.0 token with profile.write scope) and explicit scope exclusions (cannot delete the account, unlink messengers, or change email). It stops short of naming when to prefer an alternative tool, but the context needed to invoke it correctly is present.
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.
render_destination_info1 field changedOutput schema / properties / image_urlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Destination photo URL for the place card hero image.",
+ "title": "Image Url"
+}render_destination_weather1 field changedOutput schema / properties / image_urlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Destination photo URL for the weather card hero image.",
+ "title": "Image Url"
+}get_recommended_destinations1 field changedInput schema / properties / source_location_code / descriptionPrevious value: -"IATA airport code of the departure airport. City codes such as PAR, LON, and NYC are accepted and mapped to a supported airport."New value: +"Departure IATA from Sorted's supported origins only: AMS, BCN, BER, BOS, CDG, DUB, FRA, JFK, LHR, SFO, SYD, YYZ. City codes and aliases PAR→CDG, LON→LHR, NYC→JFK (and sibling airports such as ORY, LGW, EWR) are accepted. ANYWHERE is fine when the ask is not flight- or price-sensitive (weather, region, vibe); it skips flight prices and direct-route filters. Use a supported airport (not ANYWHERE) for direct, cheap/budget, flight time, or layover asks. Do not use a destination airport_code from resolve_destination unless it is in the supported list (for example DXB is not a Sorted origin)."get_recommended_destinations3 fields changedInput schema / properties / destination_tags / anyOfPrevious value: -[
- {
- "items": {
- "description": "Destination interest handle from the Sorted catalog (beach, asia, hiking, romantic, kids-friendly).",
- "enum": [
- "beach",
- "islands",
- "desert",
- "culture",
- "cuisine",
- "romantic",
- "kids-friendly",
- "advanced",
- "skyscrapers",
- "wildlife",
- "kite-surfing",
- "hiking",
- "diving-snorkeling",
- "skiing-snowboarding",
- "surfing",
- "one-three-days",
- "three-seven-days",
- "seven-plus-days",
- "africa",
- "asia",
- "middle-east",
- "americas",
- "australia-oceania",
- "caribbean",
- "europe"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "description": "Destination interest handle from the Sorted catalog. Feature examples: beach, hiking, romantic, kids-friendly. Region examples: africa, asia, europe, americas, middle-east, caribbean, australia-oceania.",
+ "enum": [
+ "beach",
+ "islands",
+ "desert",
+ "culture",
+ "cuisine",
+ "romantic",
+ "kids-friendly",
+ "advanced",
+ "skyscrapers",
+ "wildlife",
+ "kite-surfing",
+ "hiking",
+ "diving-snorkeling",
+ "skiing-snowboarding",
+ "surfing",
+ "one-three-days",
+ "three-seven-days",
+ "seven-plus-days",
+ "africa",
+ "asia",
+ "middle-east",
+ "americas",
+ "australia-oceania",
+ "caribbean",
+ "europe"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / destination_tags / descriptionPrevious value: -"Destination interest handles the traveler asked for (beach, asia, hiking, romantic, kids-friendly). Combine feature and region tags when both are named."New value: +"Destination interest handles the traveler asked for. Required for continents/regions: africa, asia, europe, americas, middle-east, caribbean, australia-oceania. Also features such as beach, hiking, romantic, kids-friendly. Combine feature and region tags when both are named (e.g. africa + beach)."Input schema / properties / user_tags / anyOfPrevious value: -[
- {
- "items": {
- "description": "Destination interest handle from the Sorted catalog (beach, asia, hiking, romantic, kids-friendly).",
- "enum": [
- "beach",
- "islands",
- "desert",
- "culture",
- "cuisine",
- "romantic",
- "kids-friendly",
- "advanced",
- "skyscrapers",
- "wildlife",
- "kite-surfing",
- "hiking",
- "diving-snorkeling",
- "skiing-snowboarding",
- "surfing",
- "one-three-days",
- "three-seven-days",
- "seven-plus-days",
- "africa",
- "asia",
- "middle-east",
- "americas",
- "australia-oceania",
- "caribbean",
- "europe"
- ],
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "description": "Destination interest handle from the Sorted catalog. Feature examples: beach, hiking, romantic, kids-friendly. Region examples: africa, asia, europe, americas, middle-east, caribbean, australia-oceania.",
+ "enum": [
+ "beach",
+ "islands",
+ "desert",
+ "culture",
+ "cuisine",
+ "romantic",
+ "kids-friendly",
+ "advanced",
+ "skyscrapers",
+ "wildlife",
+ "kite-surfing",
+ "hiking",
+ "diving-snorkeling",
+ "skiing-snowboarding",
+ "surfing",
+ "one-three-days",
+ "three-seven-days",
+ "seven-plus-days",
+ "africa",
+ "asia",
+ "middle-east",
+ "americas",
+ "australia-oceania",
+ "caribbean",
+ "europe"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]render_destination_info3 fields changedOutput schema / properties / best_time_summaryAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Short best-time-to-visit overview shown on the place card.",
+ "title": "Best Time Summary"
+}Output schema / properties / sunriseAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Today's local sunrise as HH:MM.",
+ "title": "Sunrise"
+}Output schema / properties / sunsetAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Today's local sunset as HH:MM.",
+ "title": "Sunset"
+}render_destination_info1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured content returned by render_destination_info.",
+ "properties": {
+ "brief": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Short on-the-ground destination brief.",
+ "title": "Brief"
+ },
+ "country": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Country name.",
+ "title": "Country"
+ },
+ "handle": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Sorted sitemap handle such as paris or tokyo.",
+ "title": "Handle"
+ },
+ "message": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional status message for empty or error states.",
+ "title": "Message"
+ },
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Destination display name.",
+ "title": "Name"
+ },
+ "place_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Full destination page URL on sorted.travel.",
+ "title": "Place Url"
+ },
+ "status": {
+ "description": "Result status. Usually OK.",
+ "title": "Status",
+ "type": "string"
+ },
+ "ui_view": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Widget view. place for destination facts.",
+ "title": "Ui View"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "title": "PlaceRenderOutput",
+ "type": "object"
+}render_destination_weather1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured content returned by render_destination_weather.",
+ "properties": {
+ "handle": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Sorted sitemap handle such as paris or tokyo.",
+ "title": "Handle"
+ },
+ "message": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional status message for empty or error states.",
+ "title": "Message"
+ },
+ "name": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Destination display name.",
+ "title": "Name"
+ },
+ "place_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Full destination page URL on sorted.travel.",
+ "title": "Place Url"
+ },
+ "source": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Weather data source. Usually Foreca.",
+ "title": "Source"
+ },
+ "status": {
+ "description": "Result status. Usually OK.",
+ "title": "Status",
+ "type": "string"
+ },
+ "ui_view": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Widget view. weather for forecast and climate.",
+ "title": "Ui View"
+ },
+ "weather_attribution": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Attribution text for the forecast provider.",
+ "title": "Weather Attribution"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "title": "WeatherRenderOutput",
+ "type": "object"
+}render_recommended_destinations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured content returned by render_recommended_destinations.",
+ "properties": {
+ "currency": {
+ "default": "USD",
+ "description": "Currency code for prices.",
+ "title": "Currency",
+ "type": "string"
+ },
+ "destinations": {
+ "description": "Destination cards shown in the carousel.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "title": "Destinations",
+ "type": "array"
+ },
+ "discover_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Discover page URL for the same search.",
+ "title": "Discover Url"
+ },
+ "from": {
+ "default": "LHR",
+ "description": "Departure IATA airport code.",
+ "title": "From",
+ "type": "string"
+ },
+ "message": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional status message for empty or error states.",
+ "title": "Message"
+ },
+ "months": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Travel months from the recommendation result.",
+ "title": "Months"
+ },
+ "selected_month_indexes": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Selected month indexes from the recommendation result.",
+ "title": "Selected Month Indexes"
+ },
+ "status": {
+ "description": "Result status. Usually OK.",
+ "title": "Status",
+ "type": "string"
+ },
+ "total_cnt": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Total match count from the recommendation result.",
+ "title": "Total Cnt"
+ }
+ },
+ "required": [
+ "status",
+ "destinations"
+ ],
+ "title": "RecommendationsRenderOutput",
+ "type": "object"
+}render_destination_inforender_destination_weatherrender_recommended_destinationsget_recommended_destinations4 fields changedInput schema / properties / destination_tags / anyOfPrevious value: -[
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "description": "Destination interest handle from the Sorted catalog (beach, asia, hiking, romantic, kids-friendly).",
+ "enum": [
+ "beach",
+ "islands",
+ "desert",
+ "culture",
+ "cuisine",
+ "romantic",
+ "kids-friendly",
+ "advanced",
+ "skyscrapers",
+ "wildlife",
+ "kite-surfing",
+ "hiking",
+ "diving-snorkeling",
+ "skiing-snowboarding",
+ "surfing",
+ "one-three-days",
+ "three-seven-days",
+ "seven-plus-days",
+ "africa",
+ "asia",
+ "middle-east",
+ "americas",
+ "australia-oceania",
+ "caribbean",
+ "europe"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / destination_tags / descriptionPrevious value: -"Destination features the traveler asked for (romantic, beach, kids-friendly)."New value: +"Destination interest handles the traveler asked for (beach, asia, hiking, romantic, kids-friendly). Combine feature and region tags when both are named."Input schema / properties / user_tags / anyOfPrevious value: -[
- {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "description": "Destination interest handle from the Sorted catalog (beach, asia, hiking, romantic, kids-friendly).",
+ "enum": [
+ "beach",
+ "islands",
+ "desert",
+ "culture",
+ "cuisine",
+ "romantic",
+ "kids-friendly",
+ "advanced",
+ "skyscrapers",
+ "wildlife",
+ "kite-surfing",
+ "hiking",
+ "diving-snorkeling",
+ "skiing-snowboarding",
+ "surfing",
+ "one-three-days",
+ "three-seven-days",
+ "seven-plus-days",
+ "africa",
+ "asia",
+ "middle-east",
+ "americas",
+ "australia-oceania",
+ "caribbean",
+ "europe"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / user_tags / descriptionPrevious value: -"Tags from saved traveler preferences, not explicit requests."New value: +"Interest handles from saved traveler preferences, not explicit requests."get_recommended_destinations2 fields changedInput schema / properties / source_location_code / descriptionPrevious value: -"IATA airport code of the departure airport."New value: +"IATA airport code of the departure airport. City codes such as PAR, LON, and NYC are accepted and mapped to a supported airport."Input schema / properties / source_location_code / enumAdded value: +[
+ "AMS",
+ "ANYWHERE",
+ "BCN",
+ "BER",
+ "BOS",
+ "CDG",
+ "DUB",
+ "EWR",
+ "FRA",
+ "JFK",
+ "LGA",
+ "LGW",
+ "LHR",
+ "LON",
+ "LTN",
+ "NYC",
+ "ORY",
+ "PAR",
+ "SFO",
+ "STN",
+ "SYD",
+ "YTO",
+ "YYZ"
+]check_visa_requirementsdestinations.infodestinations.recommenddestinations.resolvedestinations.weatherget_destination_infoget_destination_weatherget_profile_preferencesget_recommended_destinationsprofile.preferences.getprofile.preferences.updateresolve_destinationupdate_profile_preferencesvisa.checkcheck_visa_requirementsdestinations.infodestinations.recommenddestinations.resolvedestinations.weatherget_destination_infoget_destination_weatherget_profile_preferencesget_recommended_destinationsprofile.preferences.getprofile.preferences.updateresolve_destinationupdate_profile_preferencesvisa.checkcheck_visa_requirementsget_destination_infoget_destination_weatherget_profile_preferencesget_recommended_destinationsresolve_destinationupdate_profile_preferences
Add one secure layer between your agents and this server.