Terraform MCP: What It Does for AI agents and What It Doesn't

Terraform engineers who ask AI assistants to write HCL are likely to encounter the same issue: the model confidently invents an argument that was deprecated two provider releases ago, or references a module that doesn't exist in your registry.

That's not a prompting failure. It's due to staleness: the model is pattern-matching against a training snapshot instead of your actual registry. If you want an accurate AI for IaC, the Terraform MCP can close that gap.

In the 2025 Stack Overflow Developer Survey, more developers said they actively distrust the accuracy of AI-generated output (46%) than trust it (33%), and only 3% reported high trust in it. To start trusting its output, you need to ground an agent in live, authoritative data.

This article covers what the Terraform MCP server enables an AI assistant to do, with a step-by-step guide to running it locally and as a centrally hosted service, the configuration a secure production deployment actually needs, and the practices to adopt once you're running it against a real Terraform Enterprise or HCP Terraform organization – at a point where AI IaC tooling is already generating configuration faster than most review processes were built to handle.

However, the server has no view of what's already deployed and no locking finer than Terraform's own state file, so I also cover what it doesn't do.

What is the Terraform MCP server?

The Terraform MCP server provides a direct integration between your AI agent and the Terraform ecosystem. The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and live data sources, instead of leaving them to reason using whatever is in their training set. The Terraform MCP server is HashiCorp's version for the Terraform ecosystem: an open-source MCP server that integrates directly with the public Terraform Registry API and, when configured with credentials, with HCP Terraform and Terraform Enterprise APIs.

Point an MCP-compatible client at it (Claude Code, Claude Desktop, Cursor, VS Code, and several others all speak MCP natively) and the assistant gains a set of callable tools instead of a static snapshot of documentation.

Ask it to configure a resource, and it can query the actual current schema for that provider version, rather than pattern-matching against whatever examples happened to be common in its training data, enabling advanced automation without reducing accuracy.

The server ships as a small Go binary or a minimal Docker image and is licensed under MPL-2.0, so running it costs infrastructure, rather than requiring a subscription.

What AI assistants can do with the Terraform MCP

The server organizes its capabilities into toolsets, and what you enable determines what the connected assistant can see and do.

