Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

booking_flights_search

Search Booking.com flight offers between two locations by departure and return dates, one-way or round-trip, passenger counts, and cabin class; returns prices, currencies, and itinerary segments.

Instructions

Search Booking.com flights. Returns Booking.com flight offers between two locations given as from and to (such as SGN.AIRPORT), for a depart date. type is ROUNDTRIP (default, needs return) or ONEWAY. Also takes adults (1 to 9), children, cabin_class and sort. Offers carry price, currency and segments with legs; the response adds total_count and min_price.

Input Schema

NameRequiredDescriptionDefault
toYesDestination location id, same composite format as from
fromYesOrigin location id, e.g. SGN.AIRPORT, from a prior autocomplete result
sortNoResult sort order, default BEST
typeNoTrip type, default ROUNDTRIP
adultsNoNumber of adults, 1-9, default 1
departYesDeparture date, YYYY-MM-DD
returnNoReturn date, YYYY-MM-DD, required when type is ROUNDTRIP
childrenNoNumber of children, 0-9
to_countryNoDestination country code
cabin_classNoCabin class, default ECONOMY
from_countryNoOrigin country code

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / type / enum
      Added value: +[
+  "ROUNDTRIP",
+  "ONEWAY"
+]
  2. Added

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It helpfully discloses the return shape (offers with price, currency, segments; plus total_count and min_price) and the ROUNDTRIP/ONEWAY default logic, but says nothing about auth requirements, rate limits, or whether location ids must come from a prior autocomplete call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and front-loaded: the core purpose leads, then parameters, then return shape, in a compact few sentences with no filler. Slightly list-like but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 covers the response fields (price, currency, segments, total_count, min_price), which is the right compensation. It is complete enough to call correctly, with the only gap being the absence of guidance about sourcing location ids.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 restates the key parameters (from/to format, type default and return dependency, adults 1-9) but largely mirrors what the schema already documents rather than adding new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Search Booking.com flights') and clarifies it returns flight offers between two locations. It is distinguishable from generic flight siblings by naming Booking.com, but it does not explicitly differentiate itself from booking_flights_autocomplete or the expedia/agoda flight searches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied through the parameter walkthrough; there is no explicit when-to-use, when-not-to-use, or named alternative. An agent can infer it is the offer-retrieval step after autocomplete, but the routing 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.

Deploy Server

Other Tools