Modular Infrastructure with AI and Terraform

Ask an AI assistant to write Terraform without any tooling attached and it will produce plausible configuration built from its training data, which means provider syntax that may be several versions old and module arguments that may no longer exist. The failure is not intelligence. The model is answering from memory in a domain where memory goes stale within months, and infrastructure code punishes staleness at apply time.

The fix is one of the cleaner wins available in AI-assisted engineering right now, and it takes an afternoon to set up. This article covers the Terraform MCP server, the documentation problem for AWS specifically, and why this small workflow is a working miniature of a much larger architectural principle.

What the Terraform MCP server provides

The Model Context Protocol is the emerging standard for connecting AI assistants to live tools and data, and HashiCorp ships an official Terraform MCP server, now generally available. Connected to an MCP-compatible assistant, it gives the model tools to search and retrieve current provider documentation, inspect modules including their inputs, outputs, and examples, and find Sentinel policies for governance, all against the live registry rather than training data.

For organizations on HCP Terraform or Terraform Enterprise, the server goes further: it can list organizations and projects, reach the private registry, and manage workspaces, variables, and runs. The private registry access is the capability I would call strategically important, because it means an assistant can discover your approved modules and generate configuration that composes them, rather than inventing bespoke resources that bypass the patterns your platform team spent a year standardizing. HashiCorp’s own pattern write-up describes exactly this workflow: the agent discovers the approved networking and Kubernetes modules, generates compliant configuration, and validates it iteratively before anything reaches a human reviewer.

Setup is a short block of JSON in your assistant’s MCP configuration. The server runs locally via Docker with stdio transport, or as a shared Streamable HTTP service for a team:

{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"],
      "env": { "TFE_TOKEN": "your-token-for-enterprise-features" }
    }
  }
}

Two configuration details are worth knowing before you roll this out. The server supports --toolsets flags to control which tool groups are exposed, with the read-only registry tools as the default, so you can grant documentation lookup without granting workspace mutation. And the repository documents an AGENTS.md convention, a file committed beside your Terraform configurations that gives any coding agent your project’s boundaries and conventions. Both of these are permission decisions, and I recommend making them deliberately rather than enabling everything.

The AWS documentation question

Terraform knowledge is half of the loop; the assistant also needs current knowledge of the services it is provisioning. For AWS there are several ways to provide it, and they are not equivalent.

AWS publishes MCP servers of its own, including documentation servers that give an assistant search and retrieval over the official docs, which is the highest-fidelity option because answers come from the same pages an engineer would read, current as of the query. Broader AWS knowledge servers add API references and regional availability data. The fallback is ordinary web search, which works but returns the open internet, where the top result for an AWS question is often a blog post from three major service revisions ago.

My working rule is to match the source to the stakes. For syntax and service behavior questions during authoring, the documentation MCP servers are strictly better than model memory or search. For architectural decisions, none of these replaces reading the service documentation yourself, because the assistant retrieving a page and you understanding its implications remain different events.

The part that is not about Terraform

I described this article to myself as a softball when I planned it, and mechanically it is. But the reason the workflow works is the same reason the enterprise architecture I write about works, and the miniature is worth examining.

The MCP server does not make the model smarter. It grounds the model in a trusted, current, permissioned source of truth, and the quality improvement follows from the grounding. That is the identical move the full framework makes at enterprise scale, where agents answer from governed knowledge graphs instead of from memory and every retrieval is checked against systems of record. Infrastructure as code, meanwhile, is what makes the modularity principle real: when every layer of a system is declared in reviewable text, swapping a component as technology changes is an edit rather than an excavation, which is the framework’s defense against both vendor lock-in and structural obsolescence.

There is also a governance miniature here. The Terraform MCP server enforces your existing authentication, exposes only the tools you enable, and hands the assistant information rather than credentials. Those are the same properties the trust boundary in the Architecture series enforces for every worker in an enterprise fleet. If your organization wants a low-stakes place to develop the muscle of giving AI systems scoped, revocable, auditable access to real tooling, your Terraform workflow is a genuinely good gym.

The practical start is small. Connect the server in read-only registry mode, point your assistant at a module upgrade you have been deferring, and compare the generated configuration against the registry documentation it cites. You will learn in one afternoon whether grounded assistance earns a place in your infrastructure workflow, and you will have rehearsed, at the smallest useful scale, the pattern the rest of this site describes at the largest.