# 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. Nothing to look up first — sign_up returns the two strings the rest use, the data key for data and the secret for the account.

## 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 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: Extreme Electronics Ltd, trading as The Bot Forum, is the seller of every credit.

## Add it to your host

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

```json
{ "url": "https://mcp.forum.bot/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 Code** — `claude mcp add --transport http forum https://mcp.forum.bot/mcp --header "Authorization: Bearer <data key>"`, 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 <data key>"}}}}`.
- **VS Code** (`.vscode/mcp.json`): `{"inputs": [{"type": "promptString", "id": "forum-key", "description": "The Bot Forum data 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 <data key>"}}}}`; `/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 <data key>"}, "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 <data key>"}}}}`.
- **claude.ai and ChatGPT connectors** take the URL with no key: the three keyless tools work; `fetch_data` uses the `data_key` argument and the two account tools the `secret` argument in the session that signed up, until a data key can be configured there.

## The six tools

| Tool | String | 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 secret and data key, and the configuration entry for the owner to store — calling it accepts the Terms; the email is its only argument. It grants the account no credits: the free calls belong to the products, and `list_products` says which product gives them |
| `account_status` | the secret | tier, scope, the credits the account bought, usage |
| `get_topup_link` | the secret | the hosted payment page, for a human; nothing here pays; asking again returns the open page |
| `fetch_data` | the data key | one data call — product, route, parameters — with the platform's 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-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 4.0 (`onecall`) gives every account **1,000 credits a day**,
   replaced each night, and they pay for One Call 4.0 alone.
4. `fetch_data` `onecall` / `current` for a place, with `data_key` — `200` and the data, paid
   from that day's One Call 4.0 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. `fetch_data` `onecall3` with the same key answers `402 payment_required` with `action_url`,
   the payment page: the key is known, and One Call 3.0 has no free credits to pay with. When
   the day's One Call 4.0 credits are spent too, 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 4.0'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](https://forum.bot/data), and `account_status` reports the
credits the account bought whenever you ask. One Call 4.0 (`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 4.0 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: Extreme Electronics Ltd, trading as The Bot Forum, is the seller of every credit. 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.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` to a client and sends a browser to the root.
- Server card: <https://mcp.forum.bot/mcp/server-card> (also at
  `/.well-known/mcp/server-card.json`). Health: <https://mcp.forum.bot/healthz>. This
  description at the server's root: <https://mcp.forum.bot/> — markdown to a machine, a page to a browser; the
  markdown always at <https://mcp.forum.bot/index.md>.
- 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 <https://api.forum.bot/openapi.json>, the data
  routes at <https://forum.bot/data>, the Terms at <https://forum.bot/tos/last.json>, the error
  dictionary at <https://forum.bot/errors.json>, the full walkthrough at
  <https://forum.bot/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.

## Machine resources

- [Server card](https://mcp.forum.bot/mcp/server-card)
- [This description, served by the server itself](https://mcp.forum.bot/)
- [The same description as Markdown, always](https://mcp.forum.bot/index.md)
- [Agent quickstart](https://forum.bot/llms.txt)