Skip to main content
Glama
626,069 tools. Updated 2026-10-01 08:25

"A server for checking weather forecasts" matching MCP tools:

  • Retrieves comprehensive weather data including current conditions, hourly, and daily forecasts. **Specific Data Available:** Temperature (Current, Feels Like, Max/Min, Heat Index), Wind (Speed, Gusts, Direction), Celestial Events (Sunrise/Sunset, Moon Phase), Precipitation (Type, Probability, Quantity/QPF), Atmospheric Conditions (UV Index, Humidity, Cloud Cover, Thunderstorm Probability), and Geocoded Location Address. **Location & Location Rules (CRITICAL):** The location for which weather data is requested is specified using the `location` field. This field is a 'oneof' structure, meaning you MUST provide a value for ONLY ONE of the three location sub-fields below to ensure an accurate weather data lookup. 1. Geographic Coordinates (lat_lng) * Use it when you are provided with exact lat/lng coordinates. * Example: {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} // Los Angeles 2. Place ID (place_id) * An unambiguous string identifier (Google Maps Place ID). * The place_id can be fetched from the search_places tool. * Example: {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} // Eiffel Tower 3. Address String (address) * A free-form string that requires specificity for geocoding. * City & Region: Always include region/country (e.g., "London, UK", not "London"). * Street Address: Provide the full address (e.g., "1600 Pennsylvania Ave NW, Washington, DC"). * Postal/Zip Codes: MUST be accompanied by a country name (e.g., "90210, USA", NOT "90210"). * Example: {"location": {"address": "1600 Pennsylvania Ave NW, Washington, DC"}} **Usage Modes:** * **Current Weather:** Provide `location` only. Do not specify `date` and `hour`. * **Hourly Forecast:** Provide `location`, `date`, and `hour` (0-23). Use for specific times (e.g., "at 5 PM") or terms like "next few hours" or "later today". If the user specifies minute, round down to the nearest hour. Hourly forecast beyond 120 hours from now is not supported. Historical hourly weather is supported up to 24 hours in the past. * **Daily Forecast:** Provide `location` and `date`. Do not specify `hour`. Use for general day requests (e.g., "weather for tomorrow", "weather on Friday", "weather on 12/25"). If today's date is not in the context, you should clarify it with the user. Daily forecast beyond 10 days including today is not supported. Historical weather is not supported. **Parameter Constraints:** * **Timezones:** All `date` and `hour` inputs must be relative to the **location's local time zone**, not the user's time zone. * **Date Format:** Inputs must be separated into `{year, month, day}` integers. * **Units:** Defaults to `METRIC`. Set `units_system` to `IMPERIAL` for Fahrenheit/Miles if the user implies US standards or explicitly requests it. * The grounded output must be attributed to the source using the information from the `attribution` field when available.
    ConnectorNo auth
  • Retrieves comprehensive weather data including current conditions, hourly, and daily forecasts. **Specific Data Available:** Temperature (Current, Feels Like, Max/Min, Heat Index), Wind (Speed, Gusts, Direction), Celestial Events (Sunrise/Sunset, Moon Phase), Precipitation (Type, Probability, Quantity/QPF), Atmospheric Conditions (UV Index, Humidity, Cloud Cover, Thunderstorm Probability), and Geocoded Location Address. **Location & Location Rules (CRITICAL):** The location for which weather data is requested is specified using the `location` field. This field is a 'oneof' structure, meaning you MUST provide a value for ONLY ONE of the three location sub-fields below to ensure an accurate weather data lookup. 1. Geographic Coordinates (lat_lng) * Use it when you are provided with exact lat/lng coordinates. * Example: {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} // Los Angeles 2. Place ID (place_id) * An unambiguous string identifier (Google Maps Place ID). * The place_id can be fetched from the search_places tool. * Example: {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} // Eiffel Tower 3. Address String (address) * A free-form string that requires specificity for geocoding. * City & Region: Always include region/country (e.g., "London, UK", not "London"). * Street Address: Provide the full address (e.g., "1600 Pennsylvania Ave NW, Washington, DC"). * Postal/Zip Codes: MUST be accompanied by a country name (e.g., "90210, USA", NOT "90210"). * Example: {"location": {"address": "1600 Pennsylvania Ave NW, Washington, DC"}} **Usage Modes:** * **Current Weather:** Provide `location` only. Do not specify `date` and `hour`. * **Hourly Forecast:** Provide `location`, `date`, and `hour` (0-23). Use for specific times (e.g., "at 5 PM") or terms like "next few hours" or "later today". If the user specifies minute, round down to the nearest hour. Hourly forecast beyond 120 hours from now is not supported. Historical hourly weather is supported up to 24 hours in the past. * **Daily Forecast:** Provide `location` and `date`. Do not specify `hour`. Use for general day requests (e.g., "weather for tomorrow", "weather on Friday", "weather on 12/25"). If today's date is not in the context, you should clarify it with the user. Daily forecast beyond 10 days including today is not supported. Historical weather is not supported. **Parameter Constraints:** * **Timezones:** All `date` and `hour` inputs must be relative to the **location's local time zone**, not the user's time zone. * **Date Format:** Inputs must be separated into `{year, month, day}` integers. * **Units:** Defaults to `METRIC`. Set `units_system` to `IMPERIAL` for Fahrenheit/Miles if the user implies US standards or explicitly requests it. * The grounded output must be attributed to the source using the information from the `attribution` field when available.
    ConnectorNo auth
  • Forecast Track Record — Silicon Analysts' OWN projections, frozen monthly into write-once vintages and graded against outcomes. Every row: model, scenario (bear/base/bull), series, target period, the predicted mid + low–high band frozen at vintage time, and once the period matures, the realized value with a correct/partial/incorrect resolution and error %. Vintages cannot be backfilled or edited — a changed projection that was never frozen is gone, which is what makes this a track record. USE THIS for: checking how Silicon Analysts' HBM/DDR4/CoWoS projections have scored, citing our prediction accuracy, comparing what we projected for a period across successive vintage months, auditing the frozen assumption set behind a projection (include_assumptions=true). DO NOT USE for: third-party forecasts (TrendForce/WSTS/company guidance — use get_forecasts; ours are graded, theirs are archived); current market values (use get_wafer_pricing / get_hbm_market_data). Filters: model (hbm-pricing-model|dram-ddr4-model|cowos-capacity-model), series (e.g. hbm3e), include_assumptions (bool). Fully public at full fidelity for every tier including anonymous — the scorecard is deliberately ungated. Cite as "Silicon Analysts — Forecast Track Record".
    ConnectorNo auth
  • No arguments. Returns how many MCP servers have been read at source level, and the share of them with each category of finding (credential access, network egress, install-time execution, prompt-injection surface). Use this to judge whether checking a specific server is worth it before you look one up. It reports aggregate counts only - no per-server findings, and no verdict about any individual server.
    ConnectorNo auth
  • Get a multi-day weather forecast for any Swiss location. Returns daily summaries (temperature, precipitation, sunshine, wind, weather icon) plus a hierarchical hourly breakdown of every series. This uses official MeteoSwiss Open Data — the same forecasts powering the MeteoSwiss app and website. Accepts: - Postal codes: "8001" (Zurich), "3000" (Bern), "1200" (Geneva) - Station abbreviations: "SMA" (Zurich Fluntern), "BER" (Bern) - Place names: "Zurich", "Basel", "Lugano" Coverage: ~6000 Swiss locations (all postal codes + weather stations + mountain points). Forecast horizon: up to 9 days. Updated hourly. Each day's summary fields: temperature_min_c, temperature_max_c, precipitation_total_mm, sunshine_total_minutes, wind_avg_kmh, wind_gust_max_kmh, weather, weather_icon_url. Each day also includes "hourly": one array of per-hour objects covering every series together — { time, temperature_c, precip_mm, sunshine_minutes, wind_kmh, wind_gust_kmh } — useful for judging *when* rain, sun, or wind is expected, not just the daily summary: - Each entry's "time" is already local wall-clock time for the location (Europe/Zurich), with the UTC offset included, e.g. "2026-07-09T14:00:00+02:00". It is NOT UTC — do not convert it. - A dry/calm/sunless hour is reported as its measured value (often 0), not omitted. A fully dry day is still a full array of zero-precipitation hours, not an empty array. - Each field is independently null if just THAT series has no reading for a given hour — the other fields for that same hour are still populated. An hour is omitted entirely only when every series is missing for it. - "hourly" itself is null when no hourly breakdown exists for this location at all (a total data gap); [] only when this location supports hourly data but none was available for that specific day. - For weather stations, temperature_min_c/temperature_max_c/precipitation_total_mm are MeteoSwiss's own official daily aggregates — a different, separately-curated product from the hourly series shown alongside them. They can legitimately NOT match summing/ averaging the hourly entries for that day; this is expected, not a data error. sunshine_total_minutes/wind_avg_kmh/wind_gust_max_kmh have no official daily product for stations and are always derived from the hourly series. For postal codes/mountain points, every summary field is derived from the same hourly series shown alongside it, so it always matches summing/averaging that series exactly.
    ConnectorNo auth
  • Use this when you have VaR or Expected-Shortfall forecasts and need to know whether reality breached them more often or deeper than your claimed tail level allows -- a risk-forecast audit, not buy/sell advice. Does your risk model's VaR/ES forecast survive contact with reality? Exceedance backtest over YOUR forecasts -- a new claim type: risk numbers, not return claims. Submit realised per-period returns plus the VaR forecasts your model produced ex ante (positive loss thresholds at tail level alpha, e.g. 0.05 for a 95% VaR), optionally the matching expected-shortfall forecasts. The breach count is graded on the EXACT binomial Basel traffic-light zones (Basel Committee 1996: green below cumulative probability 0.95, yellow to 0.9999, red above) -- published boundaries, no house thresholds; red earns the named demote VAR_BREACH_RATE_EXCESS. Kupiec's proportion-of-failures LR (1995) and Christoffersen's independence LR (1998) ride along -- clustered breaches flag the advisory var_breaches_clustered (a model blind to volatility clustering). If ES forecasts are supplied, a joint (VaR, ES) mixture e-process (e-backtesting, Wang & Ziegel) grades breach DEPTH: crossing Ville's anytime-valid 1% line earns ES_TAIL_UNDERSTATED. Supply benchmark_var_forecasts (and optionally benchmark_es_forecasts, e.g. a rolling historical quantile) and the assay also tests EQUAL PREDICTIVE ABILITY: Diebold-Mariano (1995) on a strictly consistent loss (quantile tick, or the joint FZ0 loss of Fissler & Ziegel 2016 when both sides carry ES) -- a naive benchmark that beats your model past the one-sided 5% line earns RISK_FORECAST_DOMINATED_BY_BENCHMARK; the attention zone to 10% is the advisory risk_forecast_lags_benchmark. Demote-only: too many breaches can kill, too few is the mis-calibration advisory var_breach_rate_sparse -- conservative models pass with a flag, never a blessing. Code-computed end to end, fail-closed on malformed or undersized input (a series too short to reach the red zone answers insufficient_evidence instead of a hollow pass). Works for any asset class. NOT financial advice; no order path. Price: per check; see https://api.alphaassay.com/v1/meta/pricing (api_key required -- account setup at https://api.alphaassay.com/account).
    Connector
    Destructive
    No auth

