Loading ToolBench
Complete Heroku CLI MCP Server - all Heroku operations for AI assistants
mcp-heroku presents 8 tools with reasonable naming conventions (verb_noun pattern, clear prefixes) and complete input schemas. However, descriptions are inconsistent in depth, several parameter descriptions lack specific constraints or guidance, and output schemas are not documented. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification across tools. The server follows basic tool definition patterns but falls short of production-grade quality expected at 70+.
Get or set config vars (environment variables) for a Heroku app.
Get detailed information about a Heroku app including dynos and formation.
Get recent logs from a Heroku app. Can filter by dyno or source.
List all add-ons attached to a Heroku app (databases, caches, etc.)
List all Heroku apps. Optionally filter by team.
List releases for a Heroku app. Shows deployment history.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification. heroku_restart (REVERSIBLE), heroku_scale (WRITE), and heroku_config_vars (WRITE) should declare their impact level for agent safety.
Output schemas are not documented in tool definitions. Callers cannot predict response structure, they must infer from implementation. E.g., heroku_get_app's response includes dynos array and formation array, but this is invisible in the tool contract.
Parameter descriptions lack constraint guidance. E.g., heroku_scale's 'quantity' param has no min/max bounds (e.g. '1-100 dynos'); 'size' param lists examples 'eco, basic, standard-1x' in description instead of enum constraint; heroku_get_logs 'lines' default is '100' but no bounds specified (min 1?, max 1000?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Restart dynos for a Heroku app. Can restart all dynos or a specific one.
Scale dynos for a Heroku app. Change the number of running dynos.
Error responses use generic messages without recovery guidance. E.g., 'Failed to get app: <error message>' gives no actionable next step. Pattern calls for 'Try search_users() with a partial name' style guidance.
heroku_config_vars combines multiple responsibilities (get OR set, with complex conditional parameters). Tool does 'get config vars' and 'set config vars', should split into heroku_get_config_vars and heroku_set_config_vars for clarity.
heroku_list_apps and heroku_list_releases lack pagination parameters (limit, offset, next_cursor). If a user has 100+ apps or releases, results could blow context window. No per-tool description of result limits.
No documentation of required permissions or scope declarations. Tools like heroku_scale and heroku_restart modify state, should declare what OAuth scopes or API permissions the agent needs.