mcp-server-terraform
This server lets you manage Terraform infrastructure through natural language, translating conversational requests into real Terraform CLI commands.
Core Terraform Workflow
Initialize (
tf_init): Set up a working directory, download providers/modulesValidate (
tf_validate): Check.tffiles for syntax errors without accessing remote APIsPlan (
tf_plan): Preview changes with a structured risk/cost summary, flagging expensive always-on resources (NAT gateways, EKS/RDS clusters, etc.) with estimated monthly costsApply (
tf_apply): Apply changes with a built-in two-step confirmation flowDestroy (
tf_destroy): Tear down infrastructure with the same two-step confirmation gate
State & Resource Management
Outputs (
tf_output): Retrieve output values from current stateState (
tf_state): List, show, move, or remove resources from stateResources (
tf_resource): Import existing cloud resources, taint/untaint for forced recreation, or refresh stateWorkspaces (
tf_workspace): List, show, select, or create workspaces
Diagnostics & Safety
Preflight checks (
tf_preflight): Verify cloud provider authentication before running commandsDrift detection (
tf_drift): Identify resources changed outside of Terraform via a refresh-only plan/tf-diagnoseprompt: Guides Claude through systematic troubleshooting of failuresSafety modes: Restrict available tools to read-only or non-destructive subsets via environment variables
Audit logging: Every tool call logged as JSON with variable values redacted
Dangerous flag blocking: Prevents use of risky Terraform CLI flags
Allows managing Terraform infrastructure, including planning, applying, destroying, inspecting state, detecting drift, importing resources, and more, all through natural language commands.
mcp-server-terraform
A Model Context Protocol (MCP) server that lets Claude manage Terraform infrastructure through natural language.
Run plans, apply changes, inspect state, and diagnose failures — all from a Claude conversation.
What it does
Instead of switching to a terminal to run terraform plan, you can ask Claude:
"Plan the changes in
/infra/stagingand explain what will change"
"Apply it — but only if no resources will be destroyed"
"Show me all the outputs from the prod workspace"
"Something broke after the last apply — diagnose it"
The server translates these into real terraform CLI commands on your machine, with a built-in safety confirmation flow before any destructive operation runs.
Related MCP server: tfmcp
Tools
Tool | Description | Destructive |
| Initialize a Terraform working directory | No |
| Validate configuration syntax | No |
| Run a plan and return the diff + risk/cost summary | No |
| Apply changes (requires | Yes |
| Destroy infrastructure (requires | Yes |
| Read output values from state | No |
| List, show, move, or remove state entries | Partial |
| List, show, select, or create workspaces | No |
| Check provider CLI authentication before running | No |
| Detect resources changed outside Terraform | No |
| Import, taint, untaint, or refresh resources | Yes |
Plan risk & cost summary
Every plan (and every apply preview) is analyzed via terraform show -json and
annotated with a structured summary — destroyed resources are called out, and
always-on resources that commonly cause bill shock are flagged with rough
monthly costs:
── Plan Summary ──
+ 3 create, ~ 1 update, - 0 destroy, ± 0 replace
💸 EXPENSIVE — always-on resources being created:
⚠ aws_nat_gateway.main (~$32/month + data processing if left running)
Remember to tf_destroy when you're done experimenting.Cost-flagged resource types include NAT gateways, load balancers, EKS/AKS/GKE control planes, RDS/Cloud SQL instances, ElastiCache, Redshift, MSK, and Azure Firewall (~$900/month!).
Drift detection
tf_drift runs a refresh-only plan and reports resources that were changed
outside Terraform (e.g. manually in the cloud console), with the changed
attribute names and remediation options.
Audit logging
Set AUDIT_LOG_PATH to a file path and every tool call is appended as a JSON
line with timestamp, tool name, outcome, and duration. Variable values are
always redacted (db_password=<redacted>) — only names are logged.
Confirmation flow
tf_apply and tf_destroy use a two-step safety flow:
First call (no
confirmed) → runsterraform plan, shows the diff, does nothing elseSecond call (
confirmed: true) → actually applies or destroys
Claude is instructed to never pass confirmed: true without first presenting the plan to you.
Prompt
The server exposes a /tf-diagnose prompt that guides Claude through a systematic 5-step diagnosis of plan or apply failures.
Prerequisites
Node.js 18 or later
Terraform CLI on your PATH
Claude Desktop (or any MCP-compatible client)
Installation
No install needed — run it straight from npm:
npx @rajsir/mcp-server-terraformOr, for development, from source:
git clone https://github.com/RajeevSirohi/mcp-server-terraform.git
cd mcp-server-terraform
npm install
npm run buildClaude Desktop setup
Add to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"terraform": {
"command": "npx",
"args": ["-y", "@rajsir/mcp-server-terraform"]
}
}
}(If running from source instead, use "command": "node" with "args": ["/absolute/path/to/dist/index.js"].)
Restart Claude Desktop. You should see a hammer icon indicating tools are available.
Usage
Once connected, just talk to Claude about your Terraform workspaces in plain language. Some examples:
First time in a new workspace
"Initialize the terraform config in
C:\infra\stagingand check if I'm logged into the right cloud accounts"
Claude runs tf_init, then tf_preflight — if you're not authenticated it tells you exactly which command to run (az login, aws configure, ...).
The everyday plan → review → apply loop
"Plan the changes in
C:\infra\stagingand explain what will change"
You get the plan diff plus a summary: how many resources created/updated/destroyed, anything destructive called out explicitly, and cost warnings for expensive always-on resources.
"Looks good, apply it"
Claude shows the plan preview one more time and asks for your confirmation — nothing is applied until you say yes. This two-step gate is built into the server itself, not just the prompt, so Claude cannot skip it.
Checking on your infrastructure
"Did anyone change anything outside terraform in the prod workspace?"
tf_drift compares state against reality and reports what was modified in the console, with options to accept or revert.
"Show me all the outputs" · "List everything in state" · "What workspaces exist?"
Learning / experimenting (e.g. cert prep)
"Apply the VPC lab in
C:\labs\vpc, and when I say 'done' destroy everything"
The cost flags are your friend here — if a lab creates a NAT gateway or EKS cluster, the plan summary warns you what it costs per month if forgotten:
💸 EXPENSIVE — always-on resources being created:
⚠ aws_nat_gateway.main (~$32/month + data processing if left running)
Remember to tf_destroy when you're done experimenting.Fixing things
"terraform plan is failing in
C:\infra\staging— diagnose it"
The /tf-diagnose prompt walks Claude through validate → providers → plan → state → outputs systematically. There's also /tf-login for step-by-step authentication setup per provider.
"Import the S3 bucket
my-legacy-bucketinto state asaws_s3_bucket.legacy"
"Taint the web server so it gets recreated on the next apply"
Recommended setup for shared or cautious environments
Run with ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true (see Safety modes below) so apply/destroy are unavailable entirely, and set AUDIT_LOG_PATH so every operation is logged.
Safety modes
Control which tools are available via environment variables:
Variable | Effect |
| Only |
| Blocks |
| Explicit comma-separated allowlist |
Example — read-only mode:
{
"mcpServers": {
"terraform": {
"command": "node",
"args": ["/path/to/dist/index.js"],
"env": {
"ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS": "true"
}
}
}
}Development
npm run dev # watch mode (recompiles on save)
npm test # run tests
npm run build # production buildProject structure
src/
index.ts # MCP server entry point, tool registration
config/ # (reserved for future config/telemetry)
models/
common-parameters.ts # Shared Zod schemas
security/
tf-flags.ts # Dangerous flag blocking
tools/
tf-init.ts
tf-validate.ts
tf-plan.ts
tf-apply.ts # Two-step confirmation flow
tf-destroy.ts # Two-step confirmation flow
tf-output.ts
tf-state.ts
tf-workspace.ts
utils/
terraform-runner.ts # Core exec wrapper, workspace switching
prompts/
index.ts # /tf-diagnose prompt
tests/
tf-flags.test.ts
tf-apply.test.tsAdding a new tool
Create
src/tools/tf-yourcommand.ts— export a*Schemaconst and an async handler functionImport both in
src/index.tsAdd the schema to
readonlyToolsordestructiveToolsarrayAdd a
casein theCallToolRequestSchemahandler switch
Roadmap
Terraform Cloud / Enterprise API support (Phase 2)
OpenTelemetry tracing
SSE / streamable HTTP transport for remote deployments
Docker image on GitHub Container Registry
Plan risk & cost analysis
Drift detection
Import / taint / untaint / refresh
Audit logging
CI (build, test matrix, e2e against real terraform)
Contributing
See CONTRIBUTING.md.
License
MIT — see LICENSE.
Maintenance
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RajeevSirohi/mcp-server-terraform'
If you have feedback or need assistance with the MCP directory API, please join our Discord server