• Provider tools cover schema and version lookups: an agent can pull the full documentation for a specific resource or data source, or check the latest release of a provider before writing a version constraint.
• Module tools work in the same way, but against the public registry (and, with the right token and the registry-private toolset enabled, your organization's private registry), returning inputs, outputs, and usage examples instead of an agent guessing at a module's interface.
• Policy tools surface Sentinel policy listings and details, so an assistant can find what governance already exists before it drafts a new one.
• The HCP Terraform and Terraform Enterprise tools can list organizations and projects, read workspace configuration and variable sets, inspect run history, and create runs, and (behind an explicit opt-in flag covered below) apply or destroy them and create, update, or delete workspaces.

Combined with the module and provider tools, the agent can author configuration against the schema your provider version expects, using modules your organization has approved, aware of the workspace variables and policies.

Using Terraform MCP for multi-cloud provisioning

"Multi-cloud" here doesn't mean the server orchestrates across providers itself. It means the same toolset works identically regardless of which provider you're targeting, as the schema and module lookups are provider-agnostic by design.

Ask an assistant to write the configuration for a compute instance, and it calls the provider tools for whichever cloud is relevant, whether that's Google Cloud, AWS, Azure, or a smaller provider. The mechanism doesn't change: it fetches the current provider version, then pulls the resource schema before generating HCL against it.

The boundary also doesn't change. The server has no live inventory of what's actually running in any of those accounts. It can tell an agent exactly what arguments are required by a google_compute_instance block; it can't tell the agent what compute instances already exist, which ones are unmanaged, or what a proposed change would actually affect once applied.

A 5-step Terraform MCP implementation guide

Prerequisites

You need Docker installed and running, plus an MCP-compatible AI assistant that can sit alongside your existing Terraform CLI workflow. Add an HCP Terraform or Terraform Enterprise API token if you want workspace or run tools. Registry-only usage (provider and module lookups) needs no token at all.

Step 1: Run the server locally over stdio

If you are a single developer running an assistant locally, choose Stdio transport. In Claude Code, adding the server is a one-line command:

For MCP clients that take a JSON config block, whether that is VS Code, Claude Desktop, or Cursor, the equivalent is:

At this point, the assistant can query the public registry: provider schemas and current versions, module details and usage examples, plus whatever Sentinel policies are published there – no credentials, no workspace visibility, nothing that touches your Terraform Enterprise installation or HCP Terraform organization.

Step 2: Add HCP Terraform or Terraform Enterprise credentials

To unlock workspace, run, and variable-set tools, pass a scoped API token and your Terraform address as environment variables, and enable the Terraform toolset (the server loads registry tools only by default):

Scope that token to the narrowest set of workspaces the assistant genuinely needs. A team-level token is better than an owner-level one, and there's no workflow benefit to handing a coding assistant more reach than it requires to complete its task.

Step 3: Scope which tools the agent can use

By default, the server enables the registry toolset only, which is why Step 2 adds the terraform toolset. To change what's enabled, use the --toolsets flag:

For tighter control, allowlist individual tools instead of a whole toolset:

The smallest toolset that gets the job done is also the safest one. An assistant that only needs to look up provider schemas has no business holding tools that can list every workspace in your organization.

Step 4: Move to streamable HTTP for a shared deployment

Stdio is a one-process-per-developer model. For a team sharing one hosted server, switch to streamable HTTP transport (TRANSPORT_MODE will enable HTTP transport):

This example runs plain HTTP and is for local testing only. Before exposing it to a team, add TLS and origin restrictions (see the production section below). Confirm it's up before pointing a client at it:

Then point a client at the endpoint. In Claude Code:

Step 5: Verify with a real request

Ask the connected assistant something with a verifiable, current answer, like the latest version of a specific provider, or the required arguments for a resource that's changed recently.

If the response reflects the live registry rather than a stale, memorized pattern, the connection is working. Treat this check the same way you'd treat a Terraform dry run before a real apply: cheap, quick, and worth doing before you trust the output.

Terraform MCP best practices for enterprise infrastructure as code

Here are some of the best practices to follow when using an MCP to help manage your enterprise IaC:

• Leave ENABLE_TF_OPERATIONS off by default. It applies to the whole server instance, so if one workflow genuinely needs write access, run a separate instance for it and keep the shared server read-only.
• Scope every token to the team or workspace it's meant to serve rather than issuing one organization-wide credential to a shared server; a leaked token should cost you a workspace's worth of blast radius, not an org's.
• The server ships with default instructions that shape how connected models reason about your Terraform practices. If those defaults don't match how your platform engineering team works, replace them with your own instructions file and rebuild the container or binary; there's no runtime setting for this.
• Keep policy enforcement in the loop rather than treating it as something an AI-authored change can skip. If your organization runs Sentinel or OPA-based policy checks alongside IaC security scans ahead of every human-authored Terraform plan, an agent-generated one should go through an identical process.

AI-generated HCL should never be exempted from the same governance a person's pull request would face, so make sure your platform engineering team doesn't treat the two paths differently.

The best Terraform MCP setup for secure production deployments

A production deployment is a network service with access to your Terraform Enterprise support contract or HCP Terraform organization, and it should be hardened like one.

Terminate TLS at the server (MCP_TLS_CERT_FILE and MCP_TLS_KEY_FILE); the documentation marks this as required for any deployment beyond localhost.

Restrict MCP_ALLOWED_ORIGINS to the specific clients that should be able to connect, and set MCP_ORGANIZATION_ALLOWLIST so the server only accepts requests from users whose own token can access at least one of the organizations you list.

It's a check at the door, not a cap on what a token can reach afterwards, so token scoping is still important.

For a server shared across a team, use per-user token passthrough (an Authorization: Bearer header) rather than one shared credential baked into the deployment.

Each caller's request then runs under their own HCP Terraform or Terraform Enterprise permissions, which means role-based access control still applies even though an AI assistant is the one making the call.

The server backs this up with a couple of guarantees: it rejects tokens passed as query parameters outright, and in streamable HTTP mode a client can't override the server's configured TFE_ADDRESS, helping to prevent a credential-redirection attack where a malicious client tries to point your token at a server it doesn't recognize – which is just one way using this MCP tool reduces your attack surface.

Rate limiting (MCP_RATE_LIMIT_GLOBAL and MCP_RATE_LIMIT_SESSION) protects the underlying registry and Terraform Cloud APIs from a runaway agent loop, which is a failure mode that appears once an assistant starts iterating on a plan.

If you're behind a corporate proxy doing TLS inspection, mount your corporate CA certificate into the container and point the SSL_CERT_FILE variable at it, rather than disabling verification; the Terraform security posture you'd expect from any other internal service applies here too.

The risks of putting an AI agent in your Terraform workflow

MCP reduces hallucination, but it doesn't eliminate the need to review what comes out the other end. The output deserves the same scrutiny you'd give a junior engineer's pull request, not a rubber stamp because a schema-aware tool produced it.

ENABLE_TF_OPERATIONS is the specific line to watch: it switches on the tools that let an agent apply or destroy runs, auto-approve plans, and create, update, or delete workspaces. Leave it off, and those tools stay unavailable, though the agent can still read workspace data

Treat that flag with exactly the caution you'd give any CI system holding apply permissions.

The Terraform MCP server's scope stops at the Terraform model: schemas, docs, module metadata, workspace and run APIs. As covered earlier, it can't see what's deployed. It also has no resource-level locking or blast-radius analysis before a change lands.

This limitation can become a risk once MCP-authored changes start flowing through the same workspace from multiple agents, or from an agent and a human CI pipeline running in parallel: standard Terraform locks the whole state file, not the specific resources a given change touches.

You need to give your AI-authored workflow that discipline from somewhere, as MCP was never built to provide it.

Stategraph approaches this on two fronts to improve your organization's security and make sure you hit your compliance requirements.

1. Storage and execution: the dependency graph lives in a database, and graph-aware execution runs only against the subgraph a change affects, which means resource-level locking instead of a single whole-state lock, along with cross-state transactions and blast-radius visibility before anything applies.
2. The credential itself: a token can be scoped to plan-only versus apply, and to a specific resource-address pattern within a single state, so a confused or jailbroken agent can produce a wrong plan but has no path to an apply outside what that token was minted for.

Because the flag is all-or-nothing, the credential is the actual boundary: scope it so the agent can't argue its way past it, however the flag is set.

Conclusion

The Terraform MCP server helps prevent AI assistants from guessing at provider schemas and module interfaces by giving them a live connection to the registry and, optionally, your HCP Terraform or Terraform Enterprise organization.

It's simple to run from a laptop and straightforward to host centrally for a team, provided you treat the hardening options (TLS, allowlists, scoped tokens, ENABLE_TF_OPERATIONS) as requirements rather than defaults to leave alone.

What it can't do is give you any visibility into blast radius or any locking finer than Terraform's own state file. Try Stategraph free to see what graph-aware execution looks like underneath a Terraform or OpenTofu workflow, AI-authored or otherwise.

Terraform MCP FAQs

Does Terraform MCP work with OpenTofu?

The server's tools query the public Terraform Registry and HCP Terraform or Terraform Enterprise APIs specifically; nothing in the official documentation references OpenTofu's registry, as it's different from the Terraform provider.

Since OpenTofu consumes a compatible registry protocol, provider and module lookups will often return usable results in practice, but treat it as a Terraform Registry tool first rather than assuming full OpenTofu registry parity.

Can Terraform MCP see infrastructure that's already deployed?

No. It returns schemas, module metadata, and HCP Terraform or Terraform Enterprise workspace and run data, none of which includes a live inventory of deployed resources. It can tell you what a resource block should look like, but it can't tell you what's actually running in your accounts right now.

Is the Terraform MCP server free to use?

Yes. It's open source under MPL-2.0, distributed as a binary or Docker image with no license cost. You're responsible for hosting it and securing the deployment yourself, which the setup and security sections above cover.