Terraform MCP Server Setup for Cursor IDE (2026)

HashiCorp's Terraform MCP server connects Cursor to the Terraform Registry so your AI can look up provider resource schemas, data sources, and module documentation while you write HCL — instead of guessing argument names or hallucinating a resource block that doesn't match the provider version you're actually pinned to. It runs as a local process via Docker or a downloaded binary, and it's a docs/registry lookup tool, not a way to run terraform plan or apply through chat.

That distinction matters enough that it's worth stating up front: this server makes Cursor better at writing correct Terraform, it does not give your AI a way to touch your infrastructure or state file.

What This Integration Actually Does (and Doesn't Do)

With the Terraform MCP server connected, Cursor can:

It does not:

If you want an AI that can reason about what's actually running in your account, that's a job for cloud-provider-specific tools (AWS, GCP consoles/APIs) or a wrapper you build yourself around the Terraform CLI — this server is scoped to documentation and registry data only.

Prerequisites

Step 1: Get the Server Running

The simplest path is Docker — HashiCorp publishes an image so you don't need a local Go toolchain:

docker pull hashicorp/terraform-mcp-server

Confirm it runs:

docker run -i --rm hashicorp/terraform-mcp-server

If you'd rather run it as a native binary, build it from the hashicorp/terraform-mcp-server repository directly with go install — useful if you want to avoid a Docker dependency on a machine that already has a Go toolchain for other reasons.

Step 2: Add It to Cursor's Config

Open ~/.cursor/mcp.json:

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

No environment variables are required for public Terraform Registry lookups. If you need private module or provider access from Terraform Cloud, add a token:

{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "TFC_TOKEN", "hashicorp/terraform-mcp-server"],
      "env": {
        "TFC_TOKEN": "your-terraform-cloud-token"
      }
    }
  }
}

Step 3: Restart Cursor and Verify

Quit and reopen Cursor, then ask:

What arguments does the aws_instance resource support in the latest AWS provider version?

A correct, current answer confirms it's pulling live registry data rather than relying on training data that might reference a deprecated argument.

Practical Workflows

Writing a Resource Block from Scratch

I need to provision an S3 bucket with versioning enabled and a lifecycle rule to expire objects after 90 days — look up the current aws_s3_bucket-related resources and write the HCL

This is the core use case: instead of the AI recalling (possibly outdated) provider syntax from training data, it looks up the actual current schema before writing anything.

Checking a Provider Version Bump

We're bumping the AWS provider from 4.x to 5.x — look up whether aws_s3_bucket_lifecycle_configuration replaced the old inline lifecycle block, and rewrite our existing config accordingly

Provider major-version bumps are exactly where stale AI knowledge causes the most damage — resource attributes get split into separate resource types often enough that this is a genuinely common real-world edit.

Evaluating a Module Before Adopting It

Find community modules for provisioning an EKS cluster, compare their input variables, and tell me which one exposes node group configuration most flexibly

Cross-Referencing Data Sources

I need the current AMI ID for Amazon Linux 2023 in us-east-1 — what data source and filters would return that, and write the block

Troubleshooting

Docker container exits immediately
Run without --rm temporarily and check docker logs on the stopped container — this is almost always a missing -i flag (the server expects stdin to stay open for stdio transport).

Registry lookups return stale-looking data
The server queries the live Terraform Registry API, so results should reflect what's actually published. If something looks wrong, double check you specified the provider version you think you're on — omitting a version constraint returns the latest, which may differ from what your required_providers block pins.

Private module search returns nothing
Confirm TFC_TOKEN is a valid Terraform Cloud (or Enterprise) token with access to the organization that owns the module, not a personal token scoped only to your own workspaces.

AI still suggests a deprecated resource despite the server being connected
Check that Cursor is actually invoking the tool rather than answering from its own knowledge — ask explicitly to "look up the current schema" rather than a general question, which nudges it toward using the tool instead of guessing.

When This Doesn't Replace Your Existing Workflow

If your team already has a solid internal module library and rarely touches raw provider resources directly, this integration adds less value — you're mostly writing module blocks with a handful of variables, not hand-rolling resource arguments where registry lookups matter most. It earns its keep most clearly for teams frequently working across multiple providers or dealing with version migrations, where remembering exact current syntax is the actual bottleneck.

Frequently Asked Questions

Q: Can the Terraform MCP server run terraform apply for me?
A: No. It's a registry and documentation lookup tool — it has no access to your local state, your cloud credentials for provisioning, or the Terraform CLI's execution engine. Running plans and applies stays a manual (or CI-pipeline) step.

Q: Does it need my cloud provider credentials (AWS keys, GCP service account, etc.)?
A: No. It only talks to the Terraform Registry's public API for schema and module data — it never touches your actual infrastructure or requires cloud credentials.

Q: Is this an official HashiCorp project or a community one?
A: It's published under the HashiCorp GitHub organization. As with any actively developed tool, check the repository's current release notes before pinning a version in a team-wide config, since tool coverage has expanded since initial release.

Q: Will it work with Terraform Enterprise's private registry, not just the public one?
A: Yes, if you supply a valid token scoped to your Enterprise or Cloud organization. Public registry lookups work with no token at all.

Q: Does this help with existing .tf files, or only new resource blocks?
A: Both — you can point Cursor at existing HCL and ask it to verify the arguments used are still current for your pinned provider version, which is useful specifically during provider upgrades.

Related Guides

---