OpenWeather for agents over MCP

What it is

https://mcp.openweathermap.org/mcp is OpenWeather's MCP server. It presents the platform's two public APIs — accounts, keys and credits on agents.openweathermap.org, the weather feeds on data.openweathermap.org — as six tools any host that speaks the Model Context Protocol can call: Claude Code, Cursor, VS Code, Windsurf, Gemini CLI, Codex, the OpenAI Responses API, LangChain, AWS AgentCore, and the connector settings of claude.ai and ChatGPT.

The server adds nothing the HTTP API does not have. It removes the reading. An agent that spends seven calls over HTTP — the quickstart, the Terms, the product list, the signup, then the data — spends four through the tools: list, inspect, sign up, fetch. On the live server, the two model families we test with needed about half the turns they need over HTTP (measured 2026-09-02).

It is stateless and keeps no secret of its own: every tool call becomes the same public HTTPS request any agent could already make, with the caller's key forwarded, and the answer is the platform's own bytes with the HTTP status and the platform's own headers beside them. No tool pays. A human pays on the payment provider's page, from a link the agent fetches. The payment page and the receipt are in The Bot Forum's name: OpenWeather for agents is operated and sold by Extreme Electronics Ltd, trading as The Bot Forum, a company under common ownership with OpenWeather.

Add it to your host

One entry is all any client needs — the endpoint, and one header once you have a data key:

{ "url": "https://mcp.openweathermap.org/mcp", "headers": { "Authorization": "Bearer <your data key>" } }

Streamable HTTP, plain JSON answers, no session, nothing to connect with. The stored header is the data key — it serves fetch_data. The secret that runs the account stays with the owner, never in the server entry, and rides the two account tools as an argument. Leave the header out and the three keyless tools still work; an agent can sign up through the server and use the two strings it receives in the same session (see The two strings, below).

Per client, verbatim:

claude mcp add --transport http forum https://mcp.openweathermap.org/mcp --header "Authorization: Bearer <data key>"

{"mcpServers": {"forum": {"type": "http", "url": "https://mcp.openweathermap.org/mcp", "headers": {"Authorization": "Bearer ${FORUM_KEY}"}}}}

{"mcpServers": {"forum": {"url": "https://mcp.openweathermap.org/mcp", "headers": {"Authorization": "Bearer <data key>"}}}}

{"inputs": [{"type": "promptString", "id": "forum-key", "description": "OpenWeather for agents data key", "password": true}], "servers": {"forum": {"type": "http", "url": "https://mcp.openweathermap.org/mcp", "headers": {"Authorization": "Bearer ${input:forum-key}"}}}}

{"mcpServers": {"forum": {"httpUrl": "https://mcp.openweathermap.org/mcp", "headers": {"Authorization": "Bearer <data key>"}}}}

[mcp_servers.forum]
url = "https://mcp.openweathermap.org/mcp"
bearer_token_env_var = "FORUM_KEY"

{"type": "mcp", "server_label": "forum", "server_url": "https://mcp.openweathermap.org/mcp", "headers": {"Authorization": "Bearer <data key>"}, "require_approval": "never"}

{"mcpServers": {"forum": {"command": "npx", "args": ["mcp-remote", "https://mcp.openweathermap.org/mcp", "--transport", "http-only", "--header", "Authorization:${AUTH_HEADER}"], "env": {"AUTH_HEADER": "Bearer <data key>"}}}}

The six tools

Every answer has one shape: the HTTP status, the platform's own body, the request_id, the upstream call that was made, and the headers that matter (x-request-id and the rate-limit trio — no header reports a cost or a balance, and none ever did on this server's own account; account_status is where the balance is read). A wall — 401, 402, 403, 404, 400, 429 — comes back the same way, with the platform's code, message and next_action inside, and the tool result flagged as an error so the host shows it. The server never rewrites an answer, never retries, never invents an error of its own.

The two strings

sign_up returns two strings, both minted by the platform and shown once — the same two the HTTP API uses. The data key (bf_live_…) fetches data and can do nothing else. The secret (bfa_…) runs the account — balance, payment pages, keys — and fetches nothing. The wrong string on a tool comes back as the platform's own 403 wrong_credential, naming the right one. Each reaches the server one of two ways:

