MCP field guide / Terraform
// mcp field guide · infrastructure
A common assumption is that "the Terraform MCP" just searches the registry. HashiCorp's official server does that — and, with one flag, it can trigger plan, apply, and destroy runs against real, state-managed infrastructure. A destroy run is the highest-blast-radius, non-compensable action in all of infra tooling. Here's the sourced split.
GUARD FIT · REGISTRY / READS
PASS-THROUGHSearch providers/modules, pull docs, read workspaces/runs/state. No infra change — genuinely safe.
GUARD FIT · APPLY / DESTROY
STRONGApply changes or destroy real infra — a destroy can delete prod databases, networks and their data. Not compensable.
Overall fit: STRONG when ENABLE_TF_OPERATIONS=true — this is not registry-only.
The server groups tools into three toolsets — registry, registry-private, and terraform (HCP Terraform / TFE) — and a global flag ENABLE_TF_OPERATIONS (default false) gates the most dangerous actions. Mode one is read-only registry/docs (search providers, modules, policies; pull current docs so generated HCL isn't hallucinated from stale training data). Mode two manages HCP Terraform / Terraform Enterprise — list/create workspaces, manage variables and policy sets, and trigger runs, including plan, apply, and destroy.12
| Tier | Tools |
|---|---|
| read-only | Registry: search_providers, get_provider_details, search_modules, get_module_details, search_policies. HCP reads: list_workspaces, get_run_details, get_plan_json_output, list_state_versions, get_state_version; create_run with plan_only (produces a plan, changes nothing) |
| mutating (flag-gated) | create_run with plan_and_apply, action_run (apply/discard/cancel), create_workspace/update_workspace, variable & policy-set management |
| destructive (flag-gated) | create_run with is_destroy (a destroy plan — tears down all infra a workspace manages; auto_approve skips the human gate), action_run applying a destroy, delete_workspace_safely, force_unlock_workspace, delete_project/delete_team |
Honest naming note: there is no local terraform state rm/mv and no local-CLI plan/apply/destroy — state is HCP-managed, and state tools here are read-only. Destruction is expressed as a destroy run (create_run is_destroy + apply), not a state edit. The exact set of tools individually gated by ENABLE_TF_OPERATIONS vs. always-available drifts — verify against your version.
Grounded IaC authoring. Search the registry for the correct provider/module and pull current argument docs before writing HCL (the safe majority).
Agentic provisioning. Create/configure an HCP Terraform workspace, set variables, kick off a plan_and_apply run for a new environment.
Drift / teardown. Trigger a plan to inspect drift, or a destroy to decommission an ephemeral environment — the sharp edge.
Registry / reads → pass through. Genuinely safe; classify read-only and don't gate.
Apply / destroy → strong — the purest infra case. An apply or a destroy against real, state-managed infrastructure is the single highest-blast-radius action class in all of infra tooling: a destroy run can delete production databases, networks, and their data. This is exactly the surface a human-approval + impact-diff gate is built for.
The honesty match is total: a Terraform destroy is not compensable — deleted cloud resources and their data are gone; re-applying recreates new resources, it doesn't restore the old ones. That's compensation ≠ reversal in its purest form. HashiCorp already ships a coarse version of the guard — ENABLE_TF_OPERATIONS and guidance to keep manual approval on runs — which validates the need; a guard adds the per-call impact diff, risk classification, multi-approver quorum, and hash-chained audit the env-var flag lacks.
ChronoMCP passes the registry/read surface through and holds apply/destroy runs for a human — flagged honestly as non-reversible.
Read the quickstart → More MCP profilesENABLE_TF_OPERATIONS): github.com/hashicorp/terraform-mcp-serverProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with HashiCorp. Tool names are from HashiCorp's docs reference and the repo's toolset mapping; the exact per-tool flag gating and current version are noted as version-dependent/unverified. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.