v1.0 of brainstorm-mcp shipped with two providers wired up: OpenAI and DeepSeek. Gemini arrived later in v1.2.0 (3690f24, 2026-02-26), and groq, mistral and together are in the list too. You never needed all of them. The provider loader walks the list and skips anything whose env var is missing, so one working key is enough to run a debate.
The catch is which key. Every provider in that list belongs to somebody other than Anthropic. There is no Claude provider in the server and there never was; in API mode Claude's role is to read what the other models said and add its own take, which happens through the host rather than through a key the server holds. So if you're running Claude Code and you install brainstorm-mcp to see what a multi-model debate looks like, the number of usable keys you have is quite possibly zero. The friction was never "go collect N keys." It was "go sign up with a vendor you weren't otherwise using, before you can find out whether this tool is any good."
The inversion
v1.4.0, commit 7906fbf, 2026-03-24: "Add hosted mode for API-key-free multi-model brainstorming" (PR #1, co-authored with Claude Opus 4.6 per the commit trailer; Opus and I worked out the orchestration model together).
Hosted mode isn't a seventh provider or a free-tier proxy. In API mode the server is a caller. It holds keys, hits api.openai.com or api.deepseek.com, returns results. In hosted mode it never calls a model API. It builds the debate prompt for a given round and a given voice, then hands that prompt back to the host as tool output. Claude Code spawns sub-agents on opus, sonnet and haiku to run those prompts, using model access the host already has. Responses come back in through brainstorm_collect, which appends them to the debate and decides what round comes next.
Worth being precise about the mechanism, because it's easy to overstate. The server cannot make the host do any of that. What it returns is a prompt plus instructions, and Claude Code acts on them because acting on tool guidance is what a host does. There's no protocol-level guarantee anywhere in this. A host that ignored the instructions and dumped the prompt text at the user would leave the server sitting on a half-finished session until it timed out. The whole arrangement is cooperative, and I'd rather say so than let it sound like the server is driving.
Mode selection is automatic. If the model names you pass don't carry a provider: prefix (no openai:gpt-5.5, no deepseek:deepseek-chat), the server reads that as hosted mode and assumes you mean the host's own models. No flag, no config file, just the shape of the string.
The same commit brought context injection, so a debate can be grounded in a real diff or file instead of a topic sentence, plus the debate styles (freeform, redteam, socratic) and a synthesis format that closes every debate with Recommendation, Key Tradeoffs, Strongest Disagreement in both modes. brainstorm_respond was already there from v1.1.0 (75c8949, "Add interactive mode — Claude participates as active debater"); 7906fbf touched it by exactly one line, passing session.style through.
The design consequence I care about is what happens once the server stops calling models. It has to hold state: which round the debate is on, which voices have spoken, what's outstanding. That lives in memory with a 10-minute TTL, and calling brainstorm_collect against an expired session returns an error telling you to start a new one.
Two ways it broke, same afternoon
Both of these live in the API-mode calling path, which hosted mode's design doesn't touch. They broke a debate I was running to test hosted mode, so they're part of the same afternoon.
v1.5.6, c9e3d86, 2026-04-27, "drop temperature for gpt-5.x reasoning models." Three-round brainstorm, openai:gpt-5.5 and deepseek:deepseek-chat as the two voices. Every round-1 turn from gpt-5.5 came back as an HTTP 400:
Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.
The gpt-5.x family and the o-series reject any non-default temperature. deepseek-chat doesn't care what you send it, so the loop ran fine right up to the OpenAI voice, which is why testing hadn't caught it. The code already branched on model family for max_tokens vs max_completion_tokens, tracked by a useNewTokenParam flag, so the fix reused that branch and stopped sending temperature: 0.7 down it. Older gpt-4.x models still get it, since they still accept it. Rechecked against gpt-5.5-2026-04-23: 200 OK, no temperature field in the request body.
v1.5.7, 9af668b, same day, "bump per-call timeout 2m -> 5m." I shipped the temperature fix, reran the same debate, and it stalled at 120 seconds. DEFAULT_TIMEOUT_MS in src/debate.ts was hardcoded to 120_000. gpt-5.5 doing reasoning on a real brainstorm prompt (multi-thousand-word topic, six-option intervention list, redteam framing instructions on top) goes past two minutes routinely. Session 01751c60-256a-489b-88d3-9b954a3edd79, round 1, same wall on retry. One constant, 300_000, done. deepseek-chat and gpt-4.x were finishing well under two minutes and saw no change at all.
Under an hour between the two commits, which is about how long I spent believing the first one had unblocked the debate.
One thing I'm watching now: SESSION_TTL_MS is 600_000 while DEFAULT_TIMEOUT_MS is 300_000 post-fix. Two slow reasoning calls back to back inside a single round could in principle burn most of a session's life before the round finishes. I haven't hit it and I'm not certain the arithmetic works out that way in practice, but it's the next thing I'd expect to go wrong.
What the numbers say
From state/metrics-history.jsonl, npm downloads per month and GitHub stars as recorded:
| Date | npm downloads/month | GitHub stars |
|---|---|---|
| 2026-08-09 | 286 | 67 |
| 2026-08-18 | 345 | 67 |
| 2026-08-21 | 413 | 67 |
| 2026-08-24 | 427 | 67 |
Downloads up about 49% across those 15 days. Stars sat at 67 on every check.
I read that as a property of how this kind of tool gets installed rather than as a problem. You add brainstorm-mcp to an MCP client config and start calling brainstorm_quick. Nothing in that path requires opening the repo. Starring costs a page visit plus a small public declaration of interest; downloading costs wanting to run the thing. For a mechanical utility with a narrow use case, I'd weight the download curve over the star count.
Plenty of people will call that motivated reasoning from someone whose star count isn't moving, and four data points over two weeks isn't evidence of anything. It's four numbers. What it did change is what I bother logging.
Pranab Sarkar, Independent Researcher
