Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

agoda_flights_itinerary_amenities

Fetch Agoda flight segment amenities—aircraft type, seat layout, meals, entertainment, and wifi—by passing flight search segments. Get credential-free public details for one or more segments.

Instructions

Get Agoda flight segment amenities. Returns real-content amenities (aircraft type, seat layout, meals, entertainment, wifi) for one or more flight segments. Copy the segments straight from a flight search response's own segment fields. Credential-free public data from Agoda's own flight content service.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesOne or more flight segments to fetch amenities for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / body / properties
      Added value: +{
+  "segments": {
+    "items": {
+      "properties": {
+        "cabin_class": {
+          "type": "string"
+        },
+        "carrier_code": {
+          "type": "string"
+        },
+        "departure_date_time": {
+          "type": "string"
+        },
+        "destination_airport": {
+          "type": "string"
+        },
+        "fare_basis_code": {
+          "type": "string"
+        },
+        "flight_number": {
+          "type": "string"
+        },
+        "origin_airport": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "cabin_class",
+        "carrier_code",
+        "departure_date_time",
+        "destination_airport",
+        "flight_number",
+        "origin_airport"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}
    • addedInput schema / properties / body / required
      Added value: +[
+  "segments"
+]
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the transparency burden and does meaningful work: it discloses that the data is credential-free, comes from Agoda's own flight content service, and returns real-content (not generated) amenities. It does not cover failure modes or data availability edge cases, but for a simple read operation this is adequate.

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 sentences, each with a distinct purpose: action, output content, and input/auth guidance. The description is front-loaded with the verb and resource, contains no filler, and every sentence earns its place.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read endpoint with no output schema, the description is complete: it explains input provenance (copy from flight search response), output content (real-content amenities), and authentication (credential-free). The nested schema covers the required fields, so an agent has everything needed to invoke it correctly.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage for the body parameter is 100%, but the description adds valuable semantic guidance beyond field names: the segments should be copied verbatim from a flight search response's segment fields rather than manually constructed. This materially helps an agent populate the nested object correctly.

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

Purpose5/5

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

The description states a specific verb and resource ('Get Agoda flight segment amenities') and enumerates the exact content returned: aircraft type, seat layout, meals, entertainment, wifi. The name and scope clearly distinguish it from siblings like agoda_flights_search and agoda_flights_search_locations.

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?

The description gives clear operational context: copy segments directly from a flight search response's segment fields, implying this tool is a follow-up to a flight search. It does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

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