# Polymarket Weather Resolution Checker (METAR / NOAA) (`bigdavidson/polymarket-weather-resolution`) Actor

Check how a Polymarket daily-temperature market will resolve before it does. Per bracket: the running high/low at the rules' station from METAR, YES/NO locked or final, market price, confidence and a plain-English reason. Pay per bracket. METAR proxy, not the official reading.

- **URL**: https://apify.com/bigdavidson/polymarket-weather-resolution.md
- **Developed by:** [Jack Sheward](https://apify.com/bigdavidson) (community)
- **Categories:** Developer tools, Agents, AI
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $2.00 / 1,000 bracket resolution checks

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## Polymarket Weather Resolution Checker (METAR / NOAA)

**Check how a Polymarket daily-temperature market will resolve before it does.**

Give it a Polymarket "Highest / Lowest temperature in <city> on <date>?" event or bracket (URL or slug), or just cities and a date. For every bracket it reads **the station named in that market's own rules**, pulls that station's METAR/SPECI reports for the **station-local day**, and returns one row per bracket:

- the **running high or low so far** (in the market's unit and whole degrees), with report count and last report time;
- whether the bracket is already decided: `YES_LOCKED`, `NO_LOCKED`, `UNDECIDED`, and `FINAL_YES` / `FINAL_NO` once the local day is over;
- the **current market price** and implied probability, a **confidence grade**, and a one-sentence plain-English reason.

No login, no API key, no browser. It uses Polymarket's public market-data API and aviationweather.gov. The default run (three cities, daily high) takes a few seconds.

> **This is a proxy, not the official reading.** Polymarket resolves on a named weather-station page, not on METAR. The observed value here is derived from the same station's METAR/SPECI reports and can differ from the official one by about a degree (rounding, a missing or late report, a non-METAR reading). Every row says so, and the confidence grade accounts for it. See [How accurate is it?](#how-accurate-is-it)

### How Polymarket's temperature markets resolve

Read from the live rules text of all 229 open events on 2026-09-30 (each row repeats what its own market says):

- The winning bracket is the one containing the **day's highest (or lowest) temperature reading at one named station**, in **whole degrees** (°F for US cities, °C elsewhere), for the **station-local calendar day**.
- **Source.** For 48 of 51 cities the rules name NOAA's `weather.gov/wrh/timeseries?site=<ICAO>` page (the "Temp" column; the hourly data for US °F cities). **Weather Underground** (the station's history / daily observations table) is the documented **fallback** if NOAA has no data by 11:59 PM ET the next day, and the **primary** source for Taipei and Jinan. **Hong Kong** resolves on the Hong Kong Observatory's "Absolute Daily Max/Min" to 0.1 °C.
- The market resolves once the first data point for the next date is published (or by 11:59 PM ET the day after). With no data at all it resolves to the lowest bracket. Later revisions are not considered.
- Brackets are 2 °F wide for US cities (`66-67°F`, plus `65°F or below` / `84°F or higher`) and 1 °C wide elsewhere (`20°C`, plus `15°C or below` / `26°C or higher`).

Weather Underground is in this actor's title because the rules name it as the fallback source (and as the primary one for Taipei and Jinan); for most cities the page that decides is NOAA's.

`resolution_source`, `resolution_source_url` and `fallback_source` on every row come from the market's rules text, and `station_icao` is cross-checked against this actor's own station table. If they disagree you get a free `station_mismatch` notice, the rules' station is used, and the rows are graded `low`.

### What you get

One dataset. `record_type` is the first field.

| `record_type` | One row per | Billed |
|---|---|---|
| `resolution_check` | bracket market with real METAR evidence | `resolution-check` |
| `notice` | explanation: bad input, not a weather market, no market for that date, unsupported city, no observations, station mismatch... | **free** |

#### Key `resolution_check` fields

| Field | Example | Notes |
|---|---|---|
| `event_slug`, `market_slug`, `market_url`, `question`, `bracket_label` | `highest-temperature-in-nyc-on-september-29-2026`, `70-71°F` | `bracket_low` / `bracket_high` are the inclusive whole-degree bounds (`null` = open end) |
| `city`, `event_date`, `metric`, `unit` | `NYC`, `2026-09-29`, `high`, `F` | `event_date` is the **station-local** date |
| `station_icao`, `station_name`, `station_check` | `KLGA`, `LaGuardia Airport Station`, `match` | station parsed from the rules; `match` / `mismatch` / `unlisted` vs this actor's table |
| `resolution_source`, `resolution_source_url`, `fallback_source` | `NOAA`, `https://www.weather.gov/wrh/timeseries?site=klga`, `Wunderground` | straight from the rules text |
| `observed_value`, `observed_value_c`, `extreme_reports`, `observed_at_utc` | `70`, `21.1`, `4`, `2026-09-29T16:51:00Z` | running max (high markets) or min (low markets) so far, in the market's whole-degree unit; how many reports show that value; when it was first reached |
| `obs_count`, `first_obs_utc`, `last_obs_utc`, `max_obs_gap_minutes` | `25`, ..., `60.0` | METAR + SPECI reports inside the station-local day; longest hole between reports |
| `day_complete`, `timezone` | `true`, `America/New_York` | the local day is over **and** a next-day report is in the feed (or 2 h have passed) |
| `bracket_status` | `FINAL_YES` | see below |
| `confidence`, `confidence_reasons` | `medium`, `["within_1_degree_of_bracket_edge"]` | see below |
| `market_status`, `polymarket_result`, `proxy_matches_polymarket` | `resolved`, `yes`, `true` | for already-resolved markets: Polymarket's actual result and whether our verdict agrees |
| `yes_price`, `no_price`, `implied_probability`, `best_bid`, `best_ask`, `last_trade_price`, `price_flag`, `price_as_of` | `0.66`, `0.34`, `0.66`, ... | Gamma `outcomePrices` (cached up to ~5 min). On thin books the displayed price can be a midpoint, so `price_flag` says `ok` / `wide_spread` / `no_bid` / `no_book` / `resolved` |
| `explanation` | see below | one sentence, always carries the proxy caveat |

#### `bracket_status`

| Status | Meaning |
|---|---|
| `NO_LOCKED` | The bracket can no longer win. HIGH market: the max so far is already above the bracket's top (a daily high cannot fall). LOW market: the min so far is already below the bracket's bottom (a daily low cannot rise). |
| `YES_LOCKED` | An open-ended bracket that can no longer lose: a high already inside "X or higher", or a low already inside "X or below". |
| `UNDECIDED` | Could still go either way before the station-local day ends. |
| `FINAL_YES` / `FINAL_NO` | The station-local day is complete: the bracket does / does not contain the observed extreme. |

A bracket in the middle (say `70-71°F` with a high of 70 so far) stays `UNDECIDED` until the day is complete: the high could still rise out of it.

#### `confidence`

The grade says how safely the verdict survives a proxy error of about a degree.

| Grade | When |
|---|---|
| `high` | decided (locked or final), clean data, and 3+ whole degrees from the bracket's nearest edge |
| `medium` | 2 degrees from an edge; or within 1 degree of an edge on a **completed** day with a corroborated extreme (the winning 1-2 degree bracket is always within 1 degree of its own edge, so a correct `FINAL_YES` is never better than `medium`); or the verdict would flip if the single most extreme report were missing; or the next-day report has not been seen yet |
| `low` | `UNDECIDED` (day incomplete); within 1 degree of an edge while the day is still running; within 1 degree and the extreme rests on a single report; a gap of more than 150 minutes between reports; fewer than 4 reports on a finished day; stale reports (no report for 3 h on a running day); or a station mismatch |

`confidence_reasons` lists every trigger, e.g. `["day_incomplete_bracket_undecided", "within_2_degrees_of_bracket_edge"]`.

### Example output (real rows)

A finished, already-resolved day (NYC high, 2026-09-29). Polymarket's winner was `70-71°F`; our verdict matches:

```json
{
  "record_type": "resolution_check",
  "event_slug": "highest-temperature-in-nyc-on-september-29-2026",
  "market_slug": "highest-temperature-in-nyc-on-september-29-2026-70-71f",
  "bracket_label": "70-71°F", "bracket_low": 70, "bracket_high": 71,
  "city": "NYC", "event_date": "2026-09-29", "metric": "high", "unit": "F",
  "station_icao": "KLGA", "station_name": "LaGuardia Airport Station", "station_check": "match",
  "resolution_source": "NOAA", "resolution_source_url": "https://www.weather.gov/wrh/timeseries?site=klga",
  "fallback_source": "Wunderground",
  "observed_value": 70, "observed_value_c": 21.1, "extreme_reports": 4, "observed_at_utc": "2026-09-29T16:51:00Z",
  "obs_count": 25, "first_obs_utc": "2026-09-29T04:51:00Z", "last_obs_utc": "2026-09-30T03:51:00Z",
  "max_obs_gap_minutes": 60.0, "timezone": "America/New_York", "day_complete": true,
  "bracket_status": "FINAL_YES", "confidence": "medium", "confidence_reasons": ["within_1_degree_of_bracket_edge"],
  "market_status": "resolved", "polymarket_result": "yes", "proxy_matches_polymarket": true,
  "yes_price": 1.0, "no_price": 0.0, "implied_probability": 1.0, "price_flag": "resolved",
  "explanation": "The station-local day is complete and the observed high at KLGA was 70°F, inside the \"70-71°F\" bracket, so it resolves YES on the METAR proxy - within 1 degree of the bracket edge, so the official reading could land on the other side; Polymarket has resolved this bracket YES (METAR proxy, the official source can differ by about 1 degree).",
  "observation_source": "aviationweather.gov METAR/SPECI", "checked_at": "2026-10-01T02:36:10Z"
}
```

A day still running (London high, 2026-10-01, 03:35 local, 7 reports so far, highest 19 °C):

| `bracket_label` | `bracket_status` | `confidence` | `yes_price` | `explanation` (shortened) |
|---|---|---|---|---|
| `16°C or below` | `NO_LOCKED` | `high` | 0.0005 | NO is locked in: the high so far is 19°C, already above the bracket's top, and a daily high cannot fall |
| `18°C` | `NO_LOCKED` | `low` | 0.0005 | ...already above the bracket (top 18°C)... within 1 degree of the bracket edge |
| `19°C` | `UNDECIDED` | `low` | 0.0265 | Undecided: the high so far is 19°C, inside the bracket, the day is still running, so it could still rise out of it |
| `21°C` | `UNDECIDED` | `low` | 0.66 | Undecided: the high so far is 19°C, outside the bracket, so it could still rise into it |

Bad input comes back as free rows, for example `{"record_type": "notice", "notice_code": "not_weather_market", "message": "\"ballon-dor-winner-2026\" is a Polymarket event (\"Ballon d'Or Winner 2026\") but not a daily highest/lowest temperature market, so there is no weather resolution to check. Nothing was charged."}`.

### How the check works

1. Fetch the event from Polymarket (Gamma API): its rules text, brackets and current prices.
2. Parse the **station** (ICAO) and unit from the rules; cross-check the station against the built-in table of the 51 current cities (49 return evidence rows; Hong Kong and Jinan return a free notice, see Input).
3. Take the **station-local calendar day** (midnight to midnight local clock time, DST-aware) and fetch the station's METAR **and SPECI** reports for it from aviationweather.gov (history for about 30 days).
4. Running extreme = max (high markets) or min (low markets) of the day's reports. US stations: the METAR T-group tenths of °C converted to °F and rounded half-up to a whole °F (`floor(°C × 1.8 + 32 + 0.5)`, the value NOAA shows). Other stations: the reported whole °C.
5. Status per bracket (table above), confidence grade, explanation.

Reports outside the local day are ignored (a 23:51 report of the evening before and the 00:00 report of the next day are both excluded). Nothing is ever estimated: with no reports there is no evidence row, only a free notice.

### How accurate is it?

Measured on resolved markets: the bracket our `FINAL_YES` names versus the bracket Polymarket actually resolved YES.

- **The actor itself, resolved days 2026-09-29 and 2026-09-30, every city with a market, high and low: 188 of 188 events matched** (49 cities; all 2,068 bracket rows agree with Polymarket's result, `proxy_matches_polymarket = true`).
- **Backtest, 2026-09-08 to 09-30, 2,197 resolved events at 49 stations** (same logic, replayed offline): **2,185 matched (99.45%)**. That is 483 of 484 for °F stations and 1,702 of 1,713 for °C stations, and 2,095 of 2,099 (99.8%) if the one bad day (2026-09-20) is left out. The station-local **clock** day (DST-aware) beat the NWS-style local-standard-time day (2,185 vs 2,134 matches), and counting SPECI reports beat routine METARs only (2,185 vs 2,178).
- **The 12 misses, all investigated.** None was rounding, a wrong station or the day boundary. 8 fell on 2026-09-20, when 5 Asian daily highs and 3 European / Middle-East daily lows differed from every report we had for roughly 03:20-07:00 UTC (the official page appears to have been missing those reports). 3 were Manila (RPLL) lows where one evening or SPECI report that we count was not in the official data. 1 was San Francisco on 2026-09-21, where the official low sat below every METAR/SPECI (a non-METAR reading). 7 of the 12 had an extreme resting on a single report.
- **The grade is calibrated against that backtest** (accuracy of our `FINAL_YES` verdict, by the grade the row gets):

| `FINAL_YES` graded | Events | Matched Polymarket |
|---|---|---|
| `high` | 7 | 100% |
| `medium` | 1,613 | 99.7% |
| `low` | 577 | 98.8% |

So: right about 99.5% of the time on completed days, and the grade separates the verdicts that are more likely to flip. It is not a guarantee, and it is not the official value. The 44 of 188 verdicts graded `low` in the live check above were all correct too; `low` means "less safe", not "wrong".

### Known limitations

- **Proxy, not source.** The official page can lack reports METAR has (late or dropped reports, as on 2026-09-20) and can contain a reading METAR does not (one San Francisco low in the backtest). Either moves the extreme by a degree or more, which is what the grade and `extreme_reports` are for.
- **Hong Kong** (Hong Kong Observatory daily extract, 0.1 °C) and **Jinan** (no METAR feed) return free notices.
- **History is about 30 days** (the aviationweather.gov archive). Older days return a free notice that names the bracket Polymarket resolved.
- **Prices are Polymarket's displayed prices** (up to about 5 minutes old, midpoints on thin books).
- **At most 40 events per run**; new Polymarket cities need a table update.

### Input

Every field is optional, but an empty input returns a free note (nothing is run).

| Field | Type | Default | What it does |
|---|---|---|---|
| `markets` | list of strings | `[]` | Polymarket event or bracket URLs or slugs (up to 50). Event = all brackets, bracket = just that one. |
| `cities` | list of strings | `[]` (form prefill: NYC, Chicago, London) | City names as Polymarket titles them, aliases (New York, LA, SF, CDMX), the station (KLGA) or `"Chicago low"`. |
| `date` | string | `today` | Station-local date for `cities`: `today`, `yesterday`, `tomorrow`, `-2d`, `+1d`, `2026-09-29`, `September 29`. Past days that have resolved work for ~30 days. |
| `metric` | `high` | `low` | `both` | `high` | Which market for `cities`. |

At most 40 events are checked per run. Both `markets` and `cities` are used when both are filled.

```json
{ "cities": ["NYC", "Chicago", "London"], "date": "today", "metric": "high" }
```

```json
{ "markets": ["https://polymarket.com/event/highest-temperature-in-nyc-on-september-30-2026"] }
```

```json
{ "cities": ["Tokyo", "Paris"], "date": "yesterday", "metric": "both" }
```

Supported cities: NYC, Chicago, Denver, Dallas, Atlanta, Miami, Austin, Houston, Seattle, Los Angeles, San Francisco, Toronto, Mexico City, Panama City, Sao Paulo, Buenos Aires, London, Paris, Amsterdam, Munich, Milan, Madrid, Warsaw, Helsinki, Moscow, Ankara, Istanbul, Tel Aviv, Jeddah, Karachi, Lucknow, Cape Town, Singapore, Kuala Lumpur, Manila, Beijing, Shanghai, Qingdao, Jinan, Zhengzhou, Wuhan, Chengdu, Chongqing, Guangzhou, Shenzhen, Taipei, Seoul (Incheon), Busan, Tokyo, Wellington. **Hong Kong** is recognised but returns a free notice (it resolves on the Hong Kong Observatory's 0.1 °C reading, which is not a METAR value). **Jinan** has no METAR feed on aviationweather.gov, so it returns a free notice too. New Polymarket cities need a table update (they come back as a free notice).

### Pricing

Pay per event. You only pay for rows you actually receive.

| Event | Price | When |
|---|---|---|
| `actor-start` | $0.005 | once per run, only when at least one bracket check is delivered |
| `resolution-check` | $0.002 | per bracket row backed by METAR evidence |
| notice rows | free | bad input, non-weather markets, no market for the date, unsupported city, no observations |

A run that returns only notices costs nothing, not even the start fee. If your maximum cost per run cannot cover the start plus one check, nothing is charged and you get a notice. When the budget runs out mid-run, the rows that fit are delivered and a free `charge_limit` notice says how many were not.

Typical bills: one city-day-metric event (11 brackets) is about $0.027; the default run (three cities, daily high, 33 brackets) is about $0.071. To spend less, check single brackets (a bracket URL is one row) or fewer cities.

### FAQ

**Does Polymarket resolve on Wunderground?** Mostly not, according to the rules text read on 2026-09-30. The rules of 48 of 51 cities name NOAA's weather.gov timeseries page, with Weather Underground as a fallback (and as the primary source for Taipei and Jinan). The actor tells you per market which one applies. METAR is the common ground: both pages are built from the station's METAR/SPECI reports.

**Why is every correct `FINAL_YES` only `medium`?** Because the winning bracket is only 1-2 whole degrees wide, so a one-degree difference between our METAR value and the official page would move the answer. `medium` means "clean data, corroborated extreme"; the 99.7% hit rate of `medium` verdicts in the backtest above is the empirical side of that.

**Which day does it use?** The station-local calendar day on the station's clock, including daylight saving (what the market rules say: "for all times on this day"). Kalshi's NWS climate day (local standard time) is a different convention, covered by the Kalshi checker below.

**What if the market already resolved?** You still get rows (billed like any other): our verdict next to `polymarket_result`, and `proxy_matches_polymarket` per bracket. That is also how you can audit the proxy yourself.

**What if the day is too old or hasn't started?** More than ~30 days back, or a day that has not started, comes back as a free notice (the former names the bracket Polymarket resolved). It never invents a value.

**Is the price a probability?** It is Polymarket's displayed price (`outcomePrices`), cached for up to about 5 minutes. On empty or one-sided books it can be a midpoint, which `price_flag` marks.

**Is this official or investment advice?** No. This is an unofficial tool, not affiliated with or endorsed by Polymarket, NOAA, Weather Underground or the Hong Kong Observatory. It reads Polymarket's public market-data API (no scraping of polymarket.com, no wallet data, no trading) and aviationweather.gov (US public domain). You are responsible for complying with Polymarket's Terms of Use. Nothing here is investment advice.

### For AI agents (Apify MCP server)

- **Inputs are forgiving**: lists or newline-separated strings, URLs or slugs, city aliases, `"Chicago low"`, dates like `yesterday`. Bad entries become free notice rows, never a failed run.
- **Rows are flat and self-describing**: `bracket_status` and `confidence` answer "is it decided, and how sure", and `explanation` is a ready-to-quote sentence.
- Useful questions: *"Which NYC high brackets are already dead?"* (`bracket_status = NO_LOCKED`), *"Has the Tokyo high already locked a YES?"* (`YES_LOCKED` / `FINAL_YES`), *"Did the proxy agree with Polymarket yesterday?"* (`date: yesterday`, `proxy_matches_polymarket`).

### Related actors

- [Polymarket Weather Markets API](https://apify.com/bigdavidson/polymarket-weather-markets): every daily temperature bracket (about 50 cities) with live order book, odds, settlement station and history. Use it to find markets; use this actor to check how one will resolve.
- [Prediction Market Resolution Evidence Checker](https://apify.com/bigdavidson/prediction-market-resolution-evidence): the Kalshi counterpart (KXHIGH / KXLOW series, NWS climate day, settled values). Note Kalshi and Polymarket use different stations in the same city (NYC: Central Park vs LaGuardia).
- [METAR & NWS Weather Station Observations API](https://apify.com/bigdavidson/metar-nws-weather-station-observations): raw and decoded METAR history for any station.

# Actor input Schema

## `markets` (type: `array`):

Daily highest/lowest temperature events or single brackets, up to 50. An event URL or slug checks all its brackets, e.g. https://polymarket.com/event/highest-temperature-in-nyc-on-september-30-2026 or highest-temperature-in-nyc-on-september-30-2026. A bracket URL or slug (.../highest-temperature-in-nyc-on-september-30-2026-70-71f) checks that one bracket. Entries that are not Polymarket daily-temperature markets come back as a free notice. Leave empty to use Cities below; if both are filled, both are checked.

## `cities` (type: `array`):

Check every bracket of each city's market for the Date below. Polymarket's own names (NYC, Chicago, London, Tokyo, Seoul, Sao Paulo, ...), common aliases (New York, LA, SF, Mexico City / CDMX) or the settlement station (KLGA, EGLC) work; add "low" for the daily low ("Chicago low"). About 50 cities; Hong Kong is listed but has no METAR proxy (a free notice explains). The form prefills three cities (about 33 bracket rows, 0.67 USD): clear them if you only want the URLs above.

## `date` (type: `string`):

Station-local calendar date of the markets to check: today (default; each city's own local date), yesterday, tomorrow, -2d / +1d, or a date such as 2026-09-29 or "September 29". Past days that have already resolved can be re-checked for about 30 days (the METAR archive limit): the row shows our verdict next to Polymarket's actual result. Not used for URLs, which carry their own date.

## `metric` (type: `string`):

high = the 'Highest temperature in <city>' market, low = the 'Lowest temperature in <city>' market, both = both (twice the rows).

## Actor input object example

```json
{
  "markets": [],
  "cities": [
    "NYC",
    "Chicago",
    "London"
  ],
  "date": "today",
  "metric": "high"
}
```

# Actor output Schema

## `results` (type: `string`):

No description

## `overview` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "cities": [
        "NYC",
        "Chicago",
        "London"
    ],
    "date": "today",
    "metric": "high"
};

// Run the Actor and wait for it to finish
const run = await client.actor("bigdavidson/polymarket-weather-resolution").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "cities": [
        "NYC",
        "Chicago",
        "London",
    ],
    "date": "today",
    "metric": "high",
}

# Run the Actor and wait for it to finish
run = client.actor("bigdavidson/polymarket-weather-resolution").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "cities": [
    "NYC",
    "Chicago",
    "London"
  ],
  "date": "today",
  "metric": "high"
}' |
apify call bigdavidson/polymarket-weather-resolution --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,bigdavidson/polymarket-weather-resolution"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/ihnpb1yu1c2320vje/builds/woZ3CsvDwcnv2YkeM/openapi.json