{"slug": "hashicorp-built-an-mcp-server-for-writing-terraform-i-built-one-for-reviewing-it", "title": "HashiCorp built an MCP server for writing Terraform. I built one for reviewing it", "summary": "HashiCorp recently released an official MCP server that helps AI models write Terraform by searching providers and managing workspaces. In response, the author built \"tf-review-mcp,\" a specialized MCP server that parses `terraform plan` output to identify high-risk changes like stateful resource deletions and public exposure of firewalls, structuring the data for LLMs to generate actionable PR review comments. The author argues this approach is more useful than existing tools because it focuses on reviewing planned actions rather than code diffs, and the structured data format reduces hallucination risk for AI assistants.", "body_md": "A few weeks ago HashiCorp shipped terraform-mcp-server\n. It's an official MCP server that lets a model lean on the Terraform Registry: search providers, pull module docs, manage HCP Terraform workspaces. The shape is \"help the model author IaC.\" That's a genuinely useful tool and a clear signal that Terraform-via-MCP is now a category, not a curiosity.\nBut it doesn't help with the part of Terraform I spend the most time stressed about: reviewing somebody else's plan.\nterraform plan\noutputs are long. Real production plans run into the thousands of lines. The risky changes (an IAM grant going *\n, a security group opening to 0.0.0.0/0\n, an RDS instance being replaced) hide between a hundred routine attribute updates. Code review tools don't help because the danger isn't in the HCL diff, it's in the planned actions.\nSo I built tf-review-mcp\n. It's an MCP server scoped to one job: parse terraform show -json\noutput and surface what a human reviewer actually cares about, structured for an LLM to quote and reason about.\nTwo tools:\nreview_plan(plan_json_path)\nreturns a structured summary: action counts, high-blast-radius resource changes, stateful destroys, and diff-aware public-exposure findings.suggest_review_comments(plan_json_path)\nreturns a list of {address, severity, comment}\nobjects ready to drop into a PR review.The server flags three things:\nHigh-risk resource types (warn). A conservative built-in list across AWS, GCP, and Azure: IAM, KMS, RDS, security groups, S3, EKS, GKE, Cloud SQL, GCS, Cloud DNS, GCE firewalls, Key Vault. Easy to extend in source.\nStateful destroys (blocker). When a stateful resource like aws_db_instance\n, google_sql_database_instance\n, or google_compute_instance\nis scheduled for delete or replace. The GCE case matters more than people realize: a replace\non a Compute Engine VM with local SSDs nukes both the boot disk and any local-SSD attachments. Silent data loss if a reviewer misses it.\nPublic exposure changes (blocker). Diff-aware. The server compares before\nand after\non every google_compute_firewall\nchange and fires when source_ranges\nnewly contains 0.0.0.0/0\nor ::/0\n. That single check has caught more dumb mistakes for me than any static analyzer.\nGiven a plan that deletes a Cloud SQL instance, replaces a GCE VM, and widens a firewall to the public internet, the server returns:\n{\n\"counts\": {\"create\": 1, \"update\": 3, \"replace\": 1, \"delete\": 1},\n\"stateful_destroys\": [\n{\"address\": \"google_compute_instance.op_geth\", ...},\n{\"address\": \"google_sql_database_instance.indexer\", ...}\n],\n\"public_exposure_changes\": [\n{\"address\": \"google_compute_firewall.rpc_public\",\n\"finding\": \"source_ranges now includes 0.0.0.0/0 (public exposure)\"}\n],\n\"notes\": [\n\"2 stateful resource(s) scheduled for destroy/replace. Verify backups and migration plan before applying.\",\n\"1 firewall change(s) widen public exposure. Confirm intent before applying.\"\n]\n}\nAsked to summarize, Claude reads this and produces:\nBlocker-severity items (3)\ngoogle_compute_instance.op_geth\n: Delete/recreate of a stateful compute instance. Confirm backup, migration, and rollback plan before merging.google_sql_database_instance.indexer\n: Cloud SQL instance is being deleted. Confirm backup, migration, and rollback plan before merging.google_compute_firewall.rpc_public\n:source_ranges\nnow includes0.0.0.0/0\n(public exposure). Confirm this is intentional and matches firewall policy.\nThat's a PR review comment I'd actually merge.\nThe same parser could be a CLI. The reason MCP matters is the conversational shape. When I'm reviewing a plan, I want to ask follow-up questions: \"is the SQL delete a replace or a hard destroy?\", \"what changed about that firewall?\", \"draft me a PR comment for the IAM grant.\" The model can pull the right tool, narrow on the right resource, and write something useful, because the underlying tool returns data, not prose. Lower hallucination surface. Higher signal per token.\nMost community Terraform-MCP experiments wrap the CLI (\"run terraform plan\nfor me\"). That's the wrong abstraction for review. You don't want the model running plan; you want it reasoning about a plan that already ran.\nThe parser is in review.py\nas pure functions with no MCP imports: plan JSON in, ReviewSummary\nout. The MCP wrapper is in server.py\n, about a hundred lines. The split means the parser can be unit-tested, dropped into CI, or audited without touching the transport.\nDeployment is local stdio. Always. The MCP client launches the server as a child process. Plan JSON never leaves your laptop. No auth, no shared state, no network listener.\nPlan JSON contains IAM relationships, account IDs, security group rules, and resource counts. Hosted \"send us your plan\" services are a recon goldmine waiting to happen. The architecture should make leakage impossible by default. A self-hosted HTTP variant for CI is a v2 idea, with auth and a path allowlist, not before.\nHashiCorp's official server covers Registry lookup and HCP workspace management. Helpful for writing.\nThis one covers plan review. Helpful for reviewing.\nBoth ship as MCP servers. Both can be installed in the same client. The model picks the right tool per task. They're complementary by design, not competitive.\nI haven't found another MCP server scoped specifically to plan review with LLM-friendly structured output, as of writing. If one exists, I want to know.\nestimate_cost_delta\nwrapping Infracost.check_policy\nwrapping Conftest, so teams can bring their own Rego.HIGH_RISK_TYPES\nvia a YAML file so each team can codify its own blast-radius rules.aws_security_group\ningress widening, IAM *\ngrants, google_storage_bucket\nforce_destroy\ntoggles.The repo lives here: github.com/sanjeevkkansal/tf-review-mcp. It's MIT-licensed, v0.2, and very much open to PRs, especially if you have a war story about a plan that should have been caught.\nSanjeev Kumar is an infrastructure engineer working on platform tooling, AI-assisted ops, and infra that doesn't wake people up at 3am.", "url": "https://wpnews.pro/news/hashicorp-built-an-mcp-server-for-writing-terraform-i-built-one-for-reviewing-it", "canonical_source": "https://dev.to/sanjeevkkansal/hashicorp-built-an-mcp-server-for-writing-terraform-i-built-one-for-reviewing-it-9mn", "published_at": "2026-05-21 18:11:24+00:00", "updated_at": "2026-05-21 18:31:40.046665+00:00", "lang": "en", "topics": ["developer-tools", "cloud-computing", "open-source", "artificial-intelligence", "large-language-models"], "entities": ["HashiCorp", "Terraform", "MCP", "AWS", "GCP", "Azure", "HCP Terraform", "tf-review-mcp"], "alternates": {"html": "https://wpnews.pro/news/hashicorp-built-an-mcp-server-for-writing-terraform-i-built-one-for-reviewing-it", "markdown": "https://wpnews.pro/news/hashicorp-built-an-mcp-server-for-writing-terraform-i-built-one-for-reviewing-it.md", "text": "https://wpnews.pro/news/hashicorp-built-an-mcp-server-for-writing-terraform-i-built-one-for-reviewing-it.txt", "jsonld": "https://wpnews.pro/news/hashicorp-built-an-mcp-server-for-writing-terraform-i-built-one-for-reviewing-it.jsonld"}}