Loading ToolBench
MCP server that inspects Terraform plans and refuses to bless dangerous ones
Five well-named tools with clear, LLM-optimized descriptions (50 - 150 chars each). All tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (list_, summarize_, find_, check_, assess_). Descriptions explicitly state WHEN to use each tool and what it does, matching the prompt-engineering pattern. Error handling returns actionable messages ('COULD NOT READ THE PLAN: {exc}'). However, output schemas are not formally documented, responses are free-text strings rather than structured objects. No pagination support (not needed for this domain). No parameter validation constraints (enums, ranges). Security is strong (read-only operations, no secrets exposed). Composition is excellent, each tool has one clear responsibility and descriptions guide proper sequencing.
Decide whether a Terraform plan is safe to apply: SAFE, REVIEW or BLOCK. ALWAYS call this before telling a user a plan is safe. The verdict is computed in code from the contents of the plan. It is not an opinion and it is not advisory. If it returns BLOCK, report that plainly - do not soften it, do not average it with your own reading of the plan, and do not suggest applying anyway.
Check a plan against security and cost rules. Use this when the user asks whether a plan is secure, or what is wrong with it. Reports findings only; assess_risk turns findings into a decision.
List what a plan destroys or replaces, and whether it can be recovered. Use this when the user asks what will be deleted, or whether a change is reversible. Note that Terraform reports a *replacement* as delete+create, so replacements are destructive too - for a database, the data is just as gone.
List the Terraform plan files this server can read. Use this first if the user has not named a specific file, or if a path was rejected and you need to show them what is available.
Summarise what a Terraform plan will change. Use this for questions like "what does this plan do" or "how many resources change". Give the file name only, e.g. `prod.json`. This describes the plan. It does NOT judge whether it is safe - call assess_risk for that.
Output schemas not formally documented. All tools return free-text strings; no structured response schema is declared. LLMs cannot plan downstream operations or extract typed fields.
No input validation or constraint documentation. 'plan_file' parameter accepts any string; no enum, pattern, or length constraint. LLMs may pass invalid filenames.
Error handling returns raw exception text ('COULD NOT READ THE PLAN: {exc}'). While actionable, it could expose internal details. Should sanitize and provide recovery guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
assess_risk description incomplete in source. Code snippet cuts off mid-function; cannot verify full error handling or return value documentation.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. Limits deployment flexibility.