Loading ToolBench
An MCP server that exposes Terraform infrastructure-as-code operations through natural language. Allows LLMs to execute Terraform commands and retrieve information about infrastructure without requiring the user to know specific command syntax.
This server has severe structural and documentation defects. Three tools are defined with minimal descriptions and identical, overly generic input schemas. The 'init_terraform' and 'handle_terraform_query' tools accept unused/misleading parameters. No output schemas are documented. Error handling is absent, operations like 'destroy' with auto_approve=true can cause irreversible infrastructure damage with no confirmation mechanism. Tool naming lacks the action-verb clarity needed for LLM disambiguation (e.g., 'handle_terraform_query' is vague; 'plan_infrastructure', 'apply_infrastructure', 'destroy_infrastructure' would be clearer). Parameter descriptions are minimal and do not explain when each tool should be used or what it returns. Security concerns: no rate limiting, no permission gates, no audit trails for destructive operations.
Process a natural language Terraform query and execute the appropriate command.
Initialize the Terraform project.
Test if this server has access to the project_dir by listing its contents.
Vague tool names lack action-verb clarity. 'handle_terraform_query' does not indicate whether it will plan, apply, or destroy, LLMs cannot infer intent from the name alone.
Irreversible operations (destroy with auto_approve=true) have NO confirmation mechanism. Agents can destroy all infrastructure with a single call. Missing confirm_before_execute or dry-run pattern.
Parameter descriptions are missing or trivial. 'query' parameter across all three tools is described generically; 'init_terraform' notes the query parameter is 'not used in implementation', why expose it? LLMs will pass garbage values.
No output schemas documented. Tools return raw strings from subprocess calls, but LLMs don't know what fields or structure to expect. Cannot plan downstream calls or parse results reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
No error handling or recovery guidance. Subprocess errors (e.g., terraform command not found, invalid configuration) return raw exception strings. LLMs have no actionable direction on retry, alternative approaches, or root cause.
Natural language query routing in 'handle_terraform_query' is brittle. Keyword matching ('if any(keyword in query_normalized...)') is case-sensitive initially, then lowercased, but what if a user says 'will this plan work?' The tool can silently do nothing or trigger the wrong action.
All tools accept a generic 'query' parameter that is either unused (init_terraform) or routed via string matching (handle_terraform_query). No enums, no type safety, no validation. Violates constrained-input pattern.
No permission gates or audit trails. A compromised agent can execute any Terraform operation (destroy, apply) without authentication or logging. Missing scope-declaration and audit-trail patterns.
No rate limiting. An agent in a retry loop can spawn thousands of Terraform processes, overwhelming the system or backend infrastructure.