Loading ToolBench
Terraform Security & AI Review Tool — Static analysis + multi-provider AI contextual review
terraview provides 11 tools with substantial descriptions and moderately detailed schemas. Most tools have non-empty descriptions (80+ chars), which is above the rubric minimum. However, several critical gaps emerge: (1) Input schemas lack consistent type definitions and constraints across parameters, many boolean/string parameters are present but lack explicit type declarations in the schema; (2) Parameter descriptions are present but inconsistent in depth, some describe prerequisites and workflow guidance clearly (terraview_scan, terraview_explain), while others are bare (terraview_scanners, terraview_version); (3) Error handling and recovery guidance are minimal, tools declare they may fail but do not return actionable error messages with next steps; (4) Output schema documentation is present as narrative but not formalized in JSON Schema format within the tool definition; (5) No per-tool idempotency guarantees, rate limits, or permission declarations. The server demonstrates awareness of LLM-friendly design (detailed narrative descriptions, prerequisites stated upfront, examples of workflow guidance in terraview_scan) but falls short of production-grade structuring.
Manage the AI response cache. The cache stores AI analysis results keyed by plan SHA-256 hash to avoid redundant API calls on repeated scans of the same plan. Actions: - status (default): Show cache directory, entry count, total size, and oldest/newest entry timestamps. - clear: Delete all cached entries. Use when switching AI providers, changing the AI model, or when cached results may be stale after major infrastructure updates. Important: "clear" is irreversible. Deleted entries will be regenerated (with API cost) on the next scan.
Deterministic ASCII infrastructure diagram from a Terraform plan. No AI or network access required. Groups resources into layered network topology: VPC → subnets → service tiers. AWS only. Prerequisites: A plan JSON must exist (plan.json or tfplan.json in dir, or pass plan explicitly). Output: ASCII text diagram showing the infrastructure layout. Can be pasted directly into PR comments, issue descriptions, or documentation. Use when asked to: visualize what infrastructure will be created, show the network topology, or generate a diagram for documentation. For GCP or Azure resources, this tool currently returns no output (AWS-only).
AI-powered natural language explanation of Terraform infrastructure. Describes what each resource does, how resources connect, and the overall architecture pattern. Prerequisites: - An AI provider must be configured in .terraview.yaml (llm.provider + llm.api_key). - A Terraform plan JSON must exist. Output: JSON with: - overview: one-paragraph summary of the infrastructure - architecture: description of the architectural pattern (e.g., "3-tier VPC with private subnets") - components[]: per-resource purpose and role - connections[]: how resources relate to each other - patterns[]: recognized architecture patterns - concerns[]: non-security observations (cost, complexity) Use this tool when asked to: explain what infrastructure a plan will create, summarize a plan before review, or generate architecture documentation.
Input schemas lack explicit type definitions for all parameters. While many properties are declared (e.g., 'dir', 'scanner', 'plan'), the schema does not consistently include 'type': 'string', 'type': 'boolean', or 'type': 'integer' declarations. This forces LLMs to infer types from context, increasing errors.
Output schemas are documented only as narrative text within tool descriptions, not formalized as JSON Schema in the tool definition. LLMs cannot reliably parse narrative schema descriptions to understand the structure of returned data. This violates the pattern requirement that tools document output schemas structurally.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Generate AI-assisted fix suggestions for Terraform security findings. Input: A security finding (from terraview_scan output). Output: HCL code snippet showing a corrected version of the resource, plus optional prerequisite resources (e.g. a KMS key required by an S3 encryption fix). Output: JSON with: - finding_id: the finding's RuleID - resource: resource address - severity: finding severity - suggested_hcl: corrected HCL block - prerequisites[]: additional resources to create (e.g. KMS keys, IAM roles) - explanation: why this fix resolves the finding - confidence: "high" | "medium" | "low" (based on rule type and LLM certainty) Use to: generate fix code for security findings, get explanation of how to remediate, or validate that a suggested fix is correct before applying it.
Query the local SQLite scan history for a Terraform project. Every terraview_scan call stores results automatically — no extra configuration needed. Output: Array of past scans ordered by most recent, each with: - id: scan record ID (use with terraview_history_compare) - timestamp: when the scan ran - score: security score at the time (0–10) - findings_by_severity: counts of CRITICAL/HIGH/MEDIUM/LOW findings - plan_file: which plan was scanned Use to: show security posture over time, find when a score degraded, list recent scans, or get scan IDs for comparison.
Compare two specific scan records side by side. Shows score deltas and what findings appeared or were resolved between scans. Output: JSON diff with: - score_before / score_after: security scores for each scan - score_delta: positive = improved, negative = degraded - new_findings[]: findings present in "after" but not in "before" - resolved_findings[]: findings present in "before" but not in "after" - finding_count_delta: changes per severity If before/after are omitted, compares the two most recent scans automatically. Use to: measure security impact of a specific Terraform change, show what improved or regressed between two points, or validate that a fix actually resolved a finding.
Score trend analysis for a Terraform project's scan history. Shows whether the security posture is improving, degrading, or stable over time. Output: JSON with: - direction: "improving" | "degrading" | "stable" - score_delta: change from oldest to newest in the window - data_points[]: (timestamp, score) pairs for sparkline rendering - finding_trend: changes in critical/high/medium finding counts Use to: answer "is this project getting more or less secure over time?", detect regressions across multiple scans, or summarize security posture trends for a report.
Blast radius and dependency impact analysis. Shows how changed resources propagate through the infrastructure dependency graph. Prerequisites: A plan JSON must exist. Output: Impact report with: - changed_resources[]: resources being modified in this plan - impact_graph: for each changed resource, its downstream dependents and impact depth - blast_radius_score: 0–10, higher = more resources affected - high_impact_resources[]: resources whose change affects the most dependents Use when asked: how many resources are affected by changing X, what is the risk of modifying a shared VPC/subnet/security group, or which resources depend on a specific module output.
Security scan of a Terraform plan. Runs a static security scanner (checkov/trivy/terrascan) and AI contextual analysis in parallel, then merges, deduplicates, and scores the findings. Prerequisites: A Terraform plan JSON must exist. Generate it with: terraform plan -out=tfplan && terraform show -json tfplan > plan.json Output: JSON with: - score (0–10, higher is safer) - verdict: "SAFE" or "NOT SAFE" - findings[]: severity, resource, message, category, source - meta_analysis.unified_score and meta_analysis.correlations (resources flagged by multiple tools — highest confidence) - pipeline_status: which components ran and whether they succeeded Workflow guidance: - Use scanner "checkov" for broad IaC coverage. Leave static: false (default) to also run AI cross-resource analysis. - CRITICAL findings → block the change and report to the user. - HIGH-only findings → report with recommended fixes; don't block. - Check meta_analysis.correlations first — multi-tool agreement = highest confidence findings. - If no scanner is installed, call terraview_scanners first to diagnose.
Diagnostic tool: list installed scanners and probe their versions. Helps troubleshoot 'scanner not found' errors. Output: Array of scanner info, each with: - name: "checkov" | "trivy" | "terrascan" - installed: boolean - version: version string if installed, or null if not found - path: full path to the executable (or null) Use to: diagnose why terraview_scan fails with "scanner not found", verify which scanners are available in the current environment, or check scanner versions for debugging.
Return the version of terraview and information about the MCP server. Output: JSON with: - terraview_version: version string (e.g. "v1.2.0") - mcp_protocol_version: MCP protocol version supported (e.g. "2025-06-18") - mcp_server_name: "terraview" Use to: verify which version of terraview is running, check protocol compliance, or troubleshoot version mismatches.
Error handling lacks actionable recovery guidance. Tools declare failure conditions (e.g., 'If no scanner is installed, call terraview_scanners first') in narrative but do not structure error responses with clear 'try this next' instructions. Error responses will be unstructured and may not guide LLM recovery.
terraview_scanners and terraview_version have minimal descriptions (under 70 characters each, excluding examples).
Parameter 'finding' in terraview_fix_suggest is declared as type 'object' with nested properties (ruleId, severity, resource, message), but the schema does not include 'required' array or field-level type declarations (e.g., 'type': 'string' for ruleId). This makes the parameter ambiguous, LLMs may omit required fields.
No permission declarations (e.g., 'requires read:terraform', 'requires write:cache'). The terraview_cache 'clear' action is destructive and irreversible, but there is no declared permission gate or confirmation requirement. Per pattern, destructive tools should require explicit confirmation.
terraview_history, terraview_history_trend, and terraview_history_compare operate on local SQLite state. These tools are stateful (depend on prior scan history) but do not document this interdependency in parameter descriptions. An LLM may call terraview_history_compare before running terraview_scan, leading to empty/confusing results.
Pagination is not implemented for list-returning tools. terraview_history returns up to 'limit' (default 10) records, but there is no 'next_cursor' or 'offset' mechanism to fetch older records beyond the window. For projects with deep scan history, this caps visibility artificially.