I Know The Pilot

Server Details

Find curated cheap flight and travel deals from Australia.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 42 days
Last Tested: 2026-09-28 20:57
Transport: Streamable HTTP · MCP 2025-03-26
URL

TDQS

A4.2/5.0

Scored 2026-08-24 02:40 across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: find_cheapest_flights_to handles unknown origins, get_cheapest_flight_dates handles known origins and destinations, get_deal retrieves details for a specific deal, list_top_deals_from filters by airport, and search_deals does criteria-based searching. The descriptions explicitly cross-reference each other to prevent confusion.

Naming Consistency5/5

All tools use a consistent snake_case with a verb-noun pattern (find_, get_, list_, search_). Although verbs vary (find, get, list, search), they align with the action each tool performs, and the pattern is uniform across the set.

Tool Count5/5

With 5 tools, the server is tightly scoped to its purpose of flight deal discovery. Each tool addresses a distinct user need (unknown origin, known origin/date, deal details, airport-specific deals, criteria search), and there is no bloat or redundancy.

Completeness4/5

The toolset covers the primary workflows: finding cheapest flights, exploring deals by airport or criteria, and retrieving deal details. A minor gap is that there is no explicit tool to view all destinations from a given origin without a specific destination (though list_top_deals_from partially covers this), but the core discovery loop is complete.

Available Tools

5 tools

find_cheapest_flights_toFind Cheapest Flights To DestinationA

Read-only

Inspect

