Provides comprehensive tools for managing Terraform Infrastructure as Code operations, including initialization, planning, applying changes, state management, workspace management, provider operations, and configuration file editing.
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 MCP Server show me what changes would be made if I apply my current terraform config"
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.
Model Context Protocol (MCP) server for Terraform Infrastructure as Code operations. Provides 25 comprehensive tools for managing Terraform configurations, state, workspaces, and executing infrastructure operations.
tf_version - Get Terraform version information
tf_init - Initialize Terraform working directory (with optional provider upgrades)
tf_validate - Validate Terraform configuration syntax
tf_plan - Create execution plan showing proposed changes
tf_apply - Apply Terraform changes to infrastructure
tf_destroy - Destroy Terraform-managed infrastructure
tf_output - Get Terraform output values (JSON or plain text)
tf_state_list - List all resources in Terraform state
tf_state_show - Show detailed information for a specific resource
tf_state_rm - Remove a resource from Terraform state
tf_state_mv - Move/rename a resource in Terraform state
tf_import - Import existing infrastructure into Terraform state
tf_refresh - Refresh Terraform state from real infrastructure
tf_fmt - Format Terraform configuration files (check or modify)
tf_workspace_list - List all Terraform workspaces
tf_workspace_select - Switch to a different workspace
tf_workspace_new - Create a new workspace
tf_workspace_delete - Delete a workspace
tf_providers - List Terraform providers in use
tf_graph - Generate resource dependency graph in DOT format
tf_taint - Mark a resource for recreation on next apply
tf_untaint - Remove taint marking from a resource
tf_show_plan - Show details of a saved execution plan file
tf_list_files - List Terraform files in a directory (.tf, .tfvars, .tfstate)
tf_read_file - Read contents of a Terraform configuration file
tf_write_file - Write content to a Terraform configuration file
Related MCP server: CLP MCP - DevOps Infrastructure Server
npm install
npm run buildThe server uses an optional environment variable to set the default working directory:
export TERRAFORM_WORKING_DIR="/path/to/your/terraform/projects"If not set, the server will use the current working directory.
Add to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"terraform": {
"command": "node",
"args": ["/path/to/mcp-terraform/dist/index.js"],
"env": {
"TERRAFORM_WORKING_DIR": "/path/to/terraform/projects"
}
}
}
}Run in development mode with hot reload:
npm run devTerraform CLI must be installed and available in your PATH
Appropriate cloud provider credentials configured (AWS, Azure, GCP, etc.)
Terraform working directory with configuration files
Infrastructure Planning: Review changes before applying them
State Management: Import existing resources, move resources between modules
Workspace Management: Manage multiple environments (dev, staging, prod)
Code Quality: Format Terraform files consistently
Troubleshooting: Inspect state, visualize resource dependencies
Selective Operations: Apply changes to specific resources using targets
Configuration Management: Read and modify Terraform configuration files
dir (optional): Working directory for Terraform operations. Defaults to TERRAFORM_WORKING_DIR or current directory
auto_approve (optional): Skip interactive approval for apply/destroy operations
target (optional): Limit operations to specific resources (e.g., aws_instance.example)
var (optional): Pass variables to Terraform commands (object with key-value pairs)
{
"dir": "/path/to/project",
"out": "plan.tfplan",
"target": "aws_instance.web",
"var": {
"region": "us-west-2",
"instance_type": "t3.micro"
}
}{
"dir": "/path/to/project",
"address": "aws_instance.example",
"source": "aws_instance.old_name",
"destination": "aws_instance.new_name"
}The server executes Terraform commands with full permissions
Ensure proper access controls on the working directory
Be cautious with auto_approve flag on apply/destroy operations
Store sensitive variables in Terraform variable files or environment variables, not in plain text
Review plans carefully before applying changes to production infrastructure
Most commands return plain text output from Terraform CLI
Use json: true with tf_output for structured JSON responses
State operations return formatted resource information
Graph operations return DOT format for visualization tools
The tf_graph tool generates dependency graphs in DOT format. Use tools like Graphviz to visualize:
# Save graph output to file
terraform graph > graph.dot
# Generate PNG image
dot -Tpng graph.dot -o graph.pngThe server captures both stdout and stderr from Terraform commands. Failed operations return error messages with exit codes for troubleshooting.
For detailed Terraform CLI documentation, see: https://developer.hashicorp.com/terraform/cli
MIT
Contributions are welcome! Please feel free to submit a Pull Request.
Apply Terraform changes
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| auto_approve | No | ||
| plan_file | No | Apply saved plan | |
| target | No | ||
| var | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. 'Apply Terraform changes' does not disclose that this tool typically modifies infrastructure, may require confirmation, or can be destructive. No mention of side effects like state file updates or resource creation/deletion.
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 overly minimal (three words) and lacks any structure. While short, it is not concise because it omits critical information. Front-loading is not applicable as there is no content to front-load.
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 has 5 parameters with low schema coverage, no output schema, and no annotations, the description is severely incomplete. It fails to explain how to use complex parameters like 'var' (object) or 'target', and does not mention return values or error conditions.
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 only 20% (only plan_file has a description). The description adds no meaning beyond the parameter names. For instance, 'dir', 'auto_approve', 'target', and 'var' remain completely undocumented, leaving the agent without guidance on their purpose or format.
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 states 'Apply Terraform changes' which identifies the verb and resource, but it's too vague given the many sibling tools like tf_plan, tf_destroy, etc. It does not specify what 'Apply' entails (e.g., executing a plan, creating resources) nor how it differs from generating a plan.
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 vs alternatives like tf_plan (to preview changes) or tf_destroy (to tear down). Does not mention prerequisites such as having a generated plan or initialized working directory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy Terraform resources
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| auto_approve | No | ||
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fails to disclose destructive consequences, need for approval, or irreversibility. With no annotations, it carries full burden but offers minimal behavioral insight.
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 overly brief (three words), sacrificing helpfulness for brevity. It is under-specified rather than concise.
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?
For a dangerous tool like Terraform destroy, the description provides no details on behavior, output, or parameter effects. It is completely inadequate for an AI agent to safely invoke the tool.
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%, and the description adds no meaning to the parameters (dir, auto_approve, target). It does not compensate for the missing schema documentation.
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 'Destroy Terraform resources' uses a specific verb and resource, clearly stating the tool's purpose. It effectively distinguishes from sibling tools like tf_apply and tf_plan.
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 is provided on when to use this tool versus alternatives, such as tf_taint for targeted resource recreation. The description lacks any contextual usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format Terraform files
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| check | No | Check only, don't modify | |
| recursive | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only says 'Format Terraform files'. It doesn't mention file modification, check-only mode (though schema mentions check), or any side effects. Significant behavioral gaps.
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?
Single sentence is concise but too brief to be helpful. It sacrifices necessary detail for brevity, making it minimally adequate.
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 three parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool does in enough detail (e.g., it's equivalent to `terraform fmt`), leaving agents underinformed.
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 only 33% (check described in schema). The description adds no additional meaning for parameters like dir or recursive, failing to compensate for low coverage.
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 'Format Terraform files', which conveys the verb and resource. It differentiates from sibling tools like tf_apply or tf_plan, though it lacks specific mention of terraform fmt.
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 (e.g., tf_validate for validation, tf_plan for planning). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate resource graph (DOT format)
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full burden of behavioral disclosure. It only mentions generating DOT format but does not explain side effects (e.g., reads state, pure output), permissions needed, or what happens with the output. This is insufficient for safe tool invocation.
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 short (5 words), which can be concise, but it omits critical information and does not front-load important context. It is under-specified rather than optimally concise.
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 absence of annotations and output schema, the description is severely incomplete. It does not address how the DOT output is delivered (file, stdout), whether it requires a valid Terraform state, or any prerequisites. The tool's complexity is not matched by the description.
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% for the single parameter 'dir'. The description does not mention 'dir' at all, leaving its purpose, format, and constraints undocumented. With low coverage, the description should compensate but fails.
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 'Generate' and the resource 'resource graph (DOT format)', which is specific. However, it does not distinguish this tool from similar Terraform graph or visualization tools among the many siblings, e.g., tf_plan or tf_output.
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 is provided on when to use this tool versus alternatives like tf_plan for viewing dependencies or tf_show for plan details. The description implies it's for generating a DOT graph but offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import existing resource into state
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| address | Yes | Resource address | |
| id | Yes | Resource ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of disclosure. It does not explain side effects like whether importing overwrites existing state entries, or if it requires specific permissions. The description is minimal.
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 a single sentence, which is concise but lacks sufficient detail. It does not elaborate on tool behavior or usage, making it minimally adequate.
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 no output schema or annotations, the description is incomplete. It does not explain return values, prerequisites, or how the tool integrates with Terraform workflows. More context is needed for effective use.
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 67% (address and id have descriptions, dir does not). The tool description adds no extra meaning beyond the schema. The undocumented 'dir' parameter remains unclear without additional context.
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 imports an existing resource into state, using a specific verb and resource. It distinguishes from siblings like tf_apply or tf_plan which focus on applying or planning changes.
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 like tf_import is not provided. There is no mention of prerequisites or when it should not be used (e.g., if the resource already exists in state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize Terraform working directory
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Working directory | |
| upgrade | No | Upgrade providers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Initialize', which is vague. It fails to disclose that initialization may download providers, modify state backend config, or require specific permissions. No destructive or idempotent behavior is mentioned.
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 a single sentence with no fluff. However, it could benefit from additional details without becoming verbose. Still, it is appropriately sized for a tool name that is self-explanatory to some extent.
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 complexity of Terraform init (e.g., backend config, provider locks), the description is incomplete. No output schema exists, yet the tool likely returns output (e.g., success message, errors). The description provides no coverage of these aspects.
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 100%, so baseline is 3. The description adds no extra meaning beyond the schema parameter descriptions ('Working directory', 'Upgrade providers'). It does not explain when to set 'upgrade' to true or implications.
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 'Initialize Terraform working directory' clearly states the specific verb and resource. It distinguishes tf_init from sibling tools (e.g., tf_plan, tf_apply) which perform different actions.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical workflow position (e.g., first step), or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Terraform files in directory
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It fails to specify whether the listing is recursive, what file types are included (only .tf?), or if directories are listed. The agent cannot infer the operation's safety or 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 (one phrase), which is efficient for a simple tool. However, it could add a few more details without becoming verbose, such as the file listing behavior (e.g., non-recursive, .tf files only).
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 absence of an output schema, the description should indicate the output format (list of filenames? full paths?). It also fails to differentiate from 24 sibling tools, many of which also operate on Terraform files. The description is incomplete for effective tool selection.
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 single parameter 'dir' has 0% schema description coverage and no explanation in the description. The description only mentions 'directory' in the purpose but does not clarify if it is required, what format it expects, or the default value. This is insufficient for a tool with one undocumented parameter.
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 ('List') and resource ('Terraform files') with a location ('in directory'). It is specific enough for a basic understanding, but could be improved by specifying file extensions (e.g., .tf) to distinguish from other file types.
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 is provided on when to use this tool versus its siblings (e.g., tf_read_file for reading content, tf_show_plan for plans). There is no mention of prerequisites like being in a Terraform directory or that it is a read-only operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Terraform outputs
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| name | No | Specific output name | |
| json | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It only states 'get', implying a read operation, but fails to mention read-only nature, potential failures, or state requirements.
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 brief (3 words), but it is under-specified rather than appropriately concise. Critical information is missing.
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 has 3 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain return values, parameter behavior, or context for use.
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 only 33% (only 'name' has a description). The tool description adds no parameter details, failing to compensate for the low coverage.
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 'Get Terraform outputs' is a clear verb+noun but lacks specificity. It does not differentiate from sibling tools like tf_state_list or tf_show_plan, which could also be used to retrieve state information.
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 usage guidance is provided. The description does not indicate when to use tf_output versus other Terraform tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create execution plan
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| out | No | Save plan to file | |
| target | No | Target specific resource | |
| var | No | Variables to pass |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a bare description, the tool's behavioral traits (e.g., read-only nature, prerequisites, side effects) are entirely undisclosed. The description does not beyond what is obvious from the name.
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 a single sentence, but it is under-specified rather than concise. It lacks critical context that would make it useful.
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 complexity (4 params, no output schema, many siblings) and lack of annotations, the description is grossly insufficient. It omits essential details like Terraform command, plan output, and prerequisites.
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 coverage is 75% with three parameters documented. The description adds no extra meaning to parameters; baseline 3 is appropriate as the description does not detract but also adds nothing.
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 'Create execution plan' is essentially a tautology of the tool name 'tf_plan'. It fails to specify the Terraform context or distinguish what an execution plan is.
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 is provided on when to use this tool versus its siblings like tf_apply or tf_destroy. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List providers
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as side effects, readability, or required permissions. 'List' implies a read operation, but this is not explicitly stated.
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 short, but this is under-specification rather than conciseness. It lacks necessary detail and does not front-load useful information; each word does not earn 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 lack of annotations, output schema, and parameter details, the description is grossly incomplete. It fails to provide a meaningful understanding of the tool's behavior or return value.
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 input schema has one parameter 'dir' with no description. Schema description coverage is 0%, and the description does not explain the purpose or expected format of 'dir'.
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 states 'list providers' which is a clear verb+noun, but it's essentially a tautology of the tool name. It does not distinguish what specific providers are being listed (e.g., all available providers vs those in a configuration).
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 sibling tools like tf_list_files or tf_state_list. There is no context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Terraform file
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Read a Terraform file' without mentioning whether it returns raw content, parses the file, or any side effects. This is insufficient for an agent to understand the tool's behavior.
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 very short and concise, but it comes at the cost of completeness. It is not bloated, but it could be improved by adding essential details without harming conciseness.
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 lack of annotations, output schema, and parameter descriptions, the description is insufficiently complete. Even for a simple tool, more context (e.g., return value, supported file types) is needed for proper use.
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% and the description does not mention the 'file_path' parameter. The tool adds no meaning beyond the schema definition, leaving the agent uninformed about the expected format, scope, or constraints of the parameter.
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 'Read a Terraform file' clearly states the action and resource, but it essentially restates the tool name 'tf_read_file' without adding new information. It implicitly differentiates from siblings like 'tf_write_file' but lacks explicit distinction.
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 provides no guidance on when to use this tool, its prerequisites, or alternatives. It merely states the action without any contextual cues, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh state
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It only says 'Refresh state' without explaining side effects, safety, permissions, or lock requirements—leaving significant gaps.
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 two words, which is concise but severely under-specified. It fails to provide enough information to be useful, making it inadequate rather than efficiently clear.
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 complexity (Terraform state operation), no annotation coverage, no output schema, and a single undocumented parameter, the description is far too minimal to be complete or helpful.
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 input schema has one parameter 'dir' with 0% description coverage. The description does not mention or clarify this parameter, adding no meaning 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 'Refresh state' provides a verb and resource, indicating the tool refreshes Terraform state. However, it is vague and does not distinguish from siblings like tf_plan or tf_apply, which also interact with state.
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 is provided on when to use tf_refresh versus alternatives. With many sibling tools performing related state operations, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show saved plan file
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| plan_file | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits. It does not mention that the tool is a read operation, whether it outputs to stdout, or any requirements like the plan file must exist. The burden falls entirely on the description, which 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 very short (4 words) and front-loads the purpose, which is good for conciseness. However, the brevity comes at the cost of missing essential information, making it under-informative rather than efficiently concise.
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 lack of output schema, annotations, and the presence of 2 parameters (one required), the description is incomplete. It does not explain what 'show' entails, the output format, or any constraints. The agent would need to guess the behavior.
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 input schema has two parameters (dir and plan_file) with 0% description coverage. The description adds no explanation for either parameter, leaving the agent without clarity on their syntax or expected values.
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 'Show saved plan file' uses a specific verb 'Show' and identifies the resource as a saved plan file, making the purpose clear. However, it does not differentiate from related sibling tools like tf_state_show or tf_output, which could also display state or output.
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 provides no guidance on when to use this tool versus alternatives like tf_apply or tf_plan. It lacks context about prerequisites or typical workflow scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List resources in state
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only listing operation, but with no annotations, it lacks explicit statements about side effects, dependencies (e.g., requires a state file), or output format. It is adequate but could be more transparent.
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 a single concise sentence, front-loading the core purpose. However, it sacrifices completeness for brevity.
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 one undocumented parameter and a large sibling set, the description omits critical context: parameter meaning, output details, and use-case boundaries. It leaves many questions unanswered for an AI agent.
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 schema has 0% description coverage, and the description does not explain the 'dir' parameter. The agent has no information on what this parameter does, formats it expects, or how it affects the listing.
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 lists resources from the Terraform state. However, it does not specify whether it lists all resources or filtered, and the scope is implicit. It effectively distinguishes from sibling tools like tf_state_show but lacks specificity.
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 is provided on when to use this tool versus alternatives such as tf_state_show (which shows a specific resource) or other state-related tools. The agent receives no decision-support context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move resource in state
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| source | Yes | ||
| destination | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Move resource in state' without explaining whether the operation is destructive, reversible, requires backend access, or has side effects on the state file.
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 a single sentence. While brevity is good, it lacks structure and important details, making it minimally viable but not helpful.
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 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the concept of moving resources in state, the role of 'dir', or the implications of the operation. Sibling tools include many state-related ones, so more context is needed to differentiate.
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 schema has three parameters (dir, source, destination) with zero description coverage. The description does not explain what 'dir' means, and only hints at source/destination via the verb 'move'. It fails to add meaningful context beyond the parameter names.
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 'Move resource in state' clearly indicates the action (move) and the resource (resource in state). It distinguishes from siblings like tf_state_rm (remove) and tf_state_list (list), but could be more specific about what 'state' refers to (Terraform state).
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 is provided on when to use this tool versus alternatives like tf_state_rm or tf_import. The description does not mention any prerequisites, contexts, or conditions for using tf_state_mv.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove resource from state
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal description; no annotations. Does not disclose that this is a destructive operation on state (not infrastructure), or mention prerequisites like working directory.
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 (4 words), but at the expense of completeness. The action is front-loaded, but critical details are missing.
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?
For a state removal operation, the description lacks context on side effects, return values, and potential errors. Under-specified given no output schema.
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 has 0% description coverage and the description does not explain parameters 'dir' or 'address', leaving the agent without guidance on how to fill them.
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 'Remove resource from state' clearly states the action and resource, distinguishing it from sibling tools like tf_state_mv or tf_state_list.
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 provided on when to use this tool versus alternatives (e.g., tf_state_mv for moving, tf_destroy for destroying infrastructure).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show resource in state
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| address | Yes | Resource address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the tool is read-only, requires an existing state, or what happens on failure. Minimal disclosure leaves important gaps.
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 a short phrase, which is concise and front-loaded. However, it may be too terse, sacrificing valuable context that could be added without losing conciseness.
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 complexity of Terraform state management and the lack of output schema, the description is incomplete. It does not explain return format, error conditions, or how to use the parameters effectively.
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 coverage is 50% (only address has a description). The tool description adds no extra meaning beyond the schema; it does not explain the 'dir' parameter or provide examples. For a tool with incomplete schema descriptions, more elaboration is needed.
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 states the tool shows a resource in state, which is clear but does not differentiate from sibling tools like tf_state_list or tf_show_plan. The verb 'show' and resource 'resource in state' are specific enough for a basic understanding.
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. The description does not mention prerequisites, context, or when not to use it. Given the sibling tools, explicit usage advice would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark resource for recreation
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose that this is a Terraform taint command affecting state, that it requires an existing resource, or that changes take effect on next apply. Insufficient behavioral detail.
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 short (4 words) but not well-structured. While concise, it lacks a full sentence and may be too terse to be helpful. The phrase 'for recreation' could be rephrased for clarity.
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 complexity of Terraform commands and 25 sibling tools, the description is woefully incomplete. No mention of directory parameter, state implications, or relationship to tf_plan/tf_apply.
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 coverage is 0% (no param descriptions). The tool description does not mention parameters at all, adding zero value beyond the schema. For 2 parameters, this is inadequate.
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 'Mark resource for recreation' clearly states the verb (mark), resource (resource), and purpose (for recreation). It distinguishes from siblings like tf_untaint (unmark) and tf_destroy (destroy). However, 'recreation' may be ambiguous without Terraform context.
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 vs alternatives like tf_untaint, tf_apply, or tf_destroy. Lacks context for appropriate usage and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove taint from resource
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'remove taint' but does not mention permissions, side effects, or state changes, leaving significant gaps.
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 short (one sentence), which is concise but lacks structure. It does not earn its place by providing necessary details beyond the bare action.
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 zero schema descriptions, no output schema, and a mutation nature, the description is critically incomplete. It fails to cover parameter roles, prerequisites, or behavior, leaving the agent without enough 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?
Schema description coverage is 0%, yet the description fails to explain the parameters 'dir' and 'address'. Without any parameter info, the agent cannot understand how to invoke the tool correctly.
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 'Remove taint from resource' uses a specific verb and resource, clearly stating the tool's function. While it doesn't explicitly distinguish from siblings like 'tf_taint', the name and opposing sibling make it evident.
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 is provided on when to use this tool versus alternatives such as 'tf_taint' or other state manipulation tools. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate Terraform configuration
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility for disclosing behavior. It only states 'Validate Terraform configuration' without mentioning whether it is read-only, what output is produced, or any side effects. This is insufficient for an agent to understand the tool's behavior.
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 a single sentence of 4 words, which is extremely short. While there is no unnecessary text, it is under-specified and fails to convey essential information, so it does not count as effective conciseness.
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 simplicity of the tool (1 parameter, no output schema, no annotations), the description should still cover usage context, parameter meaning, and results. It does none of these, making it incomplete.
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 input schema has one parameter 'dir' with no description, and 0% schema description coverage. The description does not mention 'dir' or provide any context, leaving the parameter's purpose and format completely undocumented.
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 'Validate Terraform configuration' clearly states the tool's verb (validate) and resource (Terraform configuration). It is distinct from sibling tools like tf_plan or tf_apply, which have different purposes.
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 is provided on when to use this tool vs alternatives such as tf_plan, which also performs validation. The description implies usage before applying changes, but it is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Terraform version
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond 'Get Terraform version'. Since annotations are absent, the description alone must convey behavior, but it offers no additional details such as read-only nature or potential effects, though the tool is inherently simple.
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 a single concise sentence that wastes no words. It is front-loaded with the key action, making it easy for an agent to parse quickly.
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 (no parameters, no output schema), the description is adequately complete for its intended purpose. It tells the agent exactly what the tool does, though a brief note on the output format would have raised the score further.
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?
With zero parameters, the schema coverage is trivially 100%. The description does not need to add parameter information, and the baseline for no parameters is 4, which is appropriate here.
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 'Get Terraform version' clearly states a specific verb and resource, and it distinguishes itself from sibling tools like tf_apply or tf_plan which perform different actions.
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 provides no explicit guidance on when to use this tool versus alternatives. While the tool's simplicity makes its use case obvious, the lack of any context about its read-only nature or when to invoke it keeps it from a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete workspace
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It states 'Delete workspace' but does not explain consequences (e.g., irreversibility, effect on Terraform state, required permissions). This is a significant gap for a destructive operation.
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 short (two words) but at the cost of informativeness. It is under-specified rather than efficiently concise.
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 complexity of Terraform workspace management and the number of sibling tools, the description is woefully incomplete. It lacks return value info, error handling, and any behavioral context, making it hard for an agent to use correctly.
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?
With 0% schema description coverage, the description should compensate but does not. The two parameters (dir, name) are not explained; the user cannot infer their purpose or constraints from the description 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 'Delete workspace' is clear in that it names a verb and resource, but fails to specify which workspace (by name vs. directory) or differentiate from similar tools like tf_workspace_new or tf_destroy. It is minimally adequate but lacks specificity.
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 is provided on when to use this tool versus alternatives such as tf_destroy or other workspace commands. There are no usage scenarios, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workspaces
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits. It does not mention whether the tool requires an initialized Terraform directory, whether it lists local or remote workspaces, or what the output format is.
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 words), which is efficient, but it sacrifices necessary detail. It could be more informative without adding much length.
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 1 parameter, no output schema, and 24 sibling tools, the description is severely incomplete. An AI agent cannot determine the tool's behavior, prerequisites, or output, making it nearly impossible to use correctly.
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 input schema has one optional parameter 'dir' with no description in either the schema or the tool description. Schema description coverage is 0%, and the description does not explain the parameter's purpose or effect on the listing.
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 'List workspaces' uses a specific verb and resource, making the basic action clear. It distinguishes from sibling workspace tools like tf_workspace_new or tf_workspace_delete, but lacks context about scope (e.g., current directory or specific directory).
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 is provided on when to use this tool versus alternatives. Sibling tools include many workspace operations (create, delete, select), but the description gives no hints about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create workspace
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details. It does not disclose that creating a workspace is a mutating operation, any side effects, required permissions, or error conditions.
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 short (two words), which is underspecified rather than appropriately concise. It lacks structure and does not earn its place with valuable content.
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?
For a create operation with two parameters and no output schema, the description is far from complete. It does not explain what happens upon creation, return values, or related tools. An agent cannot reliably use this tool based solely on the description.
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 input schema has 0% description coverage, and the tool description does not explain what 'dir' or 'name' parameters mean. This leaves the agent with no semantic information beyond parameter names.
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 'Create workspace' specifies a clear verb and resource, but lacks any differentiation from sibling tools like tf_workspace_delete or tf_workspace_list. It does not clarify that this is a Terraform workspace, leaving context implicit.
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 provides no guidance on when to use this tool versus alternatives. It omits prerequisites (e.g., need for an initialized Terraform project) and does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select workspace
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'Select workspace' with no disclosure of side effects, permissions, or state changes, which is minimal.
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 short (two words), but it is under-specified rather than effectively concise, lacking necessary details.
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 no annotations, no output schema, and two parameters, the description is completely inadequate for an agent to use the tool correctly.
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 schema has 0% description coverage and the description does not explain the 'dir' and 'name' parameters, adding no meaning beyond the bare 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 states 'Select workspace,' which indicates a basic action and resource, but it does not specify what selecting entails or differentiate from sibling tools like tf_workspace_list or tf_workspace_new.
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 provides no guidance on when to use this tool versus alternatives, leaving the agent without context for selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a Terraform file
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description of behavioral traits (e.g., whether it creates new files, overwrites existing ones, or requires specific permissions), the description fails to inform the agent of important behaviors beyond the basic action.
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 short (one sentence), which is not conciseness but under-specification. It does not earn its place by providing sufficient detail for the agent to use the tool effectively.
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 lack of parameter descriptions, no output schema, and no behavioral details, the description is highly incomplete. An agent cannot reliably invoke this tool without additional knowledge.
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 input schema has 0% description coverage for parameters, and the description does not explain what file_path or content represent, nor any constraints or formats. This leaves the agent with minimal guidance for correct usage.
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 'Write a Terraform file' clearly states the verb and resource, and paired with the tool name, it distinguishes from siblings like tf_read_file. However, it lacks detail on what 'write' entails (overwrite, append, etc.), preventing a 5.
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 is provided on when to use this tool versus alternatives like tf_read_file or other Terraform operations. There is no mention of context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct Terraform operation (e.g., apply, destroy, plan, state management, workspaces) with no overlap. Descriptions are clear enough to differentiate.
All tools follow a consistent 'tf_' prefix with a verb_noun pattern (e.g., tf_apply, tf_state_list, tf_workspace_new). No mixing of conventions.
26 tools cover the full lifecycle of Terraform operations—init, plan, apply, destroy, state, workspaces, file ops, etc. Each tool serves a clear purpose without bloat.
The set includes all major Terraform workflows: initialization, planning, applying, destroying, state management, workspace management, file operations, formatting, validation, import, output, and more. No critical gaps identified.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
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/mjrestivo16/mcp-terraform'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
