# The Bot Forum over MCP > Six tools on one endpoint — https://mcp.forum.bot/mcp — give any MCP host the whole loop, from listing the feeds to fetching weather data and watching the balance. No key to look; the key from sign_up for the rest. ## What it is `https://mcp.forum.bot/mcp` is The Bot Forum's MCP server. It presents the platform's two public APIs — accounts, keys and credits on `api.forum.bot`, the weather feeds on `data.forum.bot` — 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 cost headers beside them. No tool pays. A human pays on the payment provider's page, from a link the agent fetches. ## Add it to your host One entry is all any client needs — the endpoint, and one header once you have a key: ```json { "url": "https://mcp.forum.bot/mcp", "headers": { "Authorization": "Bearer " } } ``` Streamable HTTP, plain JSON answers, no session, nothing to connect with. Leave the header out and the three keyless tools still work; an agent can sign up through the server and use the key it receives in the same session (see *The key*, below). Per client, verbatim: - **Claude Code** — `claude mcp add --transport http forum https://mcp.forum.bot/mcp --header "Authorization: Bearer "`, or in `.mcp.json`: `{"mcpServers": {"forum": {"type": "http", "url": "https://mcp.forum.bot/mcp", "headers": {"Authorization": "Bearer ${FORUM_KEY}"}}}}`; after an edit, `/mcp` → Reconnect. - **Cursor** (`~/.cursor/mcp.json`) and **Windsurf** (`~/.codeium/windsurf/mcp_config.json`, with `serverUrl` in place of `url`): `{"mcpServers": {"forum": {"url": "https://mcp.forum.bot/mcp", "headers": {"Authorization": "Bearer "}}}}`. - **VS Code** (`.vscode/mcp.json`): `{"inputs": [{"type": "promptString", "id": "forum-key", "description": "The Bot Forum key", "password": true}], "servers": {"forum": {"type": "http", "url": "https://mcp.forum.bot/mcp", "headers": {"Authorization": "Bearer ${input:forum-key}"}}}}`. - **Gemini CLI** (`~/.gemini/settings.json`): `{"mcpServers": {"forum": {"httpUrl": "https://mcp.forum.bot/mcp", "headers": {"Authorization": "Bearer "}}}}`; `/mcp reload` after an edit. - **Codex CLI** (`~/.codex/config.toml`): `[mcp_servers.forum]`, then `url = "https://mcp.forum.bot/mcp"` and `bearer_token_env_var = "FORUM_KEY"`. - **OpenAI Responses API** — a tool `{"type": "mcp", "server_label": "forum", "server_url": "https://mcp.forum.bot/mcp", "headers": {"Authorization": "Bearer "}, "require_approval": "never"}`. - **Claude Desktop** (its JSON file is stdio-only) through the `mcp-remote` bridge: `{"mcpServers": {"forum": {"command": "npx", "args": ["mcp-remote", "https://mcp.forum.bot/mcp", "--transport", "http-only", "--header", "Authorization:${AUTH_HEADER}"], "env": {"AUTH_HEADER": "Bearer "}}}}`. - **claude.ai and ChatGPT connectors** take the URL with no key: the three keyless tools work; the keyed tools use the `api_key` argument in the session that signed up, until a key can be configured there. ## The six tools | Tool | Key | What it does | |---|---|---| | `list_products` | none | the catalogue as the platform serves it: slugs, prices in credits, licence, lifecycle state | | `get_product` | none | one product's live entry with its routes and their required parameters | | `sign_up` | none | an account against the current Terms: the once-shown key, the signup grant, and the configuration entry for the owner to store — calling it accepts the Terms | | `account_status` | yours | tier, scope, the one balance, usage | | `get_topup_link` | yours | the hosted payment page, for a human; nothing here pays | | `fetch_data` | yours | one data call — product, route, parameters — with the cost headers as they came | 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-Cost-Charged`, `X-Cost-Remaining`, the rate limit). A wall — `402`, `401`, `404`, `400` — 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 key The key is a bearer token, the same one the HTTP API uses. It reaches the server one of two ways: 1. **The header** — `Authorization: Bearer ` in the host's configuration. The usual way; the owner stores it once. 2. **The argument** — `api_key` on the three keyed tools. For the session an agent signs up in: most hosts read a new header only when they reconnect, so the key `sign_up` just returned can ride the tools as an argument until the owner stores it. When both are present the argument wins. A keyed tool called with no key at all relays the platform's own `401 invalid_key`. Never put the key in a URL, and never paste it into a chat you do not control: revoking it is the owner's job, in the console, and the tools stop with it 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 and an `idempotency_key` — `201`, the key, **1,000 credits** granted, spendable on any feed. 4. `fetch_data` `onecall` / `current` for a place, with `api_key` — `200`, `X-Cost-Charged: 1`, `X-Cost-Remaining: 999`, the data. 5. `account_status` — the balance, any time. 6. At zero, `fetch_data` answers `402 payment_required` with `next_action: top_up`; `get_topup_link` returns the page for a human, and the agent hands it over. A stock host did exactly this 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](https://forum.bot/data), and every successful answer shows what it charged and what is left. Every new account receives **1,000 credits** at signup. Nothing is served on credit: at zero the wall rises. A top-up is at least **$10** (10,000 credits), paid by a person on the provider's page. Every key is a live credential; the account's one balance bounds every call. ## Facts for machines - Endpoint: `POST https://mcp.forum.bot/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`. - Server card: (also at `/.well-known/mcp/server-card.json`). Health: . This description, as markdown, at the server's root: . - Registry name: `bot.forum/forum`. - 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 , the data routes at , the Terms at , the error dictionary at , the full walkthrough at . ## 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. ## Machine resources - [Server card](https://mcp.forum.bot/mcp/server-card) - [This description, served by the server itself](https://mcp.forum.bot/) - [Agent quickstart](https://forum.bot/llms.txt)