Matching MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables agents to search US federal agency procurement forecasts — what agencies intend to buy months or years before a solicitation exists — filtering by keyword, agency, NAICS, set-aside, fiscal year, and value band, and to pull full detail records with narrative, period of performance, and contacts. Coverage is reported honestly per agency, so results distinguish "nothing planned" from "never checked".
    138 npm
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables querying and comparing operational numerical weather models, including global and regional, deterministic and ensemble, physics-based and AI forecasts, with a unified API.
    48 npm
    MIT

Matching MCP Connectors

  • US federal agency procurement FORECASTS — what an agency says it intends to

  • US weather for AI agents: active NWS alerts by state, 5-period forecasts by lat/lon. Paid per call.

  • Daily board of forecasted wagers from Lumify's model — a prediction, not a beat-the-market claim (no OOS/independence gate; see list_ev for the gated main-line +EV claim). Player props (rate model) on MLB, NCAAF, NFL, NBA, NCAAB, NHL. High-confidence main-line picks on tennis, NFL, NCAAF, MLB, and soccer: one side per moneyline / spread / total when the uncertainty band does not include a coin flip. Tennis moneyline is ranking Bradley-Terry; tennis spreads/totals are a Normal-approx games model. Other sports use the published assessment probability. Each wager has p_hit, conviction, and posted books prices. Use list_ev to scan main lines by sharp-fair price gap; use this tool to scan high-probability forecasts. reliability is emerging on v0. 1 credit; empty slate is still 200. How + field catalog: https://lumify.ai/docs/forecasts Worked wager: https://lumify.ai/docs/understanding-odds#forecasts
    ConnectorAPI key
  • Real-time web search via Tavily for current events, fact-checking, and research. Use search_depth='advanced' for complex queries (higher quality, higher cost) and topic='news' or 'finance' for headlines or market information. Use when: Choose when the task needs current, external, or factual information not available from on-chain or local data — e.g. news, prices, documentation, or fact-checking. Limitations: Returns web snippets, not raw page bodies; results depend on Tavily coverage. Advanced depth costs more. Not a substitute for on-chain tools like get_token_price. Alternatives: get_token_price, http_fetch
    ConnectorNo auth
  • Live JMA river flood forecasts and landslide alerts affecting a station's prefecture — NOT general weather warnings. Ask by station name in Japanese (新宿) or romaji (Shinjuku). Prefecture-level match (station master is Greater Tokyo). Relay of official JMA facts.
    ConnectorNo auth
  • Get a 14-day weather forecast for a campsite or location. Use this when the user asks about weather, temperature, rain, wind, or UV conditions at a campsite or destination. You can provide EITHER: - campsite_name: The name (or partial name) of a campsite to look up its GPS coordinates automatically, OR - latitude + longitude: Direct coordinates if already known Returns daily forecasts with max/min temperature, rain chance, precipitation amount, wind speed, UV index, and a weather description for each day.
    ConnectorNo auth
  • Check whether a handle is available on unu.lu (not other platforms like Instagram, TikTok, etc.). For example, checking 'joe' tells you if joe.unu.lu is available for claiming. Use this to help users choose a handle before they visit the claim page.
    ConnectorNo auth
  • Live JMA river flood forecasts and landslide alerts affecting a station's prefecture — NOT general weather warnings. Ask by station name in Japanese (新宿) or romaji (Shinjuku). Prefecture-level match (station master is Greater Tokyo). Relay of official JMA facts.
    ConnectorNo auth
  • Live barrier status, the next-30-minute closure timeline and approaching trains for ONE crossing, as markdown. Forecasts are rebuilt per request from the live train feeds, so the answer changes minute to minute. Informational only — never a substitute for the signals and barriers at the crossing itself. An ambiguous name returns the candidate URL words to choose between; an unknown one asks you to call list_crossings first.
    ConnectorNo auth
  • Call this when the user asks which indicators currently sit in an unusual band, whether a metric's current level historically preceded BTC moves, or for a cross-metric conditional overview. Returns every recorded metric in its historical band with the median 7-day BTC move that followed versus the base rate, with an n >= 30 gate; distributions, not forecasts.
    ConnectorNo auth
  • Return the exact TestGraph MCP server version and live deployment identity for diagnostics. Use this when checking a stale connection, endpoint mismatch or deployment issue; ordinary writes do not require a preceding version probe. Compare build_sha and deployment_id with the public /version endpoint when troubleshooting.
    ConnectorNo auth
  • Return the exact TestGraph MCP server version and live deployment identity for diagnostics. Use this when checking a stale connection, endpoint mismatch or deployment issue; ordinary writes do not require a preceding version probe. Compare build_sha and deployment_id with the public /version endpoint when troubleshooting.
    ConnectorNo auth
  • Complete weather overview for a location: current conditions, daily forecast (day/night periods, SPC threats, severity, CAPE, UV), active alerts, and convective outlooks in one call. Data is pre-aggregated across NBM, HRRR, GFS, RTMA, and SPC and unit-converted server-side. This is the primary weather tool; reach for lower-level tools only when you need raw observations or a specific dataset. Accepts a place name directly. Examples: {"location": "Denver"} or {"location": "Portland, OR", "days": 5} or {"lat": 41.4, "lon": -92.9}.
    ConnectorNo auth
  • Returns the Smarter Weather developer sign-up URL (with MCP referral attribution). Present the URL so the user can create a free account in a browser (Clerk, no credit card). After they finish, reconnect this MCP server with OAuth and call create_api_key, then configure_mcp. No authentication required.
    ConnectorNo auth
  • Returns a small set of passages from Fiveable study guides that are most relevant to one question. Use this for narrow explanations, research questions, and checking student notes instead of fetching a full guide. One call consumes one full-content preview for a free caller.
    ConnectorNo auth
  • Trigger a FRESH SNMP walk against a device. Wraps POST /api/getSNMPWalkInfo/{deviceId} (permission: tools). SLOW and SIDE-EFFECTING. Server-side this shells out to walktool with a 1200s (20 minute) timeout and writes the result into the tools_walks table. Always try snmp_walk_last first; only call this when the cached walk is missing or known to be stale. MCP tool timeout is 1200s to match the server-side cap. If the device has many OIDs the call will take real wall-clock time — let it run; do not retry on timeout without first checking snmp_walk_last (the writeback may have completed even if the HTTP response stalled). Example: snmp_walk_run({device_id: 42})
    ConnectorNo auth