HashiCorp's terraform-mcp-server gives Atlas the exact provider and module schemas from the registry, so the HCL it writes uses real arguments instead of plausible-looking ones. Add the server over stdio with atlas mcp add terraform -- docker run -i --rm hashicorp/terraform-mcp-server. Registry lookups need no credentials, and there is no HashiCorp-hosted endpoint, so the server always runs on your own machine.
Why Atlas needs terraform-mcp-server to write correct HCL
HashiCorp's terraform-mcp-server gives Atlas the exact provider and module schemas from the registry. In 2026 that fixes the single worst failure mode of AI-written Terraform: HCL that uses plausible-looking arguments which do not exist, and only fails when terraform plan finally runs.
A language model asked to write Terraform from memory produces HCL that looks correct. The resource type is right, the block structure is right, and two of the five arguments are invented. Terraform providers change fast enough that no static training data keeps up. terraform-mcp-server solves this by giving Atlas the real schemas from the Terraform registry at the moment it writes the code. Atlas looks up the resource, sees the actual arguments, their types, and which are required, and writes HCL against that rather than against a recollection.
Adding HashiCorp's terraform-mcp-server to Atlas
Add HashiCorp's terraform-mcp-server over stdio with atlas mcp add terraform -- docker run -i --rm hashicorp/terraform-mcp-server. Two flags matter in 2026: -i keeps stdin open for the MCP stdio transport, and --rm cleans the container up afterwards. Registry lookups need no credentials at all.
Docker is the path of least resistance because HashiCorp publishes the image and it needs no local Go toolchain. Both flags are load-bearing. Without -i, stdin closes and the MCP stdio transport has nothing to talk over. Without --rm, dead containers accumulate every time Atlas restarts the server. If Docker is not part of your workflow, prefer a binary instead: go install github.com/hashicorp/terraform-mcp-server/cmd/terraform-mcp-server@latest and point the command array at it. The binary starts faster and drops the container runtime from the dependency list.
Credentials: registry lookups versus HCP Terraform
Registry lookups through terraform-mcp-server need no credentials at all, so Atlas can read provider and module schemas on a machine with zero Terraform configuration. In 2026 the exception is HCP Terraform or Terraform Enterprise: set TFE_TOKEN and TFE_ADDRESS, for example https://app.terraform.io.
There are two distinct things the server can talk to, and they have different credential requirements. The public Terraform registry, which is where provider and module schemas come from, is open, so nothing needs configuring for Atlas to look up a resource schema. HCP Terraform and Terraform Enterprise are a different matter: they hold your workspaces and your state, so terraform-mcp-server needs TFE_TOKEN to authenticate and TFE_ADDRESS to know where to point, for example https://app.terraform.io for HCP Terraform. Set them only if you need that half.
terraform-mcp-server always runs on your own machine
There is no HashiCorp-hosted endpoint for terraform-mcp-server, so the server always runs on your own machine. In 2026 that removes an entire category of question for Atlas users doing Terraform work: no third party sees your provider lookups, your TFE_TOKEN, or the HCL Atlas is drafting.
Some MCP integrations offer a hosted URL and a local process, and you pick. Terraform does not. HashiCorp ships terraform-mcp-server as something you run, either as the Docker image hashicorp/terraform-mcp-server or as a binary you install with go install. That is worth knowing up front so you do not go looking for a URL that does not exist. It also means the security review for adding terraform-mcp-server to Atlas is short: the process runs locally, it reaches out to the Terraform registry, and TFE_TOKEN never leaves your machine.
The daily workflow: schema lookup, HCL, then terraform plan
The Atlas and Terraform loop in 2026 is three steps in one prompt. Ask Atlas to look up the exact resource schema, write the HCL, and run terraform plan against it. Because terraform-mcp-server supplies the real schema first, the plan usually succeeds on the first attempt rather than the third.
Order matters here. Atlas looks up the resource schema through terraform-mcp-server before writing anything, so the HCL it produces already uses arguments that exist. Then terraform plan becomes a verification step rather than a discovery step. When plan does surface something, the feedback is real: a type mismatch, a missing required argument in a nested block, a dependency Terraform cannot resolve. Atlas reads the plan output and iterates. The whole loop stays inside the terminal, and the artifact at the end is HCL in your repository that you have read.
Permissions: allow terraform plan, gate terraform apply
Set 'terraform plan' to allow and 'terraform apply' to ask under permission.bash, so Atlas can iterate on plans and never apply one alone. This is the correct permission split for Terraform in 2026, because plan is read-only and apply is the command that changes real infrastructure.
Terraform draws an unusually clean line between reading and writing, and Atlas's permission model should follow it exactly. terraform plan computes a diff and touches nothing, so allowing it lets Atlas iterate freely: write HCL, plan, read the error, fix, plan again, without stopping to ask you for permission on every cycle. terraform apply is the opposite. It provisions, it destroys, and it is irreversible in the ways that matter. Setting it to ask under permission.bash means Atlas can prepare a clean plan and hand it to you, and you are the one who applies it.
Setup
- 01Add HashiCorp's server over stdio with atlas mcp add terraform -- docker run -i --rm hashicorp/terraform-mcp-server
- 02If you would rather skip Docker, install a binary with go install github.com/hashicorp/terraform-mcp-server/cmd/terraform-mcp-server@latest and point the command array at it.
- 03Registry lookups need no credentials, so skip auth entirely unless you use HCP Terraform or Terraform Enterprise.
- 04For HCP Terraform or Terraform Enterprise, set TFE_TOKEN and TFE_ADDRESS, for example https://app.terraform.io
- 05Set 'terraform plan' to allow and 'terraform apply' to ask under permission.bash, so Atlas can iterate on plans and never apply one alone.
- 06Ask Atlas to look up the exact resource schema, write the HCL, and run terraform plan against it.
Frequently asked questions
- how to connect atlas to terraform mcp server
- Run atlas mcp add terraform -- docker run -i --rm hashicorp/terraform-mcp-server. Registry lookups need no credentials, so it works immediately.
- is there a hosted terraform mcp server endpoint
- No. There is no HashiCorp-hosted endpoint, so terraform-mcp-server always runs on your own machine, either as the Docker image or as a locally installed binary.
- how do i run terraform-mcp-server without docker
- Install it with go install github.com/hashicorp/terraform-mcp-server/cmd/terraform-mcp-server@latest and point the command array at the resulting binary.
- what credentials does terraform-mcp-server need
- None for registry lookups. For HCP Terraform or Terraform Enterprise, set TFE_TOKEN and TFE_ADDRESS, for example https://app.terraform.io.
- why does ai written terraform use arguments that do not exist
- Because it is written from memory. HashiCorp's terraform-mcp-server gives Atlas the exact provider and module schemas from the registry, so the HCL uses real arguments instead of plausible-looking ones.
- can atlas run terraform apply on its own
- Not if you configure it correctly. Set 'terraform plan' to allow and 'terraform apply' to ask under permission.bash, so Atlas iterates on plans and never applies one alone.
- can atlas write hcl and run terraform plan
- Yes. Ask Atlas to look up the exact resource schema, write the HCL, and run terraform plan against it. The schema lookup happens before the HCL is written.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas for Erlang in 2026
Atlas is a terminal-native AI coding agent for Erlang/OTP in 2026. Run it in an app with a rebar.config, map supervisors and gen_server modules, review every diff.
Atlas with Gemma 4 26B A4B: The Open-Weights MoE Option in 2026
Gemma 4 26B A4B in Atlas: a sparse MoE with about 4B active of 26B total parameters, a 262,144 token context, a 32,768 token output cap, and no public price.
Atlas for Spring in 2026
Atlas, the terminal native AI coding agent, empowers Spring developers in 2026 with intelligent code assistance, secure local embeddings, and transparent review processes for enhanced productivity.
Atlas with Mistral NeMo 12B (Ollama): 128K Context on a 12GB Card in 2026
Run Atlas on Mistral NeMo 12B (Ollama): 7.1GB, a 128K practical context, free self-hosted. Why the Ollama tag says 1000K, and what limit.context to actually set.
Atlas vs Warp: Choosing Your AI Coding Agent in 2026
Compare Atlas, the terminal-native AI coding agent, with Warp, a smart terminal with AI Agent Mode, for developers in 2026. Evaluate features, privacy, and workflow.
Atlas with Devstral Medium (2507): Agent-Trained Frontier Coding in 2026
Devstral Medium (2507) gives Atlas agent-first training at $0.40 / 1M input tokens and $2.00 / 1M output tokens, with 128,000 tokens in and out. Setup and tradeoffs.
Atlas with Qwen2.5-Coder 1.5B (Ollama): the 986MB small_model slot in 2026
Qwen2.5-Coder 1.5B (Ollama) in Atlas: a 986MB Q4_K_M pull with 32K tokens (32,768) of context, Free (self-hosted), sized for titles and summaries, not refactors.
Atlas with MiniMax-M2.5-highspeed in 2026: Paying 2x for Latency
MiniMax-M2.5-highspeed runs Atlas at $0.60 per Mtok input and $2.40 per Mtok output, exactly double base M2.5, for identical weights and a 204,800 token context.