Cloud & InfrastructureFreeactiveReviewed by MCPIndex

Terraform MCP

Official HashiCorp MCP server for live Terraform provider schemas, modules, policies, and HCP Terraform context.

Looking for more MCP servers? Browse the full MCP tools directory or explore more tools in Cloud & Infrastructure.

Quick overview

Terraform MCP solves the most expensive hallucination in infrastructure automation: a provider argument that looks right, compiles nowhere, or silently creates the wrong resource shape. Instead of relying on model memory or stale snippets, the server exposes current Terraform Registry provider schemas, module metadata, policy context, and HCP Terraform workspace information. The architectural distinction matters: it is primarily a schema-and-governance intelligence layer, not a license to run terraform apply against production. An agent can resolve the exact provider version, inspect required arguments, compare module constraints, and explain policy failures using live registry context before generating a plan. The hidden edge case is version drift between the provider lockfile, Terraform CLI, HCP workspace, and documentation corpus; a schema lookup can be accurate for the wrong constraint. Pin provider versions, echo workspace and organization IDs, and require plan output plus policy checks before any mutation. Terraform MCP is valuable because it makes infrastructure contracts current; it is safe only when Terraform's plan, state locking, and approval workflow remain authoritative.

What this MCP server is best for

  • Managing infrastructure and operational workflows with Terraform MCP.
  • Inspecting environments, services, and cluster resources directly from an MCP client.
  • Helping DevOps teams reduce context switching during debugging and deployment tasks.

When to choose it

Choose Terraform MCP when you want an MCP server focused on Cloud & Infrastructure and need tighter integration with your existing tools.

Good fit

terraformhashicorpinfrastructure-as-codehclprovidersmodules

Terraform MCP Configuration

Use the following configuration as a starting point for Claude Desktop or any compatible MCP client, then replace placeholder credentials with your own values.

claude_desktop_config.json
{
  "mcpServers": {
    "terraform": {
      "command": "terraform",
      "args": ["mcp-server"]
    }
  }
}

How to set up Terraform MCP

These setup steps cover the typical installation flow for this MCP server.

  1. 1

    Install a supported Terraform CLI version and verify terraform version before adding the MCP server.

  2. 2

    Configure the server for documentation, registry, and HCP Terraform access as required; keep workspace mutations disabled for initial evaluation.

  3. 3

    Pro-Tip: The fatal flaw 90% of developers commit is generating configuration from the latest provider schema while the repository lockfile pins an older provider. The result can pass superficial review and fail at init or plan, or worse, change resource semantics. Read required_providers and .terraform.lock.hcl first, resolve the exact version, and compare the schema against that constraint before writing HCL.

  4. 4

    Ground every workspace operation with organization, workspace, branch, and run identifiers; names alone are unsafe across HCP Terraform teams.

  5. 5

    Require terraform fmt, validate, plan, policy checks, and human approval before apply. Never treat generated HCL as an applied change.

  6. 6

    Verify with: resolve the provider version, inspect one resource schema, and show the workspace's current run and policy state.

Frequently asked questions

Common questions for Terraform MCP.

The generated Terraform is valid HCL but plans a destructive replacement — no syntax error appeared. Why?

The silent failure is semantic schema or state drift. The configuration is syntactically valid, but provider version, lifecycle arguments, state, or imported resource identity differs from the agent's assumptions. Terraform correctly proposes a replacement. The engineering fix is to inspect the exact provider lockfile, current state, plan actions, lifecycle settings, and policy results; block any replace or destroy action until a human confirms the blast radius.

Terraform MCP vs cloud-provider MCP servers?

Terraform MCP reasons about desired infrastructure, provider schemas, modules, policies, and workspace runs; AWS or Azure servers inspect live resources directly. Use Terraform MCP for IaC contracts and plans, and cloud-specific servers for runtime state and incidents.

Can it run terraform apply?

Capabilities depend on the deployment and HCP Terraform permissions, but production apply should remain outside an autonomous MCP session. Use the server to generate and explain plans, then apply through reviewed CI or an approval workflow.

Why do provider examples fail after generation?

The example may target another provider version, resource mode, or module constraint. Read the lockfile and resolve the exact provider schema before relying on documentation examples.

Terraform MCP vs Competitors

FeatureTerraform MCPCompetitor
Provider freshness Live Registry schemas, modules, and policies Model memory or stale blog examples
IaC governance Workspace runs and policy context Cloud API connectors see resources but not desired-state workflow
Runtime state Limited to Terraform and workspace context Cloud-native tools inspect live service telemetry
Mutation safety Plan and policy workflow still requires external approval Read-only cloud inspection has a narrower surface

Related Guides