The README's own comparison is the right guide: local is fast, private and needs no authentication, while remote adds OAuth and the scalability of Workers. Most people asking about tomorrow's rain want the local build. If you do go remote, expect token expiry to be the usual failure, with a script provided to refresh it.
An MCP server for Japanese weather built on the Japan Meteorological Agency's forecast API. Three tools split the forecast into the parts people actually ask for, and the same server ships in two shapes: a local stdio build and a remote Cloudflare Workers deployment with OAuth 2.0.
- The forecast overview for a city — announcement time, the summary text, and today, tomorrow and the day after — `get_weather_overview`
- Precipitation probability split into time bands across the day, for the same three days — `get_precipitation_probability`
- Wind direction and speed for those days — `get_wind_speed`
- Coverage across Japan's prefectural capitals, from Sapporo to Naha
- Two deployments from one codebase: `npm run build:local` for a local stdio server that needs no authentication, or the Workers build with OAuth for remote use
For the local server: Node with `npm install` and `npm run build:local`, then point the client at `dist/server/local/index.js`. Nothing to authorize on that path. For the remote server: a Cloudflare Workers deployment and an OAuth access token, obtained with the bundled `node src/utils/get-token.cjs` and refreshed with `node src/utils/update-token.cjs`, or supplied as `MCP_WEATHER_TOKEN`; the client then launches the remote client script. A debug client build is documented for when the remote path misbehaves.
One command — npx -y mcp-weather