When the user hasn't said where they're flying from, compare the cheapest fare to a destination from every origin airport with cached data. Prices are cached fares in AUD from I Want That Flight (I Know The Pilot's sister flight-search site) - refreshed regularly and indicative, not live availability. Always present the travel dates alongside prices. Use this for 'cheapest flights to Bali next month' queries; use get_cheapest_flight_dates when the origin is known.

ParametersJSON Schema

Name	Required	Description	Default
`round_trip`	No	True for return fares (default), false for one-way
`cabin_class`	No	Cabin class	economy
`destination`	Yes	Destination airport code, city name, or country name (e.g. 'DPS', 'Bali', 'Japan')
`depart_date_to`	Yes	End of the departure window (YYYY-MM-DD)
`depart_date_from`	Yes	Start of the departure window (YYYY-MM-DD)

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	No	Number of results returned
`origin`	No	Origin airport code (present when an origin was specified)
`message`	No	Optional message about the results
`results`	No
`currency`	No	Currency code (always AUD)
`destination_airports`	No	Airport codes the destination resolved to

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: the data is cached, in AUD, indicative rather than live, and that travel dates must be presented alongside prices. This goes beyond what annotations could capture and is essential for correct agent behavior.

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 somewhat long but every sentence serves a purpose: condition, data nature, presentation requirement, and usage guidance. The key condition is front-loaded. It is slightly verbose with the sister-site detail ('I Know The Pilot's sister flight-search site'), but this is contextually useful and not wasteful.

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?

The description covers all essential aspects for correct invocation: the business scenario, data caveats, required output presentation, and the alternative tool. No critical information is missing. Since an output schema exists, return-value details do not need to be in the description.

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 every parameter already has an explanation. The description does not add additional meaning about parameter formats or constraints beyond what the schema provides. It mentions the destination and date window only implicitly, so it stays at the baseline for full schema coverage.

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 clearly states the action ('compare the cheapest fare'), the resource ('to a destination from every origin airport'), and the key condition ('when the user hasn't said where they're flying from'). It also differentiates from the sibling tool get_cheapest_flight_dates, so an agent can immediately tell them apart.

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?

It explicitly gives the condition for use ('when the user hasn't said where they're flying from') and names the alternative tool ('use get_cheapest_flight_dates when the origin is known'). This is direct, unambiguous guidance on when to choose this tool over others.

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

get_cheapest_flight_datesGet Cheapest Flight DatesA

Read-only

Inspect

For a known origin and destination, get the cheapest fare for each departure date in a date window. Prices are cached fares in AUD from I Want That Flight (I Know The Pilot's sister flight-search site) - refreshed regularly and indicative, not live availability. Always present the travel dates alongside prices. Use this for 'cheapest flights from Sydney to Bali in September' queries; use search_deals for curated editorial deals.

ParametersJSON Schema

Name	Required	Description	Default
`origin`	Yes	3-letter IATA origin airport code (e.g. 'SYD', 'MEL')
`round_trip`	No	True for return fares (default), false for one-way
`cabin_class`	No	Cabin class	economy
`destination`	Yes	Destination airport code, city name, or country name (e.g. 'DPS', 'Bali', 'Japan')
`depart_date_to`	Yes	End of the departure window (YYYY-MM-DD)
`depart_date_from`	Yes	Start of the departure window (YYYY-MM-DD)

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	No	Number of results returned
`origin`	No	Origin airport code (present when an origin was specified)
`message`	No	Optional message about the results
`results`	No
`currency`	No	Currency code (always AUD)
`destination_airports`	No	Airport codes the destination resolved to

TDQS

A4.7/5.0

Behavior5/5

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

The description adds behavioral context beyond the readOnlyHint annotation: prices are 'cached fares in AUD' from a specific site, 'refreshed regularly and indicative, not live availability', and it instructs the agent to 'Always present the travel dates alongside prices'. These are non-obvious behavioral traits that the agent must know, and they do not contradict annotations.

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?

The description is concise: three meaningful sentences that front-load the core purpose, then add critical behavioral notes (pricing source, instruction to present dates), and end with usage guidance. No fluff or redundancy.

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 read-only query tool with an output schema (return values covered there) and annotations already confirming safety, the description covers all essential operational context: scope (known origin/destination), pricing source and currency, necessity to present dates, and when to use an alternative. Nothing critical is missing.

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 does not add parameter-specific semantics beyond what the schema already explains (e.g., origin codes, date window). It mentions the general purpose but does not enrich individual parameter meanings, so no credit beyond baseline is warranted.

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 clearly states the verb 'get' and the resource 'cheapest fare for each departure date in a date window', with explicit constraints ('For a known origin and destination'). It differentiates from the sibling tool search_deals by naming it directly, making the tool's function unambiguous.

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 provides an explicit usage rule: 'Use this for "cheapest flights from Sydney to Bali in September" queries; use search_deals for curated editorial deals.' This directly instructs when to choose this tool over an alternative, leaving no room for inference.

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

get_dealGet Deal DetailsB

Read-only

Inspect

Get full details for a specific flight deal including routes and airlines.

ParametersJSON Schema

Name	Required	Description	Default
`deal_id`	Yes	The deal ID

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	No	URL to view and book the deal
`title`	No	Deal headline
`routes`	No	Flight routes available for this deal
`deal_id`	No	Unique deal identifier
`summary`	No	Brief description of the deal
`airlines`	No	Airline codes operating this deal
`currency`	No	Currency code (always AUD)
`from_price`	No	Starting price in AUD
`expiry_date`	No	Deal expiry date (YYYY-MM-DD)

TDQS

B3.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which covers the safety profile. However, the description adds no behavioral context beyond that: no mention of auth requirements, rate limits, or any constraints. It only states the output content (routes and airlines), which is return-value information rather than behavioral disclosure.

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?

The description is a single, front-loaded sentence that conveys the purpose and key output details without redundancy. Every word earns its place, making it concise and well-structured.

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?

Given the tool's low complexity (one parameter), good schema coverage, an output schema, and read-only annotations, the description is largely complete. It could have explicitly mentioned the deal_id requirement, but the schema covers that, so the overall context is adequate.

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?

The input schema fully documents the single deal_id parameter with 100% coverage. The description does not add information about the parameter, but the schema is sufficient. A baseline of 3 is appropriate because the description contributes no extra semantic value.

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?

The description uses a specific verb ('Get') and identifies the resource ('specific flight deal') with useful detail ('full details including routes and airlines'). It is clear and distinct enough from sibling tools like list_top_deals_from and search_deals, though it does not explicitly mention retrieval by deal ID.

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?

The phrase 'specific flight deal' implies this tool is for retrieving one deal rather than listing or searching, but the description provides no explicit guidance on when to choose this tool over siblings. The intended usage is only implied, not spelled out.

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

list_top_deals_fromList Top Deals From AirportA

Read-only

Inspect

List the cheapest currently active flight deals from a specific Australian airport. Great for answering 'what's cheap from Melbourne right now?'

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of results (1-20, default 5)
`origin`	Yes	Australian airport code (e.g. 'MEL', 'SYD', 'BNE', 'PER', 'ADL')

Output Schema

ParametersJSON Schema

Name	Required	Description
`deals`	No
`total`	No	Number of deals returned
`message`	No	Optional message about the results

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only and non-destructive, so the bar is lower. The description adds useful behavior context: results are limited to 'currently active' deals and sorted by 'cheapest', which goes beyond the annotations and helps the agent understand filtering and ordering behavior.

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?

The description is two sentences, with the first stating the core function and the second providing a practical example. No wasted words, information is front-loaded, and it earns every word.

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 full parameter coverage in schema, an output schema present, and annotations describing safety, the description fully covers purpose, use case, and behavioral nuances. The example cements the tool's role, making it complete for its complexity.

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 both parameters are already well-documented in the schema (origin as Australian airport code, limit with range and default). The description does not add additional parameter semantics, so the baseline of 3 applies.

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 uses the specific verb 'List' and names the resource 'cheapest currently active flight deals from a specific Australian airport', clearly distinguishing it from siblings like get_deal (specific deal) and search_deals (broader search). The scope is unambiguous and actionable.

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 provides a clear use case with the example "what's cheap from Melbourne right now?", implying when to use this tool. It does not explicitly mention alternatives or exclusions, but the context is strong enough for an agent to select it appropriately.

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

search_dealsSearch Flight DealsA

Read-only

Inspect

Search for currently active curated flight deals from Australia. Returns deals matching destination and/or price criteria. Deals are curated exceptional fares, not live inventory search.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Number of results (1-20, default 5)
`max_price`	No	Maximum price in AUD
`destination`	No	Airport code, city name, or country name (e.g. 'DPS', 'Bali', 'Japan')

Output Schema

ParametersJSON Schema

Name	Required	Description
`deals`	No
`total`	No	Number of deals returned
`message`	No	Optional message about the results

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare the tool as read-only and non-destructive. The description adds that deals are curated and not live inventory, plus the 'from Australia' scope, which sets expectations. This is comparable to baseline transparency, but does not go beyond the annotation-covered safety profile.

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?

Two concise sentences, no redundant words, and the core purpose is front-loaded. Every sentence contributes meaning.

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?

The tool is simple: 3 optional parameters, an output schema exists, and annotations cover safety. The description adequately covers purpose, scope (Australia), nature (curated deals), and the non-live-inventory caveat, making it complete for the given complexity.

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?

The input schema has 100% coverage with descriptive parameter comments (limit range, max price in AUD, destination examples). The description's 'destination and/or price criteria' echoes existing schema info without adding new semantic detail, so the baseline of 3 applies.

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?

The description clearly states the action ('Search') and the resource ('curated flight deals from Australia'), and specifies it matches deals by destination and/or price. It does not explicitly contrast with sibling tools like get_deal or list_top_deals_from, but the verb 'search' differentiates it sufficiently.

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 provides clear context: it is for curated exceptional fares, not live inventory search, which tells the agent when to use it. It does not name alternatives like get_deal for specific deal details, so it stops short of full explicit guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesAug 24, 2026
- Addedfind_cheapest_flights_to
- Addedget_cheapest_flight_dates

3 tool updatesJun 19, 2026

Changedget_deal1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "airlines": {
+      "description": "Airline codes operating this deal",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "currency": {
+      "description": "Currency code (always AUD)",
+      "type": "string"
+    },
+    "deal_id": {
+      "description": "Unique deal identifier",
+      "type": "integer"
+    },
+    "expiry_date": {
+      "description": "Deal expiry date (YYYY-MM-DD)",
+      "type": "string"
+    },
+    "from_price": {
+      "description": "Starting price in AUD",
+      "type": "integer"
+    },
+    "routes": {
+      "description": "Flight routes available for this deal",
+      "items": {
+        "properties": {
+          "destination": {
+            "description": "Destination airport code",
+            "type": "string"
+          },
+          "origin": {
+            "description": "Origin airport code",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "description": "Brief description of the deal",
+      "type": "string"
+    },
+    "title": {
+      "description": "Deal headline",
+      "type": "string"
+    },
+    "url": {
+      "description": "URL to view and book the deal",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedlist_top_deals_from1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "deals": {
+      "items": {
+        "properties": {
+          "currency": {
+            "description": "Currency code (always AUD)",
+            "type": "string"
+          },
+          "deal_id": {
+            "description": "Unique deal identifier",
+            "type": "integer"
+          },
+          "expiry_date": {
+            "description": "Deal expiry date (YYYY-MM-DD)",
+            "type": "string"
+          },
+          "from_price": {
+            "description": "Starting price in AUD",
+            "type": "integer"
+          },
+          "summary": {
+            "description": "Brief description of the deal",
+            "type": "string"
+          },
+          "title": {
+            "description": "Deal headline",
+            "type": "string"
+          },
+          "url": {
+            "description": "URL to view and book the deal",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "description": "Optional message about the results",
+      "type": "string"
+    },
+    "total": {
+      "description": "Number of deals returned",
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

Changedsearch_deals1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "deals": {
+      "items": {
+        "properties": {
+          "currency": {
+            "description": "Currency code (always AUD)",
+            "type": "string"
+          },
+          "deal_id": {
+            "description": "Unique deal identifier",
+            "type": "integer"
+          },
+          "expiry_date": {
+            "description": "Deal expiry date (YYYY-MM-DD)",
+            "type": "string"
+          },
+          "from_price": {
+            "description": "Starting price in AUD",
+            "type": "integer"
+          },
+          "summary": {
+            "description": "Brief description of the deal",
+            "type": "string"
+          },
+          "title": {
+            "description": "Deal headline",
+            "type": "string"
+          },
+          "url": {
+            "description": "URL to view and book the deal",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "description": "Optional message about the results",
+      "type": "string"
+    },
+    "total": {
+      "description": "Number of deals returned",
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

3 tool updatesMay 29, 2026
- First observedget_deal
- First observedlist_top_deals_from
- First observedsearch_deals

Related MCP Connectors

Flaut.Travel A
travel.flaut
Flight search, airfare analytics, flexible destinations
Travel & Transportation
81
sunnyspoints A
io.github.swarnavspujari
Live flight deals plus points-vs-cash math: transfer partners, valuations, per-leg verdicts.
Travel & Transportation Finance
91
Flightcat A
io.flightcat
Search flights by flexible dates and broad destinations, with live prices and booking links.
Travel & Transportation Search
11
stopover-planner A
com.stopovercity
Live Google Flights search: stopover itineraries, country sweeps, explore anywhere, booking links
Travel & Transportation Search
52

Related MCP Servers

Apify Google Flights Deals API
Travel & Transportation Web Scraping
johnisanerd
F
license
Not graded
quality
B
maintenance
Enables finding the cheapest flight destinations from an airport as structured JSON, with bargain detection via typical price comparisons and booking links.
Updated 4 days ago (2026-09-24 18:08 UTC)
-
google-flights-mcp
Travel & Transportation
mtnrabi
A
license
A
quality
B
maintenance
Enables real-time flight fare searches across date ranges and multiple destinations, with historical price insights and booking links. Provides one-way and round-trip search tools through MCP.
Updated 2 days ago (2026-09-26 11:24 UTC)
4
1
MIT
Gondola AI
Finance Search Travel & Transportation
gondola-ai
A
license
A
quality
A
maintenance
Travel award search: compare cash vs points on hotels, flights & cars, cents-per-point, and book
Updated 12 days ago (2026-09-16 13:19 UTC)
31
9
MIT
MoltTravel
Travel & Transportation Search
navifare
F
license
Not graded
quality
D
maintenance
Search flights, compare prices, check visas, look up airports, get travel advisories through a single endpoint.
Updated 14 days ago (2026-09-14 09:21 UTC)
-

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

Need Help?