1. The header — Authorization: Bearer <data key> in the host's configuration. The usual way for data; the owner stores it once, and it serves fetch_data.
2. The argument — data_key on fetch_data, secret on account_status and get_topup_link. For the session an agent signs up in: most hosts read a new header only when they reconnect, so the strings sign_up just returned can ride the tools as arguments until the owner stores the data key. The secret is meant to stay an argument: keep it with the owner, out of the server entry.

When both are present the argument wins. A tool called with no string at all relays the platform's own 401 invalid_key. Never put either string in a URL, and never paste them into a chat you do not control: replacing the secret and revoking a key are the owner's, in the console or with the secret, and the tools stop with them like any other client.

The loop, in one session

1. list_products — the feeds and their prices.
2. get_product onecall — the routes and the parameters they need.
3. sign_up with a fresh email — 201, the secret and the data key. The account itself is granted nothing: One Call (onecall) gives every account 1,000 credits a day, replaced each night, and they pay for One Call alone — every API of it, 4.0's and 3.0's.
4. fetch_data onecall / current for a place, with data_key — 200 and the data, paid from that day's One Call credits; onecall / forecast, One Call 3.0's full answer, is paid from the same credits.
5. account_status with secret — the credits the account bought, any time. It is the only place that balance is: no data answer carries one.
6. When the day's One Call credits are spent, an account that has bought nothing is served nowhere, and fetch_data answers 401 invalid_key with action_url, the account page. get_topup_link returns the payment page for a human, the agent hands both over, and the same key serves again within about seven minutes of the payment — and One Call's own credits come back at midnight UTC whether or not anyone paid.

A stock host walked this loop in six calls on 2026-09-02, with no wrong call and no retry.

What it costs

The same as over HTTP: 1 credit = $0.001, each feed's price in credits is in list_products and on the data catalogue, and account_status reports the credits the account bought whenever you ask. One Call (onecall) gives every account 1,000 credits a day, replaced each night — whatever is unspent at midnight UTC is discarded, and the new day starts at 1,000 again. No card, no verification, no human step. Other feeds are paid from the first call: those credits pay for One Call — its 4.0 and 3.0 APIs alike — and nothing else, and list_products carries each product's daily credit account beside its price. Signing up grants nothing on top — the credits the account itself holds are zero until someone buys some. Nothing is served on credit: with no credits of either kind the wall rises. A top-up is at least $10 (10,000 credits), paid by a person on the provider's page. The payment page and the receipt are in The Bot Forum's name: OpenWeather for agents is operated and sold by Extreme Electronics Ltd, trading as The Bot Forum, a company under common ownership with OpenWeather. Every key is a live credential; a key reaches only the products its account can pay for right now.

Facts for machines

• Endpoint: POST https://mcp.openweathermap.org/mcp — streamable HTTP, JSON answers (send Accept: application/json), no session. Protocol revisions served: 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28. GET /mcp answers 405 to a client and sends a browser to the root.
• Server card: https://mcp.openweathermap.org/mcp/server-card (also at /.well-known/mcp/server-card.json). Health: https://mcp.openweathermap.org/healthz. This description at the server's root: https://mcp.openweathermap.org/ — markdown to a machine, a page to a browser; the markdown always at https://mcp.openweathermap.org/index.md.
• Registry name: org.openweathermap/agents.
• Not served, by design: OAuth (no 401 of its own, no WWW-Authenticate), event streams, sessions, resources, prompts.
• What the tools wrap: the platform contract https://agents.openweathermap.org/openapi.json, the data routes at https://agents.openweathermap.org/v1/products, the Terms at https://agents.openweathermap.org/tos, the error dictionary at https://agents.openweathermap.org/errors.json, the full walkthrough at https://agents.openweathermap.org/guide.

What it never does

No state, no key storage, no payment, no operator functions, and no back door: the server has no address for anything internal. It is a public client of the public API — the same walls, the same Terms, the same prices — placed where agents' hosts already look.