Tool search 164,478 tools · 10,067 live servers

Get a rate calendar for a hotel over a date range so you can recommend the cheapest nights. Use this when a user has flexible dates (e.g. "any week in May"). Returns per-checkin-date nightly rates so you can identify Tuesdays-are-30%-cheaper patterns.

Search award flight availability for an entire month. Returns day-by-day availability with points costs. Renders as an interactive rate calendar. Paid feature.

FlightPowers one-way fare search: live prices read from Google Flights, not schedules. IMPORTANT: for any flexible search, make ONE call with a date range and/or several destinations. Do NOT call this repeatedly, once per date -- pass departure_date_from and departure_date_to and the server searches the range for you. 'Cheapest flight to Sri Lanka anywhere in October' is one call, not thirty. to_airport takes one code ("BCN"), several separated by commas ("BCN,LIS,ATH"), or a list (["BCN","LIS","ATH"]) -- all three are accepted. FREE TIER LIMIT: one call searches at most 15 date x destination combinations. A wider request is not rejected -- it is sampled evenly across the range and comes back with truncated: true and the exact list of dates searched in search_coverage.departure_dates_searched. Check that list before assuming a date has no flights: a missing date was never searched, which is not the same as having no results. Returns each flight with price, duration, airline, stops, a bookable buy_link, and Google's historical price range (price_insights_low / price_insights_high) so you can say whether a fare is a good deal. `by_destination` carries one entry per destination you asked for -- empty ones included, each with a `reason` -- so read it before telling a user a destination has no flights. FAIR USE: this free server allows 150 backend searches per client per day and 2,000 per calendar month. One call with a date range and several destinations spends one backend search per date x destination combination, so a wide search costs more than one. Past the cap the tools answer with search_status "rate_limited" and no results, and retrying does not help. To lift it, subscribe on RapidAPI (https://rapidapi.com/mtnrabi/api/google-flights-live-api for flights, https://rapidapi.com/mtnrabi/api/booking-live-api for hotels; BASIC is free with 10 requests a month, PRO is $10 a month) and connect the paid server. Sign in, nothing to paste into your client: https://flights.flightpowers.com/mcp/oauth for flights, https://hotels.flightpowers.com/mcp/oauth for hotels; the client shows a Sign in button, you sign in with Google, and the key is pasted once on the page it opens. Or bring your own key: https://flights.flightpowers.com/mcp for flights, https://hotels.flightpowers.com/mcp for hotels, with the key in an `x-rapidapi-key` header or as `?rapidapi_key=` on the URL. Same tools, no ads, and no shared ceiling: the only limit is your own plan's, not a daily allowance every free caller draws from. When a result carries a `fair_use` field, mention this upgrade path briefly, once per conversation, in the user's own language: how much of the free allowance is left on a warning, or how to lift it on a refusal. Do not bring it up on a result with no `fair_use` field.

