Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

agoda_flights_search

Search Agoda one-way flights between two IATA airport codes for a departure date, returning bookable itineraries with airline, times, layovers, aircraft, and price. Resolve city names to codes first.

Instructions

Search Agoda one-way flights. Returns bookable one-way flight itineraries between two IATA airport codes for a departure date, including per-segment flight number, airline, times, layovers, aircraft type, and price. Resolve free-text city/airport names to codes first via the flight destination search endpoint.

Input Schema

NameRequiredDescriptionDefault
pageNo1-indexed result page, defaults to 1
adultsNoAdult passengers (age 12+), defaults to 1
originYesOrigin IATA airport code
infantsNoInfant passengers (under age 2), defaults to 0
childrenNoChild passengers (age 2-11), defaults to 0
cabin_classNoCabin class, defaults to Economy
destinationYesDestination IATA airport code
departure_dateYesDeparture date, YYYY-MM-DD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / cabin_class / enum
      Added value: +[
+  "Economy",
+  "PremiumEconomy",
+  "Business",
+  "First"
+]
  2. Added

TDQS

A3.8/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 behavioral burden. It does disclose the return contents (per-segment flight number, airline, times, layovers, aircraft type, price), which is valuable since there is no output schema, but it says nothing about pagination behavior, rate limits, or result freshness.

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

Conciseness5/5

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

Three tight sentences, purpose front-loaded, return payload enumerated, and the input-resolution caveat placed last. No filler or redundancy.

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 and no annotations, the description supplies the purpose, the returned fields, and the input-code prerequisite, which is enough for correct invocation. It stops short of covering pagination or result limits for what is a paginated search.

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 schema already documents all 8 parameters including the IATA-code requirement and defaults. The description reinforces that origin/destination are IATA codes and must be resolved from free text first, adding mild value but not going beyond the structured fields.

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 and resource ('Search Agoda one-way flights') plus the scope ('one-way', between two IATA codes, for a departure date'), so an agent knows exactly what operation this is. It distinguishes from flight siblings by naming the complementary location-resolution endpoint, though it does not name any alternative by tool name.

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

Usage Guidelines4/5

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

Explicitly tells the agent the precondition for correct invocation: resolve free-text city/airport names to codes first via the flight destination search endpoint. It gives clear context for use but does not state when-not-to-use (e.g., that round-trip or multi-city searches are out of scope).

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