Event Automation

Terraform PR Agent with the HashiCorp MCP Server

An event-driven workflow where an AI agent grounded by HashiCorp's official Terraform MCP server writes and corrects Terraform against real provider schemas, then opens a pull request that runs plan in CI — so generated HCL references resources and arguments that actually exist.

What This Builds

LLMs hallucinate Terraform: plausible-looking resources, arguments, and module inputs that do not exist in the provider you are actually using. This recipe grounds an IaC agent in real provider schemas using HashiCorp’s official Terraform MCP server, which gives the model live access to the Terraform Registry — providers, resources, modules, and their argument specs.

The flow is event-driven: an infrastructure change request (an issue, a comment, a chat command) triggers an agent that queries the MCP server for the correct provider schema, generates or edits HCL that conforms to it, and opens a pull request. The PR runs terraform plan in GitHub Actions, so a human reviews a real plan diff rather than untested generated code.

The Stack

  • Terraform MCP Server is HashiCorp’s official, production-grade MCP server. It integrates with the Terraform Registry APIs so an agent can look up accurate provider schemas, resources, and modules instead of guessing. It runs locally or remotely, and can run inside GitHub Actions.
  • The agent is any MCP-capable client (a coding agent, GitHub Copilot Chat, or a custom client) that calls the MCP tools while drafting HCL.
  • Terraform is the target language; GitHub Actions runs fmt, validate, and plan on the resulting PR.

Step-by-Step Outline

  1. Deploy the Terraform MCP server — locally for interactive authoring, or as a step inside GitHub Actions for CI-time schema grounding.
  2. Connect your agent/MCP client to the server so it can call the registry lookup tools (fetch latest provider version, resolve resource and argument schemas, find modules).
  3. Trigger on an event: an issue labeled infra-request, a /terraform comment, or a chat message describing the desired change.
  4. The agent queries the MCP server for the exact provider schema, then writes or edits HCL that conforms to it.
  5. Open a PR with the generated change on a branch.
  6. CI runs terraform fmt -check, terraform validate, and terraform plan; the plan output is posted to the PR for human review and approval before any apply.

Grounding through MCP is what separates this from a blind generator: the model’s output is checked against real schemas at authoring time, and against a real plan at review time.

Source