The Terraform Engine MCP Server enables AI agents and clients to manage Terraform-based infrastructure through a set of MCP tools. It supports:
List Tasks: Browse registered Terraform templates, with optional filtering by category (e.g., database, compute) or provider (e.g., AWS, Azure, GCP).
Get Task Schema: Retrieve metadata and JSON input schema for a specific task to understand required variables.
Provision Task: Deploy a new infrastructure environment by providing a task name, unique deployment name, and input payload; triggers an asynchronous Terraform apply.
Get Deployment Status: Check the current status, configuration, and outputs of any deployment.
Destroy Deployment: Tear down and delete a deployment, with built-in dependency checks to prevent removal of parent resources if active child deployments exist.
Additionally, the server exposes a REST API, a modern UI dashboard, and an integrated AI chat interface with multi-provider LLM support. It operates in both local (STDIO) and network (SSE) MCP modes, featuring async execution, caching, and a deterministic FSM orchestrator for safe, efficient infrastructure management.
Provides tools for managing Terraform templates (tasks) and deployments, including provisioning, updating, and tearing down infrastructure.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Terraform Engine MCP Server show deployment status for 'prod'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A premium, lightweight, production-ready, self-hosted infrastructure orchestrator with an integrated AI Chat Interface. The engine provides administrative controls to register Terraform templates (called Tasks) and exposes a REST API along with a modern, glassmorphic dashboard and an AI-powered conversational interface to provision, update, and teardown environments (called Deployments) asynchronously.
FastAPI Core: Ultra-fast endpoints for registering tasks and managing deployments.
Async Execution: Arq worker backing (with process-level Mock fallback if Redis is missing).
Two-Tier Caching: Near-instantaneous terraform init runs with global provider and module caching.
Glassmorphism UI: Beautiful, fully responsive theme-aware dashboard (Light & Dark mode).
AI Chat Interface: Built-in conversational assistant powered by Groq, OpenAI, or custom/on-prem LLMs (Ollama, vLLM) with automatic MCP tool calling.
FSM AI Orchestrator: Deterministic Finite-State-Machine (FSM) orchestrator with Redis session persistence, single-purpose LLM subtask nodes, and structural guardrail enforcement.
Comprehensive API: Supports PATCH updates, clean DELETE teardowns, cross-user lookups, and dependency-safe deletion with impact analysis.
MCP Server Support: Exposes local (STDIO) and remote/network (SSE) tools for AI agents (ChatGPT, Claude, Cursor) to manage the infrastructure.
Dependency-Safe Deletion: Automatic dependency detection on deployment deletion — blocks destruction of parent resources (e.g., Subnets, VNets) when active child deployments depend on them (HTTP 409 Conflict with impact report).
Zero-clutter Workspace: Standard directory package hierarchy ready for GitHub and cloud hosting.
Related MCP server: Homelab MCP Server
.github/
workflows/
ci.yml # Automated GitHub Actions testing flow
PULL_REQUEST_TEMPLATE.md # Standard pull request format
ISSUE_TEMPLATE/ # Structured bug and feature templates
app/ # Main application package
agent/ # FSM Orchestrator, Session State, LLM Client, and Nodes
core/ # Configurations, Auth, Database, Queue
models/ # SQLAlchemy database tables
schemas/ # Pydantic validation schemas
api/ # API endpoint routers (Admin, Public, Lifecycle, Chat)
frontend/ # Jinja2 HTML page router
static/ # Static CSS assets
templates/ # Layouts, dashboard panels, and AI chat interface
docs/ # Detailed architectural design documents
tests/ # Re-organized pytest test suites
pyproject.toml # UV-based Python build description
README.md # Project runbookSee docs/architecture.md for a detailed deep-dive into the architecture, caching schemes, AI orchestration, guardrails, and lifecycle state workflows.
Python: 3.12 or higher.
Terraform CLI: Locally installed and configured.
Redis Server (Optional): Used by arq for background queues and real-time catalog caching. Falls back to in-process mock if absent.
LLM API Key (Optional): A Groq, OpenAI, or custom API key for the AI Chat Interface.
This project is configured using uv for fast, reliable package management.
Install dependencies and create virtual environment:
uv syncActivate virtual environment:
On Windows:
.venv\Scripts\activateOn macOS/Linux:
source .venv/bin/activateConfigure environment variables (create a .env file):
# LLM Provider (groq, openai, or custom)
LLM_PROVIDER=groq
LLM_MODEL=llama-3.3-70b-versatile
GROQ_API_KEY=your-groq-api-key
# Optional: OpenAI
# OPENAI_API_KEY=your-openai-key
# Optional: Custom/On-Prem (Ollama, vLLM)
# LLM_BASE_URL=http://localhost:11434/v1
# LLM_API_KEY=not-needed
# Token Optimization (recommended for free-tier APIs)
TOKEN_OPTIMIZATION_MODE=true
MAX_HISTORY_TURNS=2Launch the FastAPI development server:
uv run uvicorn app.main:app --port 8080 --reloadAccess the application:
Interactive UI Dashboard: http://127.0.0.1:8080/
AI Chat Interface: http://127.0.0.1:8080/chat
Swagger API Docs: http://127.0.0.1:8080/docs
In a separate terminal, launch the arq worker:
uv run arq app.worker.WorkerSettings(If Redis is not running, the web server falls back to running tasks in-process asynchronously using MockArqRedis, so you do not strictly need to start a separate worker for local testing).
The built-in AI Chat provides a conversational interface for infrastructure management. It supports:
Multi-Provider LLM Support: Groq (free Llama-3.3), OpenAI (GPT-4o), or any OpenAI-compatible endpoint (Ollama, vLLM, LocalAI).
Automatic Tool Calling: The LLM autonomously calls list_tasks, get_task_schema, provision_task, get_deployment_status, list_deployments, and destroy_deployment via the MCP tool definitions.
11 Strict Operational Guardrails: Prevent hallucinated deployments, enforce schema validation before provisioning, resolve deployment-name-to-resource-name references, block dependent resource deletion, and more.
Token-Optimized History: Sliding-window pruning (configurable turns) with tool-result compression for low-TPM APIs.
Dynamic Catalog Awareness: System prompt auto-populates recognized categories and providers from Redis cache at zero latency.
This project exposes its tasks and deployments as tools through an MCP server. This allows AI clients (like ChatGPT Desktop, Claude Desktop, or Cursor) to inspect schemas and deploy infrastructure directly.
Configure your local AI client to launch the MCP server as a subprocess:
Command: uv
Arguments: run --project "/path/to/project" python "/path/to/project/app/mcp_server.py"
(Note: Ensure the FastAPI web server is also running locally so the MCP server can forward requests to the API endpoints).
When you start the FastAPI web server, the MCP server is automatically mounted and exposed via Server-Sent Events (SSE) at:
http://<YOUR_IP_ADDRESS>:8001/mcp/sseOther devices on the same network can connect to this endpoint directly without needing to launch a local Python command.
To run the automated pytest suite (which covers task creation, validation, provisioning, update patches, teardown lifecycles, and dependency blocking):
uv run pytestAll tests execute against an isolated test database test_tasks.db and clean up dynamic execution files automatically.
Tear down and delete an existing deployment by its name.
Args:
deployment_name: The name of the deployment to destroy.
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior but only states the action. It omits critical details such as whether the deletion is irreversible, what happens to associated resources, and required permissions. For a destructive tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant information, and front-loads the core action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive and has no annotations, the description is too sparse. It lacks essential context such as irreversibility, impact on related resources, and failure conditions. The existence of an output schema does not compensate for missing safety information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter by stating its role ('the name of the deployment to destroy'), which goes beyond the schema's bare name. However, it does not clarify format, validation rules, or error conditions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (tear down, delete) and the resource (deployment), with the key identifier (by name). It effectively distinguishes from sibling tools like provision_task (create) and get_deployment_status (check status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no warnings about irreversible effects. The agent is left to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status, configurations, and outputs of a deployment by its name.
Args:
deployment_name: The unique name of the deployment to inspect.
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies a read-only operation but does not disclose error handling (e.g., if deployment not found) or permissions needed. Basic transparency is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus an Args line. Purpose is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the basics but lacks integration hints (e.g., check status before destroy) and error scenarios. Output schema is external but not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'deployment_name' has 0% schema coverage, but description adds meaning: 'the unique name of the deployment to inspect'. This compensates well for the trivial parameter type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the current status, configurations, and outputs of a deployment by its name', specifying both the verb (Get) and the resource (deployment), distinguishing it from siblings like list_tasks and destroy_deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., before destroy_deployment) or prerequisites. Only states 'by its name' without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the metadata and input schema (JSON Schema) for a registered task.
Args:
task_name: The unique alphanumeric name of the task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates a read operation ('Get'), but does not disclose potential errors (e.g., task not found) or any side effects. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. The first sentence is a clear one-liner defining the purpose, and the second describes the single parameter. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema available), the description is mostly complete. It covers the basic behavior, but could mention that the task must exist or the tool will return an error. Still adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds 'The unique alphanumeric name of the task.' which clarifies the expected format and uniqueness of the task_name parameter, providing meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the metadata and input schema (JSON Schema) for a registered task.' It uses a specific verb and resource, and naturally distinguishes from sibling tools like list_tasks (which lists tasks) and provision_task (which creates tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving schema but provides no explicit guidance on when to use this tool versus alternatives (e.g., before provisioning). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Terraform tasks (templates) in the registry.
Args:
category: Optional category to filter tasks (e.g. database, network, compute).
provider: Optional cloud provider to filter tasks (e.g. aws, azure, gcp).
Returns:
JSON string representing the list of tasks and their details.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| provider | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the tool returns a JSON string and supports optional filtering, which implies a read-only operation. However, it does not explicitly confirm idempotency or safety, though 'list' implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three clear sections: purpose, Args, Returns. Every sentence adds value, and the structure is front-loaded with the primary action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (though not detailed here), the description adequately covers the return type ('JSON string') and parameter purposes. It does not mention error handling or empty results, but for a list operation with simple filtering, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, but the description adds meaning to both parameters: it explains they are optional filters and provides examples (e.g., 'database, network, compute' for category; 'aws, azure, gcp' for provider). This goes beyond the schema's type and title alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available Terraform tasks (templates) in the registry.' The verb 'list' and resource 'Terraform tasks' are specific, and the scope 'registry' is provided. It distinguishes from siblings like provision_task (deploy) and get_task_schema (schema retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates optional filters (category, provider) but does not explicitly state when to use this tool relative to alternatives. It lacks guidance on prerequisites or situations where listing is appropriate. The sibling names imply differentiation, but the description itself offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provision a new deployment for a given task.
Args:
task_name: The registered task name to deploy.
deployment_name: A unique name for this deployment instance.
payload: JSON object/dictionary containing the variables matching the task schema.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | ||
| task_name | Yes | ||
| deployment_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a write/mutation operation but provides no details on side effects, permissions, idempotency, or failure behaviors. With no annotations, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a single sentence stating the purpose, followed by a bullet list of arguments. No wasted words, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description does not mention return values or usage context (e.g., what happens on success/failure, prerequisites). For a provisioning tool, more context about the result is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds brief parameter explanations (e.g., 'A unique name for this deployment instance'), but these add only minimal meaning beyond the param names. Since schema description coverage is 0%, some compensation is needed, but the descriptions are not particularly insightful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Provision a new deployment for a given task.' It uses a specific verb ('provision') and resource ('deployment for a task'), distinguishing it from siblings like list_tasks or destroy_deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when to avoid it. It provides parameter explanations but no guidance on when to choose this over alternatives like destroy_deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0destroy_deploymentget_deployment_statusget_task_schemalist_tasksprovision_taskScored across 5 tools
Each tool has a clearly distinct purpose: listing tasks, getting task schema, provisioning deployments, checking deployment status, and destroying deployments. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with underscores (e.g., list_tasks, provision_task, destroy_deployment), making them predictable and easy to understand.
Five tools is an appropriate scope for managing Terraform tasks and their deployments: sufficient to cover listing, schema retrieval, provisioning, status checking, and destruction without being overwhelming.
The set covers the main lifecycle (create, read, delete) but lacks a tool to list existing deployments, which is a notable gap for agents that need to manage multiple deployments. Additionally, there is no update or modification capability.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/asadongit/tf-multicloud-app'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
