Heroku
Heroku's MCP server, shipped on npm as @heroku/mcp-server, is meant to hand an agent the Heroku Platform API: list apps, scale dynos, read and set config vars, run one-off commands, inspect add-ons and releases. It speaks stdio and expects a Heroku auth token in the environment. We started it on 2026-08-19 and it never reached the handshake.
How we started it
npx -y @heroku/mcp-serverSkip it until the package is republished. Our clean-room run died in Node's module resolver before any Heroku credential was even needed, which means the failure is in how the published tarball pins its MCP SDK, not in your setup. That is the good news and the bad news at once: nothing you configure locally will fix it, and Heroku's own CLI already does everything these tools would, so the cost of waiting is small.
Use it if
Skip it if
The bill for your context window
There is no Context Tax to report, which is its own data point. A server that never answers tools/list costs zero tokens and delivers zero capability, so it does not get credit for being light. When it does boot, expect the bill to track the Platform API's surface area: app and dyno management, config vars, add-ons, logs and one-off commands are a lot of verbs, and every one of them arrives with a description your model pays for on every turn. Judge it then, against the median for this batch, not now.
Setup reality
The run line is plain npx against @heroku/mcp-server, and the harness gave it a clean environment with no secrets, as it does for every server. It scraped no env hints out of the crash, because the crash happens too early for the server to complain about missing credentials; the README asks for a Heroku auth token, generated from the CLI or the dashboard, and that is the whole auth dance when the process survives. What actually happened: Node could not find the MCP SDK's server module inside the npx cache, the process printed a fatal error and exited with code 1 before initialize completed (harness 1.0.0, measured 2026-08-19). A bad dependency resolution in the published package, in other words. Pinning a known-good older version, or cloning the repo and building it yourself, is the only route we would trust right now.
Questions people ask
Why does @heroku/mcp-server fail to start with npx?
In our run Node threw a fatal error resolving the MCP SDK's server module inside the npx cache, then exited with code 1 before initialize completed. It is a packaging problem in the published tarball, not a missing Heroku token, so retrying with credentials set changes nothing.
Is this the official Heroku MCP server?
It is published under the @heroku npm scope and its repo lives with Heroku's tooling, so it reads as vendor-built. We list it as unconfirmed official because we verify that from a boot and a serverInfo block, and we got neither.
What should I use instead while it is broken?
The Heroku CLI, driven by whatever shell tool your agent already has. You lose typed tool schemas and gain error messages that actually tell you what went wrong, plus a credential path your security team has probably already signed off on.
Will you re-measure it?
Yes. Every server on this directory gets re-run, and a boot failure caused by a dependency pin is the kind of thing a single patch release fixes. The measured date on this page is the one to watch.
Other cloud servers we started
| Server | Vendor | Boots | Context tax |
|---|---|---|---|
| Azure MCP | Microsoft | ✗ | ~0 tokens |
| Kubernetes | community (Flux159) | ✓ | ~5,964 tokens |
| Netlify | Netlify | ✓ | ~3,083 tokens |
How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.