One forecast route beyond US borders

The National Weather Service publishes detailed forecasts for the United States and its territories. Give an agent coordinates in Paris, Nairobi, Tokyo, or São Paulo, though, and it needs another source.

Locale’s weather endpoint accepts any latitude and longitude covered by the global forecast grid. US requests can draw on NWS data. Open-Meteo supplies worldwide access, including ECMWF forecast models. The response keeps the same shape across locations, so an agent doesn’t need country-specific parsing rules.

weather is the short alias. weather-forecast is the canonical endpoint. Both cost $0.002 USDC per successful call on Base mainnet.

Geographic coverage

Here’s how requests map by location:

| Requested area | Coverage behavior | | --- | --- | | United States and territories | NWS coverage is blended with global forecast fields | | Europe, Africa, Asia, Australia, and South America | Open-Meteo provides worldwide forecast access, with ECMWF model data available through the blend | | Remote islands and ocean coordinates | Forecasts are returned where the global model grid has data | | Arctic and Antarctic coordinates | Requests are accepted, though model resolution and available observations vary near the poles |

Coordinates are the contract. A routing LLM doesn’t need to decide which weather service covers a country before making the call.

That matters for agents working across borders. A travel planner can use the same request format for Chicago and Osaka. A shipping agent can check conditions near a port by coordinate. And a field-service scheduler can request tomorrow’s precipitation probability without maintaining a country-to-provider table.

Pick the response depth

Send latitude and longitude on every request. units accepts metric or imperial. Set forecast_days from 1 through 7, then add hourly: true when the task needs time-specific conditions.

A small current-conditions request looks like this: 

POST /weather
Content-Type: application/json

{
  "latitude": 30.2672,
  "longitude": -97.7431,
  "units": "imperial",
  "forecast_days": 1,
  "hourly": false
}

The response includes location, current, daily, units, and source metadata. Current conditions cover temperature, apparent temperature, humidity, wind speed and direction, precipitation, the WMO weather code, and daylight state.

For a seven-day Tokyo forecast with hourly rows: 

POST /weather-forecast
Content-Type: application/json

{
  "latitude": 35.6762,
  "longitude": 139.6503,
  "units": "metric",
  "forecast_days": 7,
  "hourly": true
}

Daily rows include maximum and minimum temperature, precipitation totals and probability, sunrise and sunset, maximum UV index, plus the WMO weather code. Hourly output adds timestamps alongside temperature, precipitation, and condition codes.

Keep hourly off for a compact answer. Turn it on for departure windows, outdoor work scheduling, or “Will it rain at 18:00?” prompts.

Routing it from an agent

An x402 client makes the POST, receives payment terms with HTTP 402, authorizes the $0.002 USDC charge, and retries the request with its payment proof. The paid response can then pass straight into planning logic.

For a current-weather question, route to weather with one forecast day. Use weather-forecast when the user asks about a later date, an hourly window, sunrise, or UV exposure.

If the prompt starts with a place name, resolve it to coordinates first. Then send the latitude and longitude to weather, keeping the forecast call identical from Austin to Auckland.