Flight fares, ticket prices, baggage rules and Umrah/Hajj dates for travel to and from Pakistan
Scored across 8 tools
Several tools return 'cheapest fares' and can be confused: search_fares, cheapest_days, ticket_price, flights_to_city and deals all surface low fares with overlapping phrasing. The descriptions do differentiate by framing (route+day vs. timing vs. city snapshot vs. directional deals), but an agent could easily misselect among them. clear overlap remains.
Mostly consistent snake_case noun phrases (airport_info, baggage_rules, cheapest_days, season_info, ticket_price). Minor deviations exist: 'deals' is a lone single word and 'search_fares' is verb_noun rather than the dominant noun style. Still readable and predictable.
Eight tools is well-scoped for a cheap-flights/deals site, covering search, timing, deals, airport, baggage and season information without bloat. Each tool maps to a plausible user question.
As an informational fares/deals service, the surface covers route search, cheapest-day timing, deals, destination pricing, airport info, baggage rules and travel seasons. Gaps are minor (e.g. no airline-filtered search or multi-city), workable for the stated purpose.
A Pakistani airport (Allama Iqbal Lahore, Jinnah Karachi, Islamabad, Bacha Khan Peshawar, Sialkot and others): its name and code, a short description and the cheapest flights from it right now. Does not give live flight status.
| Name | Required | Description | Default |
|---|---|---|---|
| airport | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses a limitation ('Does not give live flight status') and that fare data is current ('right now'), but says nothing about caching, freshness guarantees, or error behavior for unknown airports.
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 tight sentences with the scope and return contents front-loaded and the limitation placed last where it belongs. The airport enumeration is slightly long but serves as useful example data.
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, so the description correctly enumerates return fields and explicitly rules out live status. For a single-parameter lookup tool this is nearly complete, with the only gap being the accepted input format for 'airport'.
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% for the single required 'airport' parameter, so the description must compensate. It partially does by listing valid airport names (Allama Iqbal Lahore, Jinnah Karachi, Islamabad, etc.), but never states whether an IATA code, full name, or city is accepted, leaving the input format ambiguous.
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 names the specific resource (Pakistani airport details) and enumerates exactly what it returns: name, code, short description, and current cheapest flights. It also carves out a boundary by stating it does not provide live flight status, which separates it from status-oriented tools, though it never names a sibling alternative.
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?
Usage is implied rather than stated: an agent can infer it is for looking up an airport and seeing cheapest departing fares, but there is no explicit 'use this when...' guidance and no routing to siblings like cheapest_days, deals, or ticket_price when the user wants fares rather than airport data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checked and cabin baggage allowance on Pakistan routes for an airline (PIA, airblue, Fly Jinnah, Emirates, flydubai, Qatar Airways, Saudia, flynas, Air Arabia, Etihad), including Zamzam water rules and extra-baggage options, with links to guides on hand carry (power banks, liquids) and on what 1PC, 2PC and kg mean.
| Name | Required | Description | Default |
|---|---|---|---|
| airline | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the scope and shape of the content (allowance rules, Zamzam rules, extra-baggage options, links to hand-carry guides) but says nothing about behavior such as what happens for an airline not in the list, whether data is static or fetched, or what the response looks like.
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?
A single dense sentence that front-loads the main resource (checked and cabin allowance) before the secondary topics and the airline list. It is long but largely earns its length; only the trailing 'what 1PC, 2PC and kg mean' clause is arguably padded.
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?
No output schema and no annotations, so the description is the only source of truth. It sufficiently describes what topics are covered and that guide links are returned, but for a pure data-retrieval tool it never indicates the response form (text, links, structured fields) or coverage limits, leaving a modest 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 0% and the single 'airline' parameter has no schema description, so the description must compensate. It does this well by enumerating the supported airlines (PIA, airblue, Fly Jinnah, Emirates, flydubai, Qatar Airways, Saudia, flynas, Air Arabia, Etihad), effectively conveying an accepted value set beyond the bare string type.
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 names a specific resource (checked and cabin baggage allowance) and scopes it precisely to Pakistan routes and a listed set of airlines. It reads as a content manifest rather than a verb-led statement ('Get...'), but the retrieved information is unambiguous and no sibling (search_fares, ticket_price, airport_info, etc.) overlaps with baggage rules.
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?
Usage is only implied: an agent can infer this answers baggage-allowance questions, and the mention of Zamzam water and extra-baggage options widens the inferred trigger. There is no explicit when-to-use, no when-not-to-use, and no named alternative, though with these siblings there is little routing ambiguity to resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When to fly a route for less: the cheapest day of each month, the cheapest day of the week, and how much the cheapest day saves against a typical day. Uses fares for this month and next. Use for "which day is cheapest to fly Islamabad to Riyadh" or "best time to book Karachi to Dubai".
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | ||
| destination | Yes |
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 does disclose a meaningful behavioral limit — the analysis 'uses fares for this month and next' — which tells the agent the result's time horizon. It says nothing about data source, result stability, or any auth/rate constraints, so the disclosure is partial.
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 return shape is front-loaded in the first sentence and the usage examples follow. It is compact with no filler, though the two example queries partially restate the same intent and could be trimmed to one.
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 enumerates what comes back (cheapest day of each month, cheapest day of week, savings against a typical day) and scopes the fare data to the current and next month. Given only two simple string parameters, that is close to sufficient; input format guidance is the main missing piece.
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% for both parameters, so the description must compensate. The example city pairs ('Islamabad to Riyadh', 'Karachi to Dubai') imply origin/destination are city-level names, which is useful, but there is no statement about accepted formats, IATA codes, or ambiguity when a city has multiple airports.
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 states a specific resource (cheapest day per month, cheapest day of week, and savings vs a typical day) with an implicit verb ('returns/computes'). It is clear and concrete, but it never contrasts itself with the nearby siblings such as search_fares or ticket_price, so an agent must infer the boundary.
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?
Two worked example queries ('which day is cheapest to fly Islamabad to Riyadh', 'best time to book Karachi to Dubai') give strong positive usage context and even hint at the intended trip-planning intent. There is no explicit when-not guidance or named alternative tool, which keeps this below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's cheapest flights home to Pakistan from the Gulf, Saudi Arabia and the UK, and from Karachi, Lahore and Islamabad abroad. Use for "cheapest flights from Pakistan today" or "any deals to Dubai".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it mostly discloses only the temporal scope implied by 'Today's cheapest flights'. It says nothing about whether results are cached/stale, how many deals are returned, or any freshness or availability caveats, which matters for a deals tool.
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 tight sentences that front-load the scope and then the usage examples, with no filler. The route enumeration is a little dense but each clause carries information.
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 zero-parameter query tool with no output schema and no annotations, the description covers purpose and example triggers adequately. It stops short of describing result shape or how it relates to the fare-related siblings, but nothing essential for invocation 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?
The tool takes zero parameters (empty object schema), so there is nothing for the description to disambiguate; baseline 4 applies. The description appropriately focuses on route/scenario rather than inventing parameter guidance.
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 names a specific resource (today's cheapest flights) and constrains scope to concrete routes (Pakistan from Gulf/Saudi/UK, and abroad from Karachi/Lahore/Islamabad), so an agent knows exactly what it returns. It does not, however, differentiate itself from siblings like cheapest_days, search_fares, or ticket_price, which also concern fares.
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 example trigger phrasings ('cheapest flights from Pakistan today', 'any deals to Dubai'), which is implicit guidance about when to call it. But there is no stated alternative, no when-not condition, and no mention of how it differs from search_fares or cheapest_days, so routing remains partly inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cheapest recent fare into one Pakistani city from each city abroad (Gulf, Saudi Arabia, UK, Europe, USA, Canada) and from other Pakistani cities, cheapest first. Use for "cheapest way to fly home to Lahore" or "which city abroad has the cheapest flights to Peshawar".
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does disclose key traits: the result is a list of cheapest recent fares, one per origin city, sorted cheapest first, covering specified foreign regions and other Pakistani cities. It does not define 'recent', state data freshness, or describe pagination, but it conveys the core read-only query behavior and output ordering.
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 description is two tightly written sentences with no wasted words. The core behavior and scope are front-loaded, and the second sentence provides efficient usage examples.
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?
Given the simple one-parameter schema, no annotations, and no output schema, the description adequately explains what the tool returns conceptually: cheapest recent fares per origin, sorted cheapest first. It leaves some gaps around data recency, result fields, and currency, but is complete enough for an agent to select and invoke the tool 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?
Schema description coverage is 0%, so the description must compensate. It clarifies that the single required parameter is a Pakistani destination city and provides examples ('Lahore', 'Peshawar'), but it does not specify the expected format (e.g., city name vs. IATA code) or constraints beyond the examples.
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 states a specific resource (cheapest recent fare) and a clear scope (into one Pakistani city from each foreign region and other Pakistani cities). It distinguishes itself from generic fare tools by describing the inverted origin-to-destination aggregation, though it does not explicitly name or differentiate from siblings like search_fares or ticket_price.
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 concrete usage examples: 'cheapest way to fly home to Lahore' and 'which city abroad has the cheapest flights to Peshawar'. This makes the intended context clear, but it offers no explicit exclusions or guidance on when to use alternatives such as search_fares or cheapest_days instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheapest one-way fares for a route, by day, with airline, stops and a skyfarenet.com link.
Use for questions like "cheapest Lahore to Jeddah flight in November" or "Dubai to Islamabad ticket price".
origin and destination: a city name (Lahore, Dubai, Madinah, Buraydah), a 3-letter airport code (LHE, DXB),
or a country (Canada, UK, USA, Saudi Arabia, UAE, Italy...), which compares every airport we cover there.
month: optional, "YYYY-MM"; by default this month and next. Prices are in PKR.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | ||
| origin | Yes | ||
| destination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description must disclose behavior. It adds useful context: output includes airline, stops, skyfarenet link; prices in PKR; month defaults to this and next. However, it omits rate limits, auth needs, pagination, and result limits, leaving gaps for a no-annotation tool.
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 purpose, then usage examples, then parameter semantics. Line breaks aid scanning; examples and parameter details each earn their place. Slightly verbose but not wasteful.
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?
Given no annotations, no output schema, and 0% schema descriptions, the description is largely complete: purpose, usage examples, all parameter formats, output fields, currency, and defaults. Missing pagination/result-limit details, but sufficient to call 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?
Schema description coverage is 0%, so the description compensates fully. It explains origin/destination accept a city name, 3-letter airport code, or country, and month is optional 'YYYY-MM' defaulting to this and next month. This adds rich meaning beyond the bare schema titles.
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 resource and scope: cheapest one-way fares by route/day with airline, stops, and a skyfarenet.com link. Clear what it returns and gives example questions. Does not explicitly differentiate from sibling tools like ticket_price or cheapest_days, so short of 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?
Provides explicit example queries ('cheapest Lahore to Jeddah flight in November') that tell when to use the tool. No when-not-to-use or alternatives among siblings (e.g., ticket_price), so not 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expected dates and when to book for Pakistan's busy travel seasons: Ramadan Umrah 2027, Hajj 2027 (including when Hajj flights from Pakistan are expected to start), Eid al-Fitr and Eid al-Adha 2027, winter 2026 and summer 2027 school holidays.
| Name | Required | Description | Default |
|---|---|---|---|
| season | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only describes content scope. It does not state whether the tool is read-only, whether data is static or live, or any other operational trait such as rate limits or authentication needs. No contradiction exists, but transparency is minimal.
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 description is a single, front-loaded sentence that efficiently covers all key seasons. It avoids filler, though the parenthetical aside slightly interrupts flow. Overall it is appropriately sized for a simple reference tool.
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 one-parameter lookup tool with no output schema or annotations, the description adequately conveys what information will be returned and which seasons are covered. It does not describe the output format, but for a simple informational tool this is a minor gap. The definition is largely self-contained.
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 schema has 0% description coverage for the single 'season' parameter, so the description must compensate. It lists the enum values in human-readable form and adds meaning like 'winter 2026 and summer 2027 school holidays' and 'when Hajj flights from Pakistan are expected to start', which is more than the raw enum slugs provide.
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 clearly states what the tool returns: expected dates and booking timing for specified Pakistan travel seasons. It enumerates all six supported seasons, making the scope unambiguous. However, it does not explicitly differentiate this tool from sibling tools like cheapest_days or deals, so it falls short of the top score.
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 implies usage by listing the seasons and the type of information provided, but it does not state when to use this tool versus alternatives or any prerequisites. No explicit when/when-not guidance or sibling references are present. This is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's lowest ticket prices from Pakistan for a popular trip, by city: Dubai, Saudi Arabia (Jeddah, Riyadh, Dammam, Madinah), Umrah (Jeddah and Madinah, and flights home), Skardu and Gilgit, domestic flights within Pakistan, and China. Use for "Umrah ticket price today" or "Dubai ticket price from Pakistan".
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the data kind (lowest price, today) but says nothing about currency, whether prices are cached/estimates or live, update cadence, or what happens with invalid/unavailable topics — all material for a price tool.
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 purpose is front-loaded in the first clause, followed by the destination list and two example queries, with little padding. The parenthetical destination enumeration is somewhat sprawling but each item adds coverage of a distinct enum value.
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 one-parameter, no-output-schema, no-annotation tool, the description covers what is returned at a high level (lowest prices today, broken out by city/topic) and how to ask for it. It falls short on output shape cues (currency, one price per route vs. per city, freshness) and gives no hint that only a fixed set of six topics is accepted.
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 compensate, and it largely does: it enumerates what each enum bucket covers (Saudi Arabia = Jeddah/Riyadh/Dammam/Madinah; Umrah = Jeddah and Madinah plus flights home; Skardu/Gilgit; domestic; China). This maps meaningfully onto the six enum values beyond the bare tokens, though it never states the required 'topic' parameter explicitly.
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: 'Today's lowest ticket prices from Pakistan ... by city', which tells an agent this is a daily snapshot of cheapest fares per destination topic. It does not differentiate itself from siblings like cheapest_days, search_fares, or deals, so an agent must still infer which of the seven fare-ish tools to pick.
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?
Example phrasings ('Umrah ticket price today', 'Dubai ticket price from Pakistan') imply the intended context and help map user queries to the topic enum. There is no statement of when NOT to use it, nor any pointer to alternatives such as search_fares for specific routes/dates or cheapest_days for flexible-date advice.
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.
airport_infobaggage_rulescheapest_daysdealsflights_to_citysearch_faresseason_infoticket_priceFlight search, airfare analytics, flexible destinations
Google Flights prices for any route and date: round trips, cabins, stops, airlines, cheapest dates.
Live flight, hotel and seat prices, cheapest-day calendars, and price-drop alerts.
Live flight prices and working booking links for AI agents and travel apps.
Add one secure layer between your agents and this server.
