Skip to main content
Glama

Fly Travel Albania

by al.flytravel
OverviewDiscussionsAdmin

Price for a specific hotel (live cache)

charter_hotel
Read-onlyIdempotent

Cached price(s) for ONE hotel named by the user (e.g. "Granada Luxury Belek") — searches the full price cache (hundreds of hotels). ALWAYS pass the date and the party the user gave: the per-date cache is read for that EXACT party first (party_match=true = real total for that family), then the 2-adult file (party_match=false = reference price). exact_date_matches = real cached prices for the requested date; other_cached_offers belong to their OWN dates (availability_status=reference_other_date). When nothing is cached for the requested date, say so and give hotel_page (it prices any date live). Do NOT call this tool repeatedly to browse — use charter_offers (filters) or compare_hotels (2-6 named hotels) instead. For amenities use hotel_details. CACHED prices (from recent real searches on flytravel.al — not a live query; every row carries cached_at/age_minutes). Charter prices are PACKAGE TOTALS in EUR for the row's "party" (flight + hotel + transfers), NOT per person. party_match=false means the price is the 2-adult reference, not the total for the requested party — say so. A price belongs ONLY to its own "date": never present it as the price of another date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoDesired departure date, format YYYY-MM-DD — exact-date cache is checked and the date is baked into the links.
hotelYesHotel name, or part of it.
adultsNoNumber of adults (default 2).
nightsNoTrip length in nights. Omit for the standard charter length (6 nights / 7 days). Most departures also sell 3-10 nights.
destinationNoOptional destination key ('antalya', 'bodrum') to narrow the search.
children_agesNoAge of each child AT DEPARTURE (0-14 = child; 15+ is counted as an adult automatically).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / children_ages / description
      Previous value: -"Age of each child at departure (0-14; 15+ counts as an adult)."New value: +"Age of each child AT DEPARTURE (0-14 = child; 15+ is counted as an adult automatically)."
    • addedInput schema / properties / children_ages / items / maximum
      Added value: +17
    • addedInput schema / properties / children_ages / items / minimum
      Added value: +0
    • addedInput schema / properties / children_ages / maxItems
      Added value: +6
    • changedInput schema / properties / date / description
      Previous value: -"Optional desired departure date, format YYYY-MM-DD — baked into the returned links."New value: +"Desired departure date, format YYYY-MM-DD — exact-date cache is checked and the date is baked into the links."
    • addedInput schema / properties / nights
      Added value: +{
+  "description": "Trip length in nights. Omit for the standard charter length (6 nights / 7 days). Most departures also sell 3-10 nights.",
+  "maximum": 21,
+  "minimum": 2,
+  "type": "integer"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only indicate read-only and idempotent behavior, but the description adds major behavioral nuance: the data is cached, not live; party_match semantics; exact_date_matches vs other_cached_offers; that prices are package totals in EUR, not per-person; and that a price belongs only to its own date. This far exceeds what the annotations reveal and prevents common misinterpretations.

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?

The description is dense and packed with necessary caveats, all of which earn their place. It could be better organized with bullet points, and there is minor repetition of the not-live/cached concept, but it remains well-structured with front-loaded scope and clear separators between key ideas.

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?

With no output schema, the description supplies the crucial output semantics: exact_date_matches, other_cached_offers, availability_status=reference_other_date, party_match flags, cached_at/age_minutes, and the hotel_page fallback. It also covers edge cases (no cached date, wrong party, wrong date) so an agent can correctly interpret and present results in every scenario.

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 is 100%, so the baseline is 3. The description adds value by instructing the agent to always pass the date and party given by the user, explaining that the exact party's cache is read first, and clarifying the 2-adult reference fallback. This behavioral mapping goes beyond the schema's per-field descriptions, though it is somewhat redundant with them.

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 scope: it returns cached prices for ONE named hotel, and gives an example hotel name. It explicitly distinguishes itself from the siblings charter_offers (filters), compare_hotels (2-6 named hotels), and hotel_details (amenities), so an agent can immediately differentiate it.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: call it when the user names one specific hotel, and do NOT call it repeatedly for browsing — instead use charter_offers or compare_hotels. It also prescribes a specific fallback behavior when nothing is cached: say so and provide hotel_page, which leaves no ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Fly Travel Albania toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources