Service: https://flights.flightpowers.com/mcp Registry name: com.flightpowers/google-flights Effective date: 2026-10-22 Contact: app@flightpowers.com
This policy describes exactly what the hosted MCP server at flights.flightpowers.com does with data. It is written from the server's source, not from a template. Where the server collects nothing, this policy says nothing is collected rather than reserving a right we do not use.
A hosted Model Context Protocol (MCP) server exposing these tools:
search_oneway_flightssearch_roundtrip_flightsBoth accept a date range and a list of destinations, expand them internally into individual searches (30 per call by default, rising automatically to as many as 300 when the request itself is larger -- a whole month of departures at three trip lengths is 93, and the same month across three destinations is 279; a per-call max_searches argument sets the figure explicitly, up or down, and 300 is the hard ceiling), and forward each search to the Google Flights Live API on RapidAPI. Every search is one request billed to the caller's own RapidAPI plan, and a call whose remaining allowance cannot cover the request is refused rather than run in part. Search results are returned to the caller in the tool response and are not retained.
Non-affiliation. This is an independent service that returns publicly available flight pricing. It is not affiliated with, endorsed by, or sponsored by Google.
Every search on this server is billed to the caller's own RapidAPI subscription. The key is supplied per request, and this is what happens to it:
x-rapidapi-key request header(preferred), an authorization: Bearer or x-api-key header, a query parameter on the connector URL (rapidapi_key, rapidapi-key, rapidapikey, api_key, apikey, or key), a Smithery-style config. parameter or base64 config= blob, or, last, and normally unset, a RAPIDAPI_KEY value in the server's own environment.
request and sent to RapidAPI as the x-rapidapi-key header on each upstream search request that the call makes.
in an error message, never returned in a tool response, and never cached or reused for a later request. A key supplied on a request is held in memory for that request and then discarded; it is not stored.
the optional /connect page (section 2a), the key you paste there is stored, encrypted, so that later requests can use it without you pasting it again. A server that never sees you use /connect stores nothing about you.
literal values recorded are strings such as header:x-rapidapi-key, query:rapidapi_key, env:RAPIDAPI_KEY, or none. This field exists so that "users cannot work out how to pass a key" is distinguishable from "users are not trying". It contains no part of the key value.
If a key is absent, the server returns instructions instead of running a search, and spends nothing.
/connect pageSome deployments of this server offer a page at /connect. It is optional in two senses: not every deployment has it (/health reports connect_enabled, and where it is off the page does not exist), and where it does exist, using it is your choice, every other way of passing a key keeps working untouched.
If you use it:
nothing else: openid and email. It does not ask for, and cannot see, your Google Drive, Calendar, contacts, documents, profile picture or anything else in your account.
sub)and your email address. Nothing else. The email is kept so you can see which account a key is attached to; it is not added to any mailing list by this server.
under a key held in the server's environment and never in the database. The stored record holds the ciphertext, the last four characters of the key (the only readable fragment, so the page can show you which key is connected), your account identifier and your email address. Anyone holding a copy of the database and not the encryption key holds nothing usable.
gives you carries a revocable fpk_… token. It cannot be turned back into your RapidAPI key, and on its own it authorises nothing: it resolves to the stored record, and if that record is gone it resolves to nothing.
carries the sign-in round trip to Google; one carries your signed-in session for up to an hour. Both are HttpOnly and scoped to /connect, neither is sent with an MCP request, and neither is used for analytics, advertising or tracking of any kind. There are no third-party cookies anywhere on this service.
/connect deletes thestored record, the ciphertext included, not a flag set on a row that keeps it, and every connect token for that account stops resolving immediately. Your RapidAPI account and subscription are untouched; only our copy of the key is removed.
/mcp/oauth)Where /connect is available, so is a second MCP endpoint at /mcp/oauth (/health reports oauth_enabled). Instead of pasting a URL with a token in it, your MCP client signs you in itself: it registers with this server, opens a browser, and you approve that client by name.
It uses exactly the same Google sign-in and the same encrypted key record that section 2a describes. There is no second identity and no second copy of your key. What is additionally written down is only what makes the sign-in work:
back to, and an identifier we generated for it. No personal data.
ten minutes, usable once), an access token (one hour) and a refresh token (thirty days), each stored as a one-way hash (the database never holds a value that could be replayed), alongside your Google account identifier and the client that was approved.
It never receives your RapidAPI key, and there is nothing else these tokens authorise.
/connect deletes yourstored key *and* drops every access and refresh token issued for your account, in the same action. A client can also revoke its own token at /oauth/revoke. Expired codes and tokens are deleted; nothing about a finished sign-in is kept for analytics.
Where /health reports trial_enabled: true, a person who signs in with Google (section 2a or 2b) and has connected no RapidAPI key can still run a small number of searches each UTC day (trial_day_cap on /health). Those searches run on FlightPowers' own RapidAPI key, not yours. To count them, this is written down:
(sub), your email address, the date, how many searches you ran that day, and when the row was first and last updated.
question about your account. Nothing else: it is not a mailing list and it is not shared outside FlightPowers. The daily count is shared with FlightPowers' other paid server, so one sign-in has one allowance across both.
"Disconnect" on /connect does not delete them (Disconnect deletes your stored key and your tokens, sections 2a and 2b). To have them deleted, write to the contact address below.
One JSON line per tool call (never one per upstream request) is written to the server's standard output, prefixed MCP_CALL . It contains exactly these fields and nothing else:
| Field | Meaning |
|---|---|
ts, iso | Time of the call (epoch seconds and UTC timestamp) |
tool | one of search_oneway_flights or search_roundtrip_flights |
requested_combinations | How many date/destination combinations the call asked for (a number) |
upstream_calls | How many RapidAPI requests the call actually made |
upstream_failures | How many of those failed |
results_returned | How many results were returned (a number) |
duration_ms | How long the call took |
truncated | Whether the fan-out cap trimmed the search |
credential_source | Which mechanism supplied the key (see section 2) |
error | An error label such as no_api_key, auth or quota; a validation message when the request was rejected before any search ran; otherwise null. A validation message quotes the value that failed validation, an unparseable date or trip length, for example |
If the deployment is configured with a writable log path, the same line is also appended to a local file. On the current hosting platform that path is not writable, so standard output is the record.
If you signed in (sections 2a-2c), a few further lines carry your Google account identifier (sub), never your email address and never a key: one when a client is approved for your account, one when a key is stored or your tokens are revoked, and, on the daily allowance, a [paid_trial] line per search call with the tool name and your day's counters.
Our search backend keeps its own short-lived logs. Every search is run by a backend we operate on Amazon Web Services, behind the Google Flights Live API. Its operational log lines can hold the search itself (route, dates, passenger counts and filters) and the RapidAPI username of the key that paid for it; for a search on the daily allowance (section 2c) that is FlightPowers' own account, not yours. These logs are kept for about one day and are used to find failures and to count traffic. Before they expire, they are rolled up into totals in our own metrics database that carry no username.
Aggregate integer counters are incremented per call: tool_calls, upstream_calls, upstream_failures, results_returned, truncated_calls, errored_calls, unauthenticated_calls, plus per-UTC-hour totals of tool_calls and upstream_calls.
These are plain numbers with no per-caller dimension: there is no key, no identifier, and no way to attribute a counter to anyone. By default they live in process memory and reset when the process recycles. If an Upstash Redis store is configured, they are stored there as integers under the key prefix gfpaid; hourly buckets expire automatically after 35 days, and lifetime totals are running integers.
The server does not collect, log, store, or transmit any of the following:
appears in any record it writes, and none is sent upstream. (The hosting platform terminates the network connection and keeps its own request logs, see section 6.)
/connect or through/mcp/oauth: the tool path itself has no account, no user ID, no session ID, no name, no email address and no device or client identifier (our search backend's own logs, section 3, do see the RapidAPI username of the key that paid for a search). If you did sign in, sections 2a-2c and section 3 describe every place your Google account identifier or email address is kept. It exists only because you chose to sign in; Disconnect deletes your key and tokens, and the daily counts in section 2c are deleted on request.
to perform the search and are then discarded by this server. Only the *count* of requested combinations is recorded here, not the values, with one exception: when a request is rejected as invalid before any search runs, the validation message goes into the error field described in section 3, and that message quotes the single value that failed (a malformed date or trip length, for example). Our search backend's own short-lived logs are described in section 3.
This server serves no ads and embeds no third-party tracking of any kind. The MCP endpoint sets no cookies at all. The only cookies that exist anywhere on this service are the two functional, first-party, HttpOnly ones described in section 2a, and they only exist if you use /connect.
There is no profiling, no automated decision-making, and no sale or sharing of personal data.
with your key, billed to your own subscription, or, on the daily allowance (section 2c), with FlightPowers' own key. RapidAPI and the API provider handle that request under their own terms and privacy policies.
backend we operate, reached through RapidAPI; its logs are described in section 3. Amazon Web Services hosts it as our processor.
in a Neon Postgres database.
Google's own consent screen; Google handles that under its own privacy policy. The service asks for openid and email and receives nothing else. If you never sign in, this service never contacts Google about you.
integer counters described in section 4.
standard-output lines described in section 3 as runtime logs and retains them under its own log retention. Like any internet host, the platform also terminates the network connection and may keep its own request-level logs under its own policy; that layer is the platform's, not this server's, and this server neither reads nor uses it.
No other processor receives anything.
GET /health: public and unauthenticated. Returns service status, thepublic MCP URL, the signup URL, whether ads are served (always false), whether a server-side fallback key is configured, and whether the daily sign-in allowance is on and its size (trial_enabled, trial_day_cap). It contains no caller data.
GET /metrics and GET /metrics/calls: the aggregate counters fromsection 4, protected by a x-metrics-token header when a token is configured. They contain no caller data.
GET /.well-known/openai-apps-challenge: a domain-verification token, or404 when unconfigured.
/connect: retained, encrypted, until you pressDisconnect. There is no expiry sweep: the record lasts as long as you want it to and no longer.
same lifetime as the key, and deleted with it.
by Disconnect; deleted on request to the contact address below.
counts rolled up from them have no automatic expiry today; write to the contact address below to have the counts under your account deleted.
MCP_CALL log lines: retained by the hosting platform under its runtime logretention. They contain no personal data. The sign-in and allowance lines in section 3 carry a Google account identifier and are kept under the same platform retention.
integers with no personal dimension.
If you have never signed in, this server keeps no record keyed to you; the only trace is the RapidAPI username of your key in our search backend's one-day logs, and in the daily counts rolled up from them where section 3 says those counts are kept per account. If you have, "Disconnect" on /connect deletes your stored key and tokens at once, and a request to the contact address below deletes the daily allowance counts in section 2c. Either way, if you believe a record about you exists that this policy does not describe, write to the contact address below and we will investigate.
The service is a developer API tool and is not directed to children.
Material changes to this policy will be published at this URL with an updated effective date. The version in force is the one published here.
app@flightpowers.com