Summary
Resolving the place is its own call, which is what keeps a forecast from quietly answering about the wrong city.
lookupCity accepts a name, an ID or coordinates and hands back a city ID the weather tools take, so the ambiguity lives in one place rather than in every request. The horizons are fixed rather than requested: getHourlyWeather covers the next 24 hours and getWeatherForecast the next few days, with each call taking a location and an options object. What comes back from getWeather is temperature, humidity and conditions — enough for a decision, not enough for a chart.
What it is
A weather server exposing 4 tools: current conditions, a daily forecast, an hourly forecast covering the next 24 hours, and a city lookup that returns the ID the weather calls accept.
What you get
- Conditions as they stand: getWeather returns temperature, humidity and conditions for a location.
- Forecast horizons on separate calls: getWeatherForecast covers the next few days, getHourlyWeather returns data hour by hour for the next 24 hours.
- Location resolved once and reused: lookupCity takes a name, an ID or coordinates and returns a city ID that the weather calls accept, so an ambiguous place name is settled before any forecast is read.
Requirements
No credentials are configured; a call needs a location, or a city ID obtained from lookupCity.