Plan trips, search hotels and flights, get exact quotes and check out on Anywayr.
Scored across 18 tools
Each tool targets a distinct lifecycle step or resource: destination resolution, search, rate/offer reading, quote, checkout preparation, booking reading, cancellation quote/confirmation, trip planning/editing, and async operation status. The hotel tools form a readable chain rather than overlapping duplicates: search_hotels finds hotels, get_hotel_rates lists offers for one hotel from that search, and get_offer reads a stored offer snapshot. Descriptions make the boundaries explicit.
Almost all tools follow a consistent anywayr_ + snake_case verb_noun pattern, such as get_booking, list_trips, search_hotels, quote_booking, and confirm_cancellation. The main minor deviation is anywayr_capabilities, which is noun-only rather than verb_noun, but the overall naming is predictable and readable.
The 18 tools are broad but each covers a real part of the travel search, planning, booking, and cancellation lifecycle. It is slightly heavy for a typical MCP surface, but not excessive for a domain that legitimately spans flights, hotels, trips, bookings, deals, and cancellations.
The set covers the core lifecycle from destination resolution and search through planning, quoting, checkout preparation, booking lookup, and cancellation quoting/confirmation. Completeness gaps are minor: there is no direct booking-completion tool (checkout is handed to the Anywayr website), and trip editing is limited to dates and travelers, with sharing and broader preference edits not exposed.
Lists what Anywayr supports right now: products, party and room limits, cabins, booking modes and which tools are available to this connection. Call this first. Effects: None.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 full safety profile is covered. "Effects: None." merely restates those structured hints and earns no credit, though the note that availability is scoped to "this connection" adds a small useful nuance.
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 compact sentences: contents first, the imperative "Call this first" second, no filler. Every clause carries information and the critical routing instruction is not buried.
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 takes on the job of describing the payload and does enumerate what comes back, which is the key thing an agent needs. It stops short of describing the response shape (list vs. nested object) or field naming, so a small gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies and there is nothing for the description to compensate for. The schema coverage figure is nominal given an empty properties 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?
Specific verb ("Lists") plus a precisely scoped resource, with the returned contents enumerated (products, party and room limits, cabins, booking modes, available tools). No sibling tool does discovery, so it is instantly distinguishable from the 17 lookup/quote/booking tools.
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?
"Call this first." is an explicit, unambiguous ordering directive that tells the agent when to use it relative to every sibling. There are no when-not conditions or named alternatives, but for a unique zero-arg discovery tool that omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels a booking the traveller has asked to cancel, only when anywayr_quote_cancellation said confirm_in_chat. Pass that cancellation_ref and the exact refund it showed. Refuses if the refund changed or is no longer the full amount; then quote again or use the review link. Cannot be undone. Effects: Cancels the reservation with the supplier and refunds the traveller in full. Real money, cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| refund | Yes | ||
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. | |
| cancellation_ref | Yes | Anywayr cancellation reference (starts with cxl_), as returned by anywayr_quote_cancellation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint=true annotation, the description discloses the refusal condition (refund changed or no longer full amount), the downstream effect (cancels with the supplier, refunds traveller in full), and the irreversibility with real money. It also explains the retry semantics that back idempotentHint.
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 precondition, then the payload, then failure handling, then effects — good ordering. Loses a point for redundancy: "Cannot be undone" and "Real money, cannot be undone" restate the same warning across two adjacent 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?
For a destructive, open-world mutation with a nested payload and no output schema, the description covers precondition, refusal behavior, retry path, and side effects. It does not say what a successful call returns, which is a minor gap given there is no output 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 67% and both string params already carry descriptions, but the description adds real meaning the schema does not: cancellation_ref must come from anywayr_quote_cancellation and refund must be the exact amount it showed. The nested refund object itself is only constrained structurally, not semantically, in either place.
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 ("Cancels a booking") plus the exact scope that qualifies it (the traveller asked to cancel). It explicitly names the sibling it depends on, anywayr_quote_cancellation, so the agent can distinguish this confirm step from the quote step without reading 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 an explicit precondition (only when anywayr_quote_cancellation said confirm_in_chat), tells the agent what values to pass and their provenance, and names concrete alternatives on failure ("then quote again or use the review link"). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the canonical reservation and payment state of one booking. Only the booking owner sees private details such as a confirmation code. If payment_state is needs_review, the payment outcome is unresolved: read this booking or contact Anywayr support, never start a new booking or claim no charge was made. Reservation confirmation and refund settlement are separate. Effects: None.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_ref | Yes | Anywayr booking reference (starts with bkg_), as returned by anywayr_list_bookings or a completed booking. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond that: owner-only visibility of private details like confirmation codes, the semantics of an unresolved payment_state, and the fact that refund settlement is separate from reservation confirmation.
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 read purpose is front-loaded in the first sentence, and the payment_state warning is placed before the more peripheral notes. 'Effects: None.' is largely redundant with readOnlyHint/destructiveHint but is a conventional, low-cost disclosure.
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 appropriately characterizes what is returned ('canonical reservation and payment state') and covers access control and side effects. It leaves the exact returned fields unspecified, but for a single-object read whose annotations already convey safety, an agent has enough to call 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?
There is only one parameter and schema description coverage is 100%, with the schema itself documenting the bkg_ prefix and where the reference comes from. The description adds no parameter-level detail, so the baseline of 3 applies when 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 gives a specific verb ('Reads') and resource ('the canonical reservation and payment state of one booking'), which clearly scopes it as a single-booking lookup rather than a listing. It is clear enough to separate from anywayr_list_bookings, but it never names or contrasts with any sibling explicitly, so it lands just short of the top tier.
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 real conditional guidance: when payment_state is needs_review the agent should read the booking or contact support, and explicitly must NOT start a new booking or claim no charge was made. That is strong when/when-not guidance, though it stops short of routing the agent among named sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists room offers for one hotel from an existing search, using exactly that search’s dates and guests. Does not hold a room. Effects: Stores offer snapshots and spends provider rate budget. Holds nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_ref | Yes | Anywayr hotel reference (starts with htl_), as returned by anywayr_search_hotels. | |
| search_ref | Yes | Anywayr search reference (starts with srch_), as returned by anywayr_search_hotels, anywayr_search_flights or anywayr_discover_flight_deals. | |
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description goes further by disclosing two non-obvious effects: it stores offer snapshots and spends provider rate budget. The 'Does not hold a room' clause clarifies that no reservation is created. This is real value beyond the safety hints, though return/pagination behavior is not covered.
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 effects, in a compact four-sentence block. Slightly repetitive at the end, where 'Does not hold a room' and 'Holds nothing' convey the same point, costing a little economy.
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 3-parameter tool with full schema coverage, rich annotations, and no output schema, the description covers purpose, precondition, and side effects adequately. Only the lack of any explicit routing to sibling tools leaves a minor gap.
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 schema already documents all three parameters, making 3 the baseline. The description does add one useful nuance (search_ref supplies the dates and guests), but it says nothing about request_key's retry semantics beyond what the schema already states.
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 ('Lists room offers for one hotel') and scopes it to an existing search with that search's dates and guests. This clearly separates it from anywayr_search_hotels (finding hotels) though it never names a sibling explicitly.
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?
The prerequisite is stated ('from an existing search'), implying it should be called after a search, but there is no explicit when-to-use/when-not guidance or named alternative such as anywayr_get_offer. Usage is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the stored snapshot of one offer with its freshness. Does not re-price, prebook or reserve. Effects: None.
| Name | Required | Description | Default |
|---|---|---|---|
| offer_ref | Yes | Anywayr offer reference (starts with ofr_), as returned by anywayr_get_hotel_rates, anywayr_search_flights or anywayr_get_offer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world. The description adds genuine value beyond them: it is a stored snapshot (not a live re-price) and it surfaces freshness/staleness, which matters for deciding whether to trust the data. 'Effects: None' corroborates rather than contradicts 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?
Two sentences, zero filler, and the core behavior (snapshot read + freshness) is front-loaded ahead of the exclusions. 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?
For a single-parameter read-only getter with no output schema, the description covers what it returns conceptually (snapshot + freshness) and rules out side effects. It could say slightly more about staleness semantics or the returned object shape, but nothing essential to calling 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 description coverage is 100% and the single offer_ref parameter is fully documented in the schema, including its ofr_ prefix and the tools that produce it. The description adds no parameter-level meaning beyond that, 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?
States a specific verb+resource ('Reads the stored snapshot of one offer') plus its scope ('with its freshness'), which is more precise than the title. It differentiates from pricing/booking siblings by negation rather than by naming them, so it falls just short of a 5.
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?
'Does not re-price, prebook or reserve' tells the agent what this tool will NOT do, implicitly steering away from it when a fresh quote or reservation is needed. However, no sibling is named and no positive when-to-use condition (e.g. re-reading a previously returned ofr_ reference) is stated, 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.
Reads the status of an earlier command that came back processing or reconciling (a checkout or a booking still being confirmed). A planning operation completes when its trip is saved, and its result contains the trip link; itinerary progress is read separately with anywayr_get_trip. It never restarts that work. Effects: None.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Anywayr cursor reference (starts with cur_), as returned by the next_cursor of a previous page. | |
| operation_ref | Yes | Anywayr operation reference (starts with op_), as returned by a tool result that is still processing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive, so the safety profile is known. The description adds real context beyond that: it never restarts the underlying work, it declares 'Effects: None', and it explains that a planning operation completes when its trip is saved and that the result carries the trip link.
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 tight sentences, front-loaded with the purpose and the processing/reconciling trigger. The completion semantics for planning operations earn their place, though the parenthetical and the trip-link clause make it slightly denser than strictly necessary.
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 usefully discloses what a planning result contains (the trip link) and confirms the call has no side effects. Pagination via cursor is left entirely to the schema, a minor gap but not blocking for a status-check 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 description coverage is 100%, so both operation_ref and cursor are already documented with their prefixes and provenance, which sets the baseline at 3. The description implies operation_ref semantics ('status of an earlier command') but adds no new syntax or format detail, and never touches the cursor/paging parameter.
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: it reads the status of an earlier command that returned processing or reconciling, with concrete examples (a checkout or booking still being confirmed). It also explicitly separates itself from anywayr_get_trip for itinerary progress, so an agent can distinguish the two 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?
The 'when' is clearly stated: use it for a command that came back processing or reconciling. It routes itinerary reads to anywayr_get_trip and clarifies that this tool never restarts the work. It stops short of an explicit when-not boundary (e.g., what to do once the operation completes), but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a saved trip at your permitted sharing level, including its browser trip_url and evidence-based planning_progress. Use returned links verbatim; opaque trp references are tool inputs, never browser paths. A scheduled retry remains planning. Stop bounded polling on ready, failed or unknown and give the saved link. Effects: None.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_ref | Yes | Anywayr trip reference (starts with trp_), as returned by anywayr_plan_trip, anywayr_list_trips or anywayr_get_trip. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, but the description adds real context: results are scoped to 'your permitted sharing level', the ref is opaque and not a browser path, and the trip can still be in a scheduled-retry state. 'Effects: None' largely restates readOnlyHint, but the polling and sharing-scope semantics are net-new.
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?
Four tight sentences, purpose first, then link-handling, polling, and effects. Dense but no filler; some phrasing ('evidence-based planning_progress') is jargon-heavy enough to cost a little clarity.
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 the return-value burden, and it names the key fields (trip_url, planning_progress) and terminal states (ready, failed, unknown). A brief note on what the payload looks like beyond those two fields would make it 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 the extra point by clarifying that the opaque trp_ reference is a tool input distinct from the browser-facing trip_url returned in the payload – a distinction the schema does not make.
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 ('Reads a saved trip') plus the payload it returns (trip_url, planning_progress), which separates it from write tools like update_trip and plan_trip. It never names the nearest sibling (anywayr_list_trips) explicitly, so the differentiation is implicit rather than spelled out.
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 concrete operational conditions: poll bounded, stop on ready/failed/unknown, a scheduled retry still counts as planning, and hand back the saved link. It nonetheless never states the entry condition for choosing this tool over anywayr_list_trips or anywayr_get_operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists summaries of your bookings, newest first. If payment_state is needs_review, the payment outcome is unresolved: read that booking or contact Anywayr support, never start a new booking or claim no charge was made. A cancelled reservation does not mean a refund has settled. Effects: None.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-10). Defaults to 10. | |
| cursor | No | Anywayr cursor reference (starts with cur_), as returned by the next_cursor of a previous page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive behavior, yet the description goes further with safety-critical semantics: needs_review means an unresolved payment outcome, the agent must not start a new booking or assert no charge was made, and a cancellation does not imply a refund. This is substantive context an agent cannot get from the 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?
Purpose is front-loaded, followed by the payment caveats and a brief effects note. It is appropriately compact with no filler, though the caveats could be grouped slightly more tightly.
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 small filtered-list tool with no output schema, the description covers purpose, ordering, pagination-adjacent behavior and the critical payment-state caveat. The main omission is any hint of the summary fields returned, which is minor given the low complexity.
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 limit and cursor are already documented in the schema. The description adds no pagination or parameter detail beyond that, making the baseline 3 appropriate.
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 ('Lists summaries of your bookings') and adds the ordering ('newest first'), which helps an agent understand the return. It implicitly routes to the single-booking sibling with 'read that booking', but does not explicitly contrast with anywayr_get_booking or anywayr_list_trips.
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?
Offers interpretive rules for the needs_review payment state and warns that a cancelled reservation is not a settled refund, which is useful. However, it gives no explicit when-to-use guidance relative to siblings such as get_booking (full detail) or list_trips, so the usage framing is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the deal board Anywayr publishes for one home city and its Instagram account (instagram_handle), plus published flight + hotel packages. It reads stored deals only and never searches. To post from a board: post nothing from flights or hotels unless that section's state is "fresh"; post nothing before post_not_before; post only items with post_today true, in rank order; never post the same post_key twice; never post an item after its valid_until; post a format "story_only" item only as a story. Use image_url for a feed post and story_image_url for a story, and a flight's deal_url or a hotel's share_url as the post's link; link_in_bio_url is the account's bio link. Never build or change a link or an image URL. Quote only the returned price with its price basis, dates, airline, savings_pct and why lines as given, and add price_note. Say "great deal" or "deal" only when label is great_deal or deal; a pick claims no saving, and a quote is never posted. A flight price is the whole fare for one adult, economy, round trip. Hotels are picks against similar hotels in the same screen. Hotel stay_total is the whole stay for 2 adults, 1 room including hotel fees, never per person. peer_median_total describes other hotels, never this hotel’s usual price. Quote hotel why lines exactly, use its share_url and image URLs as given, and never claim cheaper than other sites. A package price is the whole-party total for its party_basis (rooms and child ages), cabin and hotel nights; share a package's share_url as given. Do not repeat any price after its valid_until. flights.state "updating" means the board is not confirmed fresh, not that there are no deals; packages.state "unavailable" likewise says nothing about which packages exist. Never call discovery, anywayr_search_hotels, package publishing or watch tools to find something to post. Booking happens on Anywayr. Effects: None. Reads published deals; starts no supplier search.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Anywayr deal city: "austin" (Austin), "los-angeles" (Los Angeles), "new-york" (New York). | |
| limit | No | Maximum number of items to return (1-10). Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false; the description adds genuinely non-obvious context: 'Effects: None. Reads published deals; starts no supplier search,' plus the important staleness semantics that flights.state 'updating' does not mean no deals and packages.state 'unavailable' says nothing about which packages exist. The remainder is downstream posting policy rather than tool behavior, which is useful but sits outside this tool's own execution profile.
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 first two sentences are tight and front-loaded, but the bulk of the description is a long run-on chain of posting rules ('post nothing before post_not_before; post only items with post_today true, in rank order...') that govern what a consumer does with the results rather than how to invoke this read tool. It is dense, repetitive in structure, and buries the invocation-relevant facts.
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 substantial work explaining return semantics — price basis for flights, stay_total and peer_median_total for hotels, party_basis for packages, which URL field to use where, and the meaning of state values. It stops short of describing the overall response shape (the flights/hotels/packages sections and item fields), but an agent has enough to call it and interpret the main values.
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 both parameters (city enum, limit 1-10) are fully documented in the schema, so the baseline of 3 applies. The description adds no constraint on limit and introduces mild ambiguity by referencing instagram_handle as if it were an input, when the only inputs are city and limit — an agent could briefly wonder whether a handle must be supplied.
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 — reads the published deal board for one home city plus its flight/hotel/package sections — and immediately bounds the scope with 'reads stored deals only and never searches.' It also distinguishes itself from the search/discovery siblings by name, so an agent can tell it apart from anywayr_search_hotels or anywayr_search_flights 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 about when to use it (retrieving stored, published deals for a city) and when not to, naming the alternatives to avoid: 'Never call discovery, anywayr_search_hotels, package publishing or watch tools to find something to post.' It also clarifies that booking happens elsewhere on Anywayr, closing the loop on what this tool is not for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists summaries of trips you can access, newest first. Effects: None.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-10). Defaults to 10. | |
| cursor | No | Anywayr cursor reference (starts with cur_), as returned by the next_cursor of a previous page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so "Effects: None" is largely redundant. The genuinely additive parts are that results are summaries rather than full records and are ordered newest first; pagination behaviour via cursor is left to the schema.
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 sentences with no waste; the scope and ordering constraint are front-loaded ahead of the effects note. Nothing needs trimming.
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 simple, zero-required-parameter list tool with no output schema, the description conveys what comes back (summaries, newest first) but says nothing about the returned summary fields or how paging interacts with the cursor. Adequate but with clear gaps.
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 limit and cursor both fully documented in the schema (including default and cursor prefix format). The description adds no parameter meaning beyond that, 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?
States a specific verb and resource ("Lists ... trips") plus the access scope ("trips you can access") and ordering ("newest first"). It is clear what the tool returns, though it never contrasts itself with siblings like anywayr_get_trip or anywayr_list_bookings, so differentiation is left to inference.
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?
The description gives no when-to-use guidance, no exclusions, and no pointer to an alternative such as anywayr_get_trip for full trip detail. "Trips you can access" hints at scope but is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saves a private trip and returns its real trip_url immediately; completed means saved, not itinerary ready. Before calling, confirm a city or named stay destination (not a country) and its exact local arrival/check-out dates; ask one combined question if those are missing or an overseas departure day is ambiguous. Do not save a placeholder draft first. Use one destination_ref or confirmed segments for 2–5 contiguous cities. Dates and travelers are required; budget is optional. Keep the wider journey and undecided stops in planning_context; never save guesses as preferences. A whole-trip budget is a ceiling, not a hotel rate: use wider_journey when it covers the wider trip, even if only Japan is saved; do not narrow it to saved_trip without the traveler saying so. Private context and ceiling metadata have no edit operation or website editor. Share trip_url and saved_scope first. Poll only if the host can actually wait planning_progress.poll_after_ms, for at most 60 seconds; otherwise return the current phase. Stop on ready, failed or unknown. Never promise a completion time or a later callback. It does not invite, hold inventory or spend money. Effects: Creates one private draft trip per request key and runs trip research (model and provider cost).
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | ||
| party | No | ||
| budget | No | ||
| segments | No | Confirmed cities in travel order with contiguous local check-in/check-out dates. Unchosen stops belong in planning_context.undecided_stops. | |
| arrival_at | No | ||
| date_range | No | Confirmed local first-night/check-out dates at the destination, not an unconfirmed overseas departure date. Ask before calling when arrival day is ambiguous. | |
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. | |
| departure_at | No | ||
| planning_budget | No | ||
| destination_refs | No | One confirmed city or named stay destination from anywayr_resolve_destination, never a country placeholder. For multiple cities use segments. | |
| planning_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the generic safety profile (readOnlyHint=false, idempotentHint=true, openWorldHint=true, destructiveHint=false). The description adds what the annotations cannot: one private draft per request_key, immediate trip_url, that the call incurs model and provider cost, that private context/ceiling metadata has no edit or web editor, and that the tool does not invite, hold inventory or spend money.
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 the key 'completed means saved' clarification, and most sentences carry a distinct rule. It is dense and several sentences pack multiple semicolon-joined rules, which makes it harder to scan, but given 11 nested parameters and no output schema there is little 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?
With no output schema, the description supplies the return contract itself: immediate trip_url, a phase-based planning status, poll_after_ms, and terminal states (ready/failed/unknown). It also tells the agent what to surface first (trip_url and saved_scope) and what not to promise (completion time, callbacks), which is complete for a complex write-and-research 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 description coverage is only 36% across 11 parameters (many nested), so the description carries real weight and does: it explains destination_refs vs segments ('one destination_ref or confirmed segments for 2-5 contiguous cities'), that dates and travelers are required and budget optional, that undecided stops belong in planning_context, and it disambiguates budget scope (whole-trip ceiling is 'not a hotel rate'; use wider_journey unless the traveler narrows it). It does not explicitly cover 'brief' or 'party', but adds substantial meaning beyond 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 opening sentence gives a specific verb and resource ('Saves a private trip and returns its real trip_url immediately') and immediately disambiguates the word 'completed' for this tool. An agent can distinguish it from anywayr_get_trip, anywayr_update_trip and anywayr_list_trips 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?
Explicit preconditions are given ('confirm a city or named stay destination (not a country) and its exact local arrival/check-out dates', 'ask one combined question if those are missing'), along with a prohibition ('Do not save a placeholder draft first') and a routing rule ('Use one destination_ref or confirmed segments for 2-5 contiguous cities'). Polling guidance names the condition and the cap (poll_after_ms, at most 60 seconds) and stop states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates (or returns the existing) checkout for a quote and gives a secure Anywayr link where the traveler reviews the exact booking, enters traveler and payment details and approves. Preparing is not approval; nothing is booked or charged here. Effects: Creates one checkout per quote revision. No charge, hold or reservation.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_ref | Yes | Anywayr quote reference (starts with qte_), as returned by anywayr_quote_booking. | |
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. | |
| quote_revision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give readOnlyHint=false, idempotentHint=true and destructiveHint=false, and the description adds real value on top: no charge/hold/reservation, preparing is not approval, and the idempotency rule ('one checkout per quote revision') which explains the idempotentHint. It does not describe failure modes or what happens to prior checkouts, keeping it short of 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?
Three tightly packed sentences, front-loaded with the action and output, then the crucial 'not approval' disambiguation, then a structured 'Effects:' clause. Every sentence earns its place 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?
With no output schema, the description telling the agent it returns a secure link is useful, and it fully covers the mutation's side effects. Minor gap: it does not say what the response contains beyond the link or what to do with the link, but for a 3-param tool this is close to 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 67%, so the schema already documents quote_ref and request_key in detail. The description reinforces the quote/revision relationship ('one checkout per quote revision') but adds no format or syntax beyond the schema, so baseline 3 is appropriate.
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 ('Creates (or returns the existing) checkout for a quote') plus the scope (one per quote revision) and points to the output (a secure link). It implicitly distinguishes itself from downstream approval, but does not name a sibling tool like anywayr_quote_booking or any approval step explicitly.
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?
The line 'Preparing is not approval; nothing is booked or charged here' clarifies the stage in the flow, which implies when to call it. However, it never states when to use this over alternatives or what upstream prerequisites (e.g., a completed quote) must hold, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets an expiring, exact price and terms for a selected offer. The quote states any provider-side effect of quoting. It never charges, reserves, holds a seat or invites anyone. Effects: Stores a quote revision and makes a provider price check.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_ref | No | Anywayr trip reference (starts with trp_), as returned by anywayr_plan_trip, anywayr_list_trips or anywayr_get_trip. | |
| offer_ref | Yes | Anywayr offer reference (starts with ofr_), as returned by anywayr_get_hotel_rates, anywayr_search_flights or anywayr_get_offer. | |
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. | |
| stay_segment_ref | No | Anywayr stay segment reference (starts with seg_), as returned by anywayr_get_trip. | |
| traveler_set_ref | No | Anywayr traveler set reference (starts with tvs_), as returned by the Anywayr website checkout. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing concrete side effects: it 'Stores a quote revision and makes a provider price check,' and it explicitly disclaims charging, reserving, holding, or inviting. This reconciles cleanly with readOnlyHint=false and destructiveHint=false, telling the agent exactly what write occurs.
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 effects, then explicit non-effects — four tight sentences with little waste. The 'The quote states any provider-side effect of quoting' sentence is slightly meta but still informative.
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 tool with no output schema and a write side effect, the description adequately covers what it does, what it stores, and what it deliberately avoids. It could say more about the quote's expiration timing and return shape, but nothing critical is missing 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% and every parameter carries a detailed description (ref prefixes, request_key retry semantics), so the schema does the heavy lifting. The description adds no parameter-level detail, making the baseline 3 appropriate.
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: 'Gets an expiring, exact price and terms for a selected offer.' Clearly distinct from the cancellation-quote sibling by scope. However, it never names a sibling or scope boundary explicitly, so an agent must infer the distinction from the resource alone.
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?
The 'never charges, reserves, holds a seat or invites anyone' line implies this is a pre-booking pricing step, giving implied when-to-use context. But there is no explicit routing against alternatives like anywayr_prepare_checkout or anywayr_quote_cancellation, and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Asks the supplier what cancelling one booking would refund right now. Shows the refund, whether it is the full amount paid, and the next step: confirm in chat (full refunds only, with the cancel permission) or a link where the traveller confirms on Anywayr. Cancels nothing; tell the traveller the refund before any confirmation. Effects: Asks the supplier for a cancellation quote (for flights, a pending airline cancellation that expires unused). No money moves.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_ref | Yes | Anywayr booking reference (starts with bkg_), as returned by anywayr_list_bookings or a completed booking. | |
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false; the description explains exactly why the read is not side-effect free — for flights it opens 'a pending airline cancellation that expires unused' — and reassures that 'No money moves.' It also discloses the cancel-permission requirement for full-refund confirmations, context the annotations cannot 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?
Roughly four sentences, purpose front-loaded, then next-step, then a labeled 'Effects:' clause. Every sentence carries distinct information — scope, follow-up path, and side-effect profile — with no repetition or 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?
With no output schema, the description still tells the agent what the quote returns (refund amount, whether it is the full amount paid, and the confirmation path). Combined with the side-effect disclosure, an agent has everything needed to call it correctly and act on the result.
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 schema already documents both booking_ref (format bkg_) and request_key (idempotency/reuse semantics). The description adds no parameter-level detail, which is acceptable at full coverage; baseline 3.
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 names a specific action (ask the supplier what cancelling one booking would refund) and the resource (a single booking's cancellation terms). It clearly distinguishes itself from anywayr_confirm_cancellation by stating it 'Cancels nothing.' An agent can route correctly 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?
The description establishes the flow context ('the next step: confirm in chat... or a link') and an operating rule ('tell the traveller the refund before any confirmation'). It stops short of explicitly naming anywayr_confirm_cancellation as the follow-up call, but the sequencing is clear enough that the agent knows when this tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turns a place name into Anywayr place references. Returns every plausible match for the traveler to choose from; it never picks one silently. Effects: None. May call a place-lookup provider.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds real context beyond them: "Effects: None. May call a place-lookup provider" discloses an external dependency, and "never picks one silently" tells the agent to expect multiple results rather than a single answer. Minor gap: no mention of latency, rate limits, or failure behavior when the provider is unreachable.
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 core transformation, then the result guarantee, then the side-effect disclosure. No filler and nothing buried.
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?
There is no output schema, and the description only partially covers return values ("every plausible match") without saying what a match contains or how many to expect. The undocumented kind parameter is the main completeness gap for an otherwise simple two-parameter lookup 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 description coverage is 0%, so the description must carry parameter meaning and it largely does not. "Place name" loosely maps to the required query parameter, but the required kind enum (any/city/airport) is never mentioned, leaving the agent to discover that constraint only by reading 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 gives a specific verb+resource pair: "Turns a place name into Anywayr place references." That is precise enough to distinguish it from siblings like search_flights or search_hotels, which consume destinations rather than resolve them. It stops short of explicitly naming an alternative, but the purpose 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?
"Returns every plausible match for the traveler to choose from" implies this is a disambiguation step to run before other destination-consuming tools, but no when-to-use or when-not-to-use condition is stated. There is no explicit routing to or from a sibling, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches flights for exact legs, passengers and cabin. The requested cabin is kept throughout; offers in another cabin are labeled, never substituted. Children need real ages. Effects: Stores a search snapshot and spends provider search budget. Holds no seats.
| Name | Required | Description | Default |
|---|---|---|---|
| legs | Yes | ||
| cabin | Yes | ||
| currency | No | Currency for prices. Only USD is supported today; omit it or pass "USD". | USD |
| passengers | Yes | ||
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is the strongest part of the description. It explicitly states non-obvious behavior: the requested cabin is preserved and alternate-cabin offers are labeled, children require real ages, a search snapshot is stored, provider search budget is spent, and no seats are held. Annotations already cover readOnly/idempotent/open-world safety, so this adds genuine operational context beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then caveats, then side effects. Every sentence earns its place; no filler or repetition of obvious schema details.
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 search tool with no output schema and nested parameters, the description covers the key behavioral quirks (cabin policy, budget spend, snapshot storage, no seat hold). It could be more complete by mentioning output availability or retry semantics with request_key, but it is solid overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description must compensate, but it only clarifies a few semantics: "Children need real ages" and the cabin-preservation rule. Nested legs and passengers structure remain largely schema-documented, and there is no explanation of request_key semantics beyond the schema. Baseline 3 is appropriate given partial schema coverage and partial description assistance.
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 opens with a specific verb-and-resource statement: "Searches flights for exact legs, passengers and cabin." This is clearer than a bare tautology and names the scope, but it does not differentiate from sibling search_* tools like anywayr_search_hotels, which is essentially self-evident from the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as anywayr_prepare_checkout or anywayr_quote_booking. The description implies it is a search step but never says "call this before X" or "use this to get offer references."
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches hotels for exact dates and one room with real guest ages. Results come best-first the way Anywayr ranks them (guest rating and review count, star class, value, location), 20 at a time; pass sort "top_rated" or "cheapest" to change that, and min_stars / min_guest_rating / max_total / max_distance_km / free_cancellation_only / breakfast_included to filter (e.g. for "somewhere nicer"). Sort "best_deal" returns only hotels in the place priced at or below similar hotels near them in the same search, each with a deal: quote deal.why as given, and say "deal" or "great deal" only when deal.label does; a "pick" is about other hotels in this search, never this hotel's usual price. When fewer than 3 hotels inside the place qualify, nearby ones follow with location.inside_place false: never call them in the place, and give their town and distance as their first why line does. An airport is a point: no hotel is in it, only near it. Never compare Anywayr's prices with other sites. With best_deal a state or country is searched as its most-booked hotel area (narrowed_to). With a room filter, quote matched_room. Each hotel has its address and distance from the centre of the searched place. For the next 20, call again with the same search and cursor set to next_cursor (no new supplier search). Quote all_in_total as the price: it adds fees the hotel collects at the property to what Anywayr charges; when it is null, say the hotel may charge extra at the property. Give both prices per hotel when they differ: cheapest_room (often non-refundable) and cheapest_free_cancellation_room with its free-cancellation date. Unsupported party shapes are refused, not adjusted. Results say whether they are live or cached and whether any source was missing; a provider outage is never reported as no availability. Prices shown are leads, not quotes. Effects: Stores a search snapshot (so rates can be read later) and spends provider search budget. Holds nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| cursor | No | Anywayr cursor reference (starts with cur_), as returned by the next_cursor of a previous page. | |
| currency | No | Currency for prices. Only USD is supported today; omit it or pass "USD". | USD |
| max_total | No | Highest whole-stay price in USD, including fees the hotel collects at the property. | |
| min_stars | No | ||
| date_range | Yes | ||
| occupancies | Yes | ||
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. | |
| destination_ref | Yes | Anywayr place reference (starts with plc_), as returned by anywayr_resolve_destination. | |
| max_distance_km | No | Only hotels within this many km of the centre of the searched place. | |
| min_guest_rating | No | ||
| breakfast_included | No | Only hotels with a room that includes breakfast; prices then quote that room. | |
| free_cancellation_only | No | Only hotels with a room that can be cancelled for free; prices then quote that room. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations with details the structured fields cannot carry: unsupported party shapes are refused rather than adjusted, results state live vs cached and flag missing sources, a provider outage is never reported as no availability, and prices are leads not quotes. The Effects line explicitly names the snapshot write and provider-budget spend, so the agent is not surprised by the readOnlyHint framing.
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?
Nothing is wasted and the purpose is front-loaded, but the body is one dense block that interleaves pagination, deal-labeling policy, nearby-hotel fallback, and price-quoting rules. Breaking these into distinct sentences or semicolon groups would improve scanability without losing content.
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 and 13 parameters, the description still covers return-shape essentials: all_in_total semantics and the null case, dual cheapest_room vs cheapest_free_cancellation_room pricing, next_cursor pagination, location.inside_place, and how to quote deal.why and deal.label. An agent could call and report results correctly from this alone.
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?
At 62% schema coverage, the description compensates well for the undocumented params: it explains what top_rated/cheapest/best_deal do, that a room filter makes prices quote matched_room, and that a state or country is folded to its most-booked area via narrowed_to. request_key and currency are left to the schema, which is acceptable.
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 exact scope: "Searches hotels for exact dates and one room with real guest ages." That scope plus the sort/filter machinery distinguishes it cleanly from siblings like list_city_deals or get_hotel_rates.
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 concrete triggers for each mode — pass "top_rated" or "cheapest" to change ranking, use the filter parameters for "somewhere nicer", and re-call with cursor to get the next 20. What is missing is sibling routing: it never says when to prefer list_city_deals or get_hotel_rates instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes the dates or the number of travelers of a trip you can edit (the same edits the Anywayr website allows; budget, title and preference edits are refused for now). Requires the version you last read with anywayr_get_trip; a stale version is refused rather than overwritten. Multi-city date changes and child-leg party changes require the Anywayr website. Does not share, invite or book. Effects: Writes a new trip version.
| Name | Required | Description | Default |
|---|---|---|---|
| changes | Yes | ||
| trip_ref | Yes | Anywayr trip reference (starts with trp_), as returned by anywayr_plan_trip, anywayr_list_trips or anywayr_get_trip. | |
| request_key | Yes | Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request. | |
| expected_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructiveHint/idempotentHint; the description adds substantive behavior beyond them: optimistic-concurrency semantics (stale version refused rather than overwritten), the effect of writing a new trip version rather than mutating in place, and the refusal list for unsupported edit types. This is exactly the extra context annotations cannot 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?
Front-loads the action and its scope, then prerequisites, then exclusions, then effects. The parenthetical about website-parity edits is dense but carries real selection value; no sentence is 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 4-parameter mutation tool with nested objects, no output schema and only partial schema coverage, the description supplies everything an agent needs: precondition, refusal conditions, out-of-scope cases, and the write effect. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with expected_version having no schema description; the description compensates by explaining that it must be the version last read via anywayr_get_trip and that mismatches are refused. It also constrains the valid contents of `changes`, though it doesn't restate the nested party/date sub-field semantics (which the schema covers).
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 (changes) plus the exact resource and editable fields (dates, number of travelers) on a trip, and explicitly rules out what it is not (no share/invite/book, no budget/title/preference edits). An agent can distinguish it from siblings like anywayr_get_trip or anywayr_plan_trip 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?
Gives the precondition (requires the version last read via anywayr_get_trip), the failure mode (stale version refused), and the out-of-scope cases routed elsewhere (multi-city date changes and child-leg party changes require the Anywayr website). Explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
anywayr_search_hotels5 fields changedInput schema / properties / breakfast_includedAdded value: +{
+ "description": "Only hotels with a room that includes breakfast; prices then quote that room.",
+ "type": "boolean"
+}Input schema / properties / free_cancellation_onlyAdded value: +{
+ "description": "Only hotels with a room that can be cancelled for free; prices then quote that room.",
+ "type": "boolean"
+}Input schema / properties / max_distance_kmAdded value: +{
+ "description": "Only hotels within this many km of the centre of the searched place.",
+ "maximum": 50,
+ "minimum": 0.5,
+ "type": "number"
+}Input schema / properties / max_totalAdded value: +{
+ "description": "Highest whole-stay price in USD, including fees the hotel collects at the property.",
+ "exclusiveMinimum": 0,
+ "maximum": 1000000,
+ "type": "number"
+}Input schema / properties / sort / enumPrevious value: -[
- "best",
- "top_rated",
- "cheapest"
-]New value: +[
+ "best",
+ "top_rated",
+ "cheapest",
+ "best_deal"
+]anywayr_get_hotel_rates1 field changedInput schema / properties / search_ref / descriptionPrevious value: -"Anywayr search reference (starts with srch_), as returned by anywayr_search_hotels or anywayr_search_flights."New value: +"Anywayr search reference (starts with srch_), as returned by anywayr_search_hotels, anywayr_search_flights or anywayr_discover_flight_deals."anywayr_list_city_dealsanywayr_capabilitiesanywayr_confirm_cancellationanywayr_get_bookinganywayr_get_hotel_ratesanywayr_get_offeranywayr_get_operationanywayr_get_tripanywayr_list_bookingsanywayr_list_tripsanywayr_plan_tripanywayr_prepare_checkoutanywayr_quote_bookinganywayr_quote_cancellationanywayr_resolve_destinationanywayr_search_flightsanywayr_search_hotelsanywayr_update_tripPlan trips and find hotels, tours and flights; build day-by-day itineraries. Account required.
Search flights, hotels & experiences at all-in prices, then build a trip on breckenwander.com.
Waysway AI travel MCP for hotels, live prices, restaurants, flights, and activities.
Create trips, compare variants side by side, and add accommodation, transport and event options.
Add one secure layer between your agents and this server.