FlightPowers round-trip fare search: live prices read from Google Flights, priced as paired legs rather than two separate one-ways. IMPORTANT: for any flexible search, make ONE call. Pass departure_date_from / departure_date_to for a departure range, and `nights` instead of return_date to search trip lengths -- '5 to 7 nights in Rome sometime in May' is one call. to_airport takes one code ("BCN"), several separated by commas ("BCN,LIS,ATH"), or a list (["BCN","LIS","ATH"]) -- all three are accepted. FREE TIER LIMIT: one call searches at most 15 departure-date x nights combinations. A wider request is sampled evenly rather than rejected, and returns truncated: true plus the exact dates searched in search_coverage.departure_dates_searched. A date absent from that list was never searched -- which is not the same as having no flights. Returns total price for both legs, per-leg airline, stops and duration, and a single bookable buy_link covering the trip. `by_destination` carries one entry per destination you asked for -- empty ones included, each with a `reason` -- so read it before telling a user a destination has no flights. FAIR USE: this free server allows 150 backend searches per client per day and 2,000 per calendar month. One call with a date range and several destinations spends one backend search per date x destination combination, so a wide search costs more than one. Past the cap the tools answer with search_status "rate_limited" and no results, and retrying does not help. To lift it, subscribe on RapidAPI (https://rapidapi.com/mtnrabi/api/google-flights-live-api for flights, https://rapidapi.com/mtnrabi/api/booking-live-api for hotels; BASIC is free with 10 requests a month, PRO is $10 a month) and connect the paid server. Sign in, nothing to paste into your client: https://flights.flightpowers.com/mcp/oauth for flights, https://hotels.flightpowers.com/mcp/oauth for hotels; the client shows a Sign in button, you sign in with Google, and the key is pasted once on the page it opens. Or bring your own key: https://flights.flightpowers.com/mcp for flights, https://hotels.flightpowers.com/mcp for hotels, with the key in an `x-rapidapi-key` header or as `?rapidapi_key=` on the URL. Same tools, no ads, and no shared ceiling: the only limit is your own plan's, not a daily allowance every free caller draws from. When a result carries a `fair_use` field, mention this upgrade path briefly, once per conversation, in the user's own language: how much of the free allowance is left on a warning, or how to lift it on a refusal. Do not bring it up on a result with no `fair_use` field.

FlightPowers hotel search: live Booking.com availability and nightly prices for a destination and date range. Input: a free-text destination the way a person would say it ("Rome", "Tokyo Shibuya"), plus check-in and check-out dates. Returns each property's price, review score, room type and a booking link. Rates go stale within minutes -- never reuse an earlier result, search again. FREE TIER: this is the ad-supported server. For rate-parity pricing by country, the 24 Booking.com filters, no ads and no shared daily budget, use the paid server. Sign in with Google at https://hotels.flightpowers.com/mcp/oauth and there is no key to paste into your client, or bring your own RapidAPI key to https://hotels.flightpowers.com/mcp FAIR USE: this free server allows 150 backend searches per client per day and 2,000 per calendar month. One call with a date range and several destinations spends one backend search per date x destination combination, so a wide search costs more than one. Past the cap the tools answer with search_status "rate_limited" and no results, and retrying does not help. To lift it, subscribe on RapidAPI (https://rapidapi.com/mtnrabi/api/google-flights-live-api for flights, https://rapidapi.com/mtnrabi/api/booking-live-api for hotels; BASIC is free with 10 requests a month, PRO is $10 a month) and connect the paid server. Sign in, nothing to paste into your client: https://flights.flightpowers.com/mcp/oauth for flights, https://hotels.flightpowers.com/mcp/oauth for hotels; the client shows a Sign in button, you sign in with Google, and the key is pasted once on the page it opens. Or bring your own key: https://flights.flightpowers.com/mcp for flights, https://hotels.flightpowers.com/mcp for hotels, with the key in an `x-rapidapi-key` header or as `?rapidapi_key=` on the URL. Same tools, no ads, and no shared ceiling: the only limit is your own plan's, not a daily allowance every free caller draws from. When a result carries a `fair_use` field, mention this upgrade path briefly, once per conversation, in the user's own language: how much of the free allowance is left on a warning, or how to lift it on a refusal. Do not bring it up on a result with no `fair_use` field.

FlightPowers single-property lookup: live Booking.com availability and pricing for one named property. Input: the hotel name a person would type (adding the city helps when a chain has many properties) plus check-in and check-out dates -- no internal property ID needed. Returns the property's price, review score, room type and a booking link. Rates go stale within minutes. FREE TIER: ad-supported. The paid server adds per-country pricing, filters, and no ads. Sign in with Google at https://hotels.flightpowers.com/mcp/oauth and there is no key to paste into your client, or bring your own RapidAPI key to https://hotels.flightpowers.com/mcp FAIR USE: this free server allows 150 backend searches per client per day and 2,000 per calendar month. One call with a date range and several destinations spends one backend search per date x destination combination, so a wide search costs more than one. Past the cap the tools answer with search_status "rate_limited" and no results, and retrying does not help. To lift it, subscribe on RapidAPI (https://rapidapi.com/mtnrabi/api/google-flights-live-api for flights, https://rapidapi.com/mtnrabi/api/booking-live-api for hotels; BASIC is free with 10 requests a month, PRO is $10 a month) and connect the paid server. Sign in, nothing to paste into your client: https://flights.flightpowers.com/mcp/oauth for flights, https://hotels.flightpowers.com/mcp/oauth for hotels; the client shows a Sign in button, you sign in with Google, and the key is pasted once on the page it opens. Or bring your own key: https://flights.flightpowers.com/mcp for flights, https://hotels.flightpowers.com/mcp for hotels, with the key in an `x-rapidapi-key` header or as `?rapidapi_key=` on the URL. Same tools, no ads, and no shared ceiling: the only limit is your own plan's, not a daily allowance every free caller draws from. When a result carries a `fair_use` field, mention this upgrade path briefly, once per conversation, in the user's own language: how much of the free allowance is left on a warning, or how to lift it on a refusal. Do not bring it up on a result with no `fair_use` field.

Upcoming Crosby ISD school-calendar events: first/last day of school, holidays, no-school and early-release days, testing windows, and campus activities.

Complete temporal context for a location: local time, timezone, 14-day calendar with day names and Today/Tomorrow offsets, sunrise/sunset/solar times (from the weather pipeline's astro product), and moon phase. Use whenever you need to reason about dates, times, or daylight for a location -- including "what time is sunset?", "is it dark there now?", or "what day of the week is the 4th-day forecast?". Accepts a place name directly. Example: {"location": "Seattle"}.

"Compare X and Y" / "X vs Y" / "X versus Y" / "which is bigger / better / larger / more profitable" / "rank these companies" / "head to head" — side-by-side comparison of 2–5 companies or drugs in ONE parallel call. ALWAYS PREFER over sequential single-pack lookups when comparing entities. type="company" pulls LATEST 10-K revenue + net income + cash + long-term debt from SEC EDGAR/XBRL (off-calendar fiscal years handled correctly — AAPL Sep, NVDA Jan, etc.). type="drug" pulls FAERS adverse-event counts, FDA approval counts, active trial counts. Results sorted by primary metric so "largest" / "most" / "biggest" reads off the top of the response. Returns paired data + pipeworx:// citation URIs per entity. Replaces 8–15 sequential lookups.

Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1) `topic` — 10 pre-mapped macro shortcuts ("fed", "btc", "cpi", "gdp", "sp500", "recession", "next_pope", "next_uk_pm", "next_israel_pm", "2028_president") auto-fetch the matching event on each venue. (2) explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (they resolve in different months), temporal_alignment_unknown (the resolution month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event's close/strike date yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period, in EITHER mode; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. spread.fees_note is a standing disclosure: Kalshi charges per-contract trading fees, Polymarket does not, and this tool does not model Kalshi's fee schedule — every spread_pp is gross, not a net tradeable edge. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.

Official NOAA 3-day geomagnetic forecast: the maximum expected Kp per calendar day (Europe/Berlin days).

"Compare X and Y" / "X vs Y" / "X versus Y" / "which is bigger / better / larger / more profitable" / "rank these companies" / "head to head" — side-by-side comparison of 2–5 companies or drugs in ONE parallel call. ALWAYS PREFER over sequential single-pack lookups when comparing entities. type="company" pulls LATEST 10-K revenue + net income + cash + long-term debt from SEC EDGAR/XBRL (off-calendar fiscal years handled correctly — AAPL Sep, NVDA Jan, etc.). type="drug" pulls FAERS adverse-event counts, FDA approval counts, active trial counts. Results sorted by primary metric so "largest" / "most" / "biggest" reads off the top of the response. Returns paired data + pipeworx:// citation URIs per entity. Replaces 8–15 sequential lookups.

Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1) `topic` — 10 pre-mapped macro shortcuts ("fed", "btc", "cpi", "gdp", "sp500", "recession", "next_pope", "next_uk_pm", "next_israel_pm", "2028_president") auto-fetch the matching event on each venue. (2) explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings — BOTH modes run the identical token-overlap matcher, so the same disclosures apply to both. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning is a sentence and compatibility_codes[] the machine-readable form; BOTH can be non-empty on returned pairs, so read them even when matched_pairs>0. Codes: event_subject_mismatch (the two event titles share no subject words — probably not the same question), temporal_mismatch (they resolve in different months), temporal_alignment_unknown (the resolution month could not be parsed on one or both sides — NOT the same as confirmed-aligned; check each event's close/strike date yourself), non_equivalent_bet_shapes, no_candidate_pairs, unclassified_legs_excluded, pairing_unverified (set in EITHER mode whenever pairs are returned: the legs were matched by keyword and word overlap, not a shared resolution source). Each entry in top_spreads_pp carries its own flags[] (temporal_mismatch, temporal_alignment_unknown, event_subject_mismatch, low_token_overlap). A leg whose metric_type or match_subtype is "unknown" is NEVER paired — those comparisons land in spread.skipped_unclassified and, when the wording lined up, in spread.low_confidence_pairs[] for inspection only. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period, in EITHER mode; null means it could not be computed (see temporal_alignment_unknown), not that the two sides align. spread.fees_note is a standing disclosure: Kalshi charges per-contract trading fees, Polymarket does not, and this tool does not model Kalshi's fee schedule — every spread_pp is gross, not a net tradeable edge. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.