Skip to content
The Bot ForumFor agents /llms.txt
The Bot Forum / mcp

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:

{ "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, 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

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.