Supercharge Terraform with MCP Servers

AI assistants are great at writing Terraform, until they invent a resource argument that was removed three provider versions ago. The root cause is always the same: the model's training data is frozen in time while providers ship weekly. MCP (Model Context Protocol) fixes exactly that by letting your assistant query live sources instead of guessing. In this tutorial, I'll show you how to wire up the two MCP servers that make the biggest difference when programming Terraform.

The Terraform MCP server

HashiCorp ships an official Terraform MCP server that connects your assistant directly to the Terraform Registry. Out of the box, it exposes three families of registry tools:

• Provider tools: search any provider's documentation and fetch the full docs for a resource, data source, or function, always at the latest version.
• Module tools: discover community and verified modules, then pull their complete inputs, outputs, and examples before deciding to use one.
• Policy tools: browse Sentinel policies for governance and compliance requirements.

The server runs as a Docker container using the default stdio transport, so nothing is exposed on your network.

Here's how to register it in the most common assistants:

claude mcp add terraform -s user -t stdio -- docker run -i --rm hashicorp/terraform-mcp-server

{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"]
    }
  }
}

{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"]
    }
  }
}

{
  "servers": {
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server"]
    }
  }
}

From there, your assistant stops relying on stale training data from your LLM. Ask it to write an S3 bucket with versioning and it will pull the current aws_s3_bucket documentation first.

With the configurations above, your assistant starts a fresh container on demand and talks to it over stdio. You can also run the server yourself in HTTP mode, which is handy to check that it works, or to keep a single instance running for several tools.

docker pull hashicorp/terraform-mcp-server:latest

docker run -d --rm --name terraform-mcp \
  -p 127.0.0.1:8080:8080 \
  -e TRANSPORT_MODE=streamable-http \
  -e TRANSPORT_HOST=0.0.0.0 \
  hashicorp/terraform-mcp-server:latest

curl -s -X POST http://localhost:8080/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'

claude mcp add --transport http terraform http://localhost:8080/mcp

{
  "mcpServers": {
    "terraform": {
      "type": "http",
      "url": "http://localhost:8080/mcp"
    }
  }
}

{
  "mcpServers": {
    "terraform": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

{
  "servers": {
    "terraform": {
      "type": "http",
      "url": "http://localhost:8080/mcp"
    }
  }
}

docker stop terraform-mcp

Connect it to HCP Terraform

The registry tools work without any credentials. But if you use HCP Terraform or Terraform Enterprise, the same server can also manage your organization: listing workspaces and runs, reading plan and apply logs, browsing state versions, managing variables and variable sets, or searching your private registry. Provide a token and your assistant becomes an operator, not just a documentation reader:

{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "TFE_ADDRESS=https://app.terraform.io",
        "-e", "TFE_TOKEN=<YOUR_TOKEN>",
        "hashicorp/terraform-mcp-server"
      ]
    }
  }
}

The AWS Knowledge MCP server

Provider docs tell your assistant how to write a resource, but not always which AWS architecture makes more sense. If your Terraform targets AWS, pairing the Terraform server with the AWS Knowledge MCP server is a nice combo: it's a fully managed remote server hosted by AWS that exposes the AWS documentation, API references, architectural guidance, Well-Architected best practices, and even the regional availability of each service and API. No container, no credentials, not even an AWS account, just an URL:

claude mcp add --transport http aws-knowledge https://knowledge-mcp.global.api.aws

{
  "mcpServers": {
    "aws-knowledge": {
      "type": "http",
      "url": "https://knowledge-mcp.global.api.aws"
    }
  }
}

{
  "mcpServers": {
    "aws-knowledge": {
      "url": "https://knowledge-mcp.global.api.aws"
    }
  }
}

{
  "servers": {
    "aws-knowledge": {
      "type": "http",
      "url": "https://knowledge-mcp.global.api.aws"
    }
  }
}

With both servers connected, the division of labor is neat: the AWS Knowledge server helps design the architecture and confirms a service is available in your target region, while the Terraform server makes sure the generated code matches the current provider schema.

Put them to work

Once configured, your assitant trigger automatically when your questions touch their domain. A few prompts that show the difference:

• "Write an aws_s3_bucket with versioning and lifecycle rules using the current provider syntax", pulls the latest provider docs instead of recalling deprecated arguments.
• "Is there a verified module for an EKS cluster? Compare its inputs with writing the resources myself", fetches real module documentation with download counts and verification status.
• "Review this VPC configuration against AWS best practices", combines Well-Architected guidance with the current provider schema.
• "Which of my workspaces failed their last run, and why?", reads run logs straight from HCP Terraform (token required).

One last tip to close the loop: these servers make your assistant accurate, but they don't make terraform apply safe. Keep the actual deployment in a controlled pipeline with plan review and least-privilege roles, exactly like the workflow I describe in Deploy Your Terraform IaC with GitHub Actions. Let AI write the Terraform code, and let your CI/CD ship it.