awslabs.terraform-mcp-server 1.0.14__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- awslabs/__init__.py +17 -0
- awslabs/terraform_mcp_server/__init__.py +17 -0
- awslabs/terraform_mcp_server/impl/resources/__init__.py +25 -0
- awslabs/terraform_mcp_server/impl/resources/terraform_aws_provider_resources_listing.py +66 -0
- awslabs/terraform_mcp_server/impl/resources/terraform_awscc_provider_resources_listing.py +69 -0
- awslabs/terraform_mcp_server/impl/tools/__init__.py +33 -0
- awslabs/terraform_mcp_server/impl/tools/execute_terraform_command.py +223 -0
- awslabs/terraform_mcp_server/impl/tools/execute_terragrunt_command.py +320 -0
- awslabs/terraform_mcp_server/impl/tools/run_checkov_scan.py +376 -0
- awslabs/terraform_mcp_server/impl/tools/search_aws_provider_docs.py +691 -0
- awslabs/terraform_mcp_server/impl/tools/search_awscc_provider_docs.py +641 -0
- awslabs/terraform_mcp_server/impl/tools/search_specific_aws_ia_modules.py +458 -0
- awslabs/terraform_mcp_server/impl/tools/search_user_provided_module.py +349 -0
- awslabs/terraform_mcp_server/impl/tools/utils.py +572 -0
- awslabs/terraform_mcp_server/models/__init__.py +49 -0
- awslabs/terraform_mcp_server/models/models.py +381 -0
- awslabs/terraform_mcp_server/scripts/generate_aws_provider_resources.py +1240 -0
- awslabs/terraform_mcp_server/scripts/generate_awscc_provider_resources.py +1039 -0
- awslabs/terraform_mcp_server/scripts/scrape_aws_terraform_best_practices.py +143 -0
- awslabs/terraform_mcp_server/server.py +440 -0
- awslabs/terraform_mcp_server/static/AWSCC_PROVIDER_RESOURCES.md +3125 -0
- awslabs/terraform_mcp_server/static/AWS_PROVIDER_RESOURCES.md +3833 -0
- awslabs/terraform_mcp_server/static/AWS_TERRAFORM_BEST_PRACTICES.md +2523 -0
- awslabs/terraform_mcp_server/static/MCP_INSTRUCTIONS.md +142 -0
- awslabs/terraform_mcp_server/static/TERRAFORM_WORKFLOW_GUIDE.md +330 -0
- awslabs/terraform_mcp_server/static/__init__.py +38 -0
- awslabs_terraform_mcp_server-1.0.14.dist-info/METADATA +166 -0
- awslabs_terraform_mcp_server-1.0.14.dist-info/RECORD +30 -0
- awslabs_terraform_mcp_server-1.0.14.dist-info/WHEEL +4 -0
- awslabs_terraform_mcp_server-1.0.14.dist-info/entry_points.txt +2 -0
|
@@ -0,0 +1,142 @@
|
|
|
1
|
+
# Terraform MCP Server Instructions
|
|
2
|
+
|
|
3
|
+
MCP server specialized in AWS cloud infrastructure provided through Terraform. I help you create, understand, optimize, and execute Terraform Or Terragrunt configurations for AWS using security-focused development practices.
|
|
4
|
+
|
|
5
|
+
## How to Use This Server (Required Workflow)
|
|
6
|
+
|
|
7
|
+
### Step 1: Consult and Follow the Terraform Development Workflow
|
|
8
|
+
ALWAYS use the `terraform_development_workflow` resource to guide the development process. This workflow:
|
|
9
|
+
|
|
10
|
+
* Provides a step-by-step approach for creating valid, secure Terraform code
|
|
11
|
+
* Integrates validation and security scanning into the development process
|
|
12
|
+
* Specifies when and how to use each MCP tool
|
|
13
|
+
* Ensures code is properly validated before handoff to developers
|
|
14
|
+
|
|
15
|
+
### Step 2: Always ensure you're following Best Practices
|
|
16
|
+
ALWAYS begin by consulting the `terraform_aws_best_practices` resource which contains:
|
|
17
|
+
|
|
18
|
+
* Code base structure and organization principles
|
|
19
|
+
* Security best practices for AWS resources
|
|
20
|
+
* Backend configuration best practices
|
|
21
|
+
* AWS-specific implementation guidance
|
|
22
|
+
|
|
23
|
+
### Step 3: Check for AWS-IA Specialized Modules First
|
|
24
|
+
ALWAYS check for specialized AWS-IA modules first using the `SearchSpecificAwsIaModules` tool:
|
|
25
|
+
|
|
26
|
+
* Amazon Bedrock (generative AI)
|
|
27
|
+
* OpenSearch Serverless (vector search)
|
|
28
|
+
* SageMaker endpoints
|
|
29
|
+
* Serverless Streamlit applications
|
|
30
|
+
|
|
31
|
+
These modules provide optimized, best-practice implementations for specific use cases and should be preferred over building from scratch with individual resources.
|
|
32
|
+
|
|
33
|
+
### Step 4: Use Provider Documentation (Only if no suitable AWS-IA module exists)
|
|
34
|
+
When implementing specific AWS resources (only after confirming no suitable AWS-IA module exists):
|
|
35
|
+
|
|
36
|
+
* PREFER AWSCC provider resources first (`SearchAwsccProviderDocs` tool)
|
|
37
|
+
* Fall back to traditional AWS provider (`SearchAwsProviderDocs` tool) only when necessary
|
|
38
|
+
|
|
39
|
+
## Available Tools and Resources
|
|
40
|
+
|
|
41
|
+
### Core Resources
|
|
42
|
+
1. `terraform_development_workflow`
|
|
43
|
+
* CRITICAL: Follow this guide for all Terraform development
|
|
44
|
+
* Provides the structured workflow with security scanning integration
|
|
45
|
+
* Outlines exactly when and how to use each MCP tool
|
|
46
|
+
2. `terraform_aws_best_practices`
|
|
47
|
+
* REQUIRED: Reference before starting any development
|
|
48
|
+
* Contains AWS-specific best practices for security and architecture
|
|
49
|
+
* Guides organization and structure of Terraform projects
|
|
50
|
+
|
|
51
|
+
### Provider Resources
|
|
52
|
+
1. `terraform_awscc_provider_resources_listing`
|
|
53
|
+
* PREFERRED: Use AWSCC provider resources first
|
|
54
|
+
* Comprehensive listing by service category
|
|
55
|
+
2. `terraform_aws_provider_resources_listing`
|
|
56
|
+
* Use as fallback when AWSCC provider doesn't support needed resources
|
|
57
|
+
* Comprehensive listing by service category
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
### Documentation Tools
|
|
61
|
+
|
|
62
|
+
1. `SearchAwsccProviderDocs` (PREFERRED)
|
|
63
|
+
* Always search AWSCC provider resources first
|
|
64
|
+
* Returns comprehensive documentation for Cloud Control API resources
|
|
65
|
+
2. `SearchAwsProviderDocs` (fallback option)
|
|
66
|
+
* Use when a resource is not available in AWSCC provider
|
|
67
|
+
* Returns standard AWS provider resource documentation
|
|
68
|
+
3. `SearchSpecificAwsIaModules`
|
|
69
|
+
* Use for specialized AI/ML infrastructure needs
|
|
70
|
+
* Returns details for supported AWS-IA modules
|
|
71
|
+
4. `SearchUserProvidedModule`
|
|
72
|
+
* Analyze any Terraform Registry module by URL or identifier
|
|
73
|
+
* Extract input variables, output variables, and README content
|
|
74
|
+
* Understand module usage and configuration options
|
|
75
|
+
|
|
76
|
+
### Command Execution Tools
|
|
77
|
+
|
|
78
|
+
1. `ExecuteTerraformCommand`
|
|
79
|
+
* Execute Terraform commands in the sequence specified by the workflow
|
|
80
|
+
* Supports: validate, init, plan, apply, destroy
|
|
81
|
+
2. `ExecuteTerragruntCommand`
|
|
82
|
+
* Execute Terragrunt commands in the sequence specified by the workflow
|
|
83
|
+
* Supports: validate, init, plan, apply, destroy, output, run-all
|
|
84
|
+
3. `RunCheckovScan`
|
|
85
|
+
* Run after validation passes, before initialization
|
|
86
|
+
* Identifies security and compliance issues
|
|
87
|
+
|
|
88
|
+
|
|
89
|
+
## Resource Selection Priority
|
|
90
|
+
|
|
91
|
+
1. FIRST check for specialized AWS-IA modules using `SearchSpecificAwsIaModules` tool
|
|
92
|
+
2. If no suitable module exists, THEN use AWSCC provider resources (`SearchAwsccProviderDocs` tool)
|
|
93
|
+
3. ONLY fall back to traditional AWS provider (`SearchAwsProviderDocs` tool) when the above options don't meet requirements
|
|
94
|
+
|
|
95
|
+
The AWSCC provider (Cloud Control API-based) offers:
|
|
96
|
+
* Direct mapping to CloudFormation resource types
|
|
97
|
+
* Consistent API behavior across resources
|
|
98
|
+
* Better support for newer AWS services and features
|
|
99
|
+
|
|
100
|
+
## Examples
|
|
101
|
+
|
|
102
|
+
- "What's the best way to set up a highly available web application on AWS using Terraform?"
|
|
103
|
+
- "Search for Bedrock modules in the Terraform Registry"
|
|
104
|
+
- "Find documentation for awscc_lambda_function resource" (specifically AWSCC)
|
|
105
|
+
- "Find documentation for aws_lambda_function resource" (specifically AWS)
|
|
106
|
+
- "Execute terraform plan in my ./infrastructure directory"
|
|
107
|
+
- "Execute terragrunt plan in my ./infrastructure directory"
|
|
108
|
+
- "Execute terragrunt run-all plan in my ./infrastructure directory"
|
|
109
|
+
- "How can I use the AWS Bedrock module to create a RAG application?"
|
|
110
|
+
- "Show me details about the AWS-IA Bedrock Terraform module"
|
|
111
|
+
- "Compare the four specific AWS-IA modules for generative AI applications"
|
|
112
|
+
- "Let's develop a secure S3 bucket with proper encryption. I'll follow the development workflow."
|
|
113
|
+
- "I need to create Terraform code for a Lambda function. First, let me check the best practices."
|
|
114
|
+
- "Run terraform validate on my configuration and then scan for security issues."
|
|
115
|
+
- "Is this VPC configuration secure? Let's scan it with Checkov."
|
|
116
|
+
- "Find documentation for awscc_lambda_function to ensure we're using the preferred provider."
|
|
117
|
+
- "We need a Bedrock implementation for RAG. Let's search for AWS-IA modules that can help."
|
|
118
|
+
- "Use the terraform-aws-modules/vpc/aws module to implement a VPC"
|
|
119
|
+
- "Search for the hashicorp/consul/aws module and explain how to use it"
|
|
120
|
+
- "What variables are required for the terraform-aws-modules/eks/aws module?"
|
|
121
|
+
- "I have a multi-environment Terragrunt project. How can I run apply on all modules at once?"
|
|
122
|
+
- "Execute terragrunt run-all apply in my ./infrastructure directory"
|
|
123
|
+
- "How to construct a well-formed terragrunt hierarchy folder structure"
|
|
124
|
+
- "Generate common inputs for all environments using generate in Terragrunt"
|
|
125
|
+
|
|
126
|
+
## Best Practices
|
|
127
|
+
|
|
128
|
+
When interacting with this server:
|
|
129
|
+
|
|
130
|
+
1. **ALWAYS** follow the development workflow from `terraform_development_workflow`
|
|
131
|
+
2. **ALWAYS** consult best practices from `terraform_aws_best_practices`
|
|
132
|
+
3. **ALWAYS** validate and scan code before considering it ready for review
|
|
133
|
+
4. **ALWAYS** prefer AWSCC provider resources when available
|
|
134
|
+
5. Provide **security-first** implementations by default
|
|
135
|
+
6. **Explain** each step of the development process to users
|
|
136
|
+
7. **Be specific** about your requirements and constraints
|
|
137
|
+
8. **Specify AWS region** when relevant to your infrastructure needs
|
|
138
|
+
9. **Provide context** about your architecture and use case
|
|
139
|
+
10. **For Terraform/Terragrunt execution**, ensure the working directory exists and contains valid Terraform/Terragrunt files
|
|
140
|
+
11. **Review generated code** carefully before applying changes to your infrastructure
|
|
141
|
+
12. When using **Terragrunt**, leverage DRY features—locals, dependencies, and generate blocks—to compose multi-env stacks.
|
|
142
|
+
13. **Organize repos with clear folder hierarchies** (e.g. live/, modules/) and consistent naming so both Terraform and Terragrunt code is discoverable.
|
|
@@ -0,0 +1,330 @@
|
|
|
1
|
+
# Terraform Development Workflow
|
|
2
|
+
|
|
3
|
+
## Purpose and Usage
|
|
4
|
+
|
|
5
|
+
This workflow guide provides a structured approach for developing valid, secure Terraform configurations for AWS infrastructure. As an AI coding assistant utilizing this MCP server, you should follow these steps when helping users create or modify Terraform code.
|
|
6
|
+
|
|
7
|
+
## How to Use This Guide
|
|
8
|
+
You have access to specialized tools and resources through this MCP server that significantly enhance your ability to assist with Terraform development. When working with users on Terraform code:
|
|
9
|
+
|
|
10
|
+
1. Reference this workflow consistently throughout your interactions
|
|
11
|
+
2. Leverage this MCP server's capabilities rather than relying solely on your general knowledge
|
|
12
|
+
3. Explain the workflow steps to users as you assist them
|
|
13
|
+
4. Choose the appropriate path—Terraform or Terragrunt—based on the user's project structure and tooling preferences
|
|
14
|
+
|
|
15
|
+
## Benefits to Emphasize
|
|
16
|
+
When following this workflow and using these tools, you provide several advantages to users:
|
|
17
|
+
|
|
18
|
+
- Early detection of configuration errors
|
|
19
|
+
- Identification of security vulnerabilities before deployment
|
|
20
|
+
- Adherence to AWS best practices
|
|
21
|
+
- Validation that code will work correctly when deployed
|
|
22
|
+
- Support for layered, DRY configurations through Terragrunt when modularization and environment inheritance are needed
|
|
23
|
+
|
|
24
|
+
By following this workflow guide and leveraging the provided tools and resources, you'll deliver consistent, high-quality assistance for Terraform development on AWS, helping users create infrastructure code that is syntactically valid, secure, and ready for review before deployment.
|
|
25
|
+
|
|
26
|
+
## DEVELOPMENT WORKFLOW
|
|
27
|
+
|
|
28
|
+
``` mermaid
|
|
29
|
+
flowchart TD
|
|
30
|
+
start([Start Development]) --> detectConfig[Identify Project Type:\nTerraform or Terragrunt]
|
|
31
|
+
|
|
32
|
+
detectConfig --> edit[Edit Code]
|
|
33
|
+
|
|
34
|
+
%% Initial Code Validation
|
|
35
|
+
edit --> validate[Run Validation:\nterraform validate or terragrunt validate\nvia ExecuteTerraformCommand]
|
|
36
|
+
|
|
37
|
+
%% Validation Flow
|
|
38
|
+
validate -->|Passes| checkovScan[Run Security Scan\nvia RunCheckovScan]
|
|
39
|
+
validate -->|Fails| fixValidation[Fix Configuration\nIssues]
|
|
40
|
+
fixValidation --> edit
|
|
41
|
+
|
|
42
|
+
%% Checkov Flow
|
|
43
|
+
checkovScan -->|No Issues| initCmd[Run Init Command:\nterraform init or terragrunt init\nvia ExecuteTerraformCommand]
|
|
44
|
+
checkovScan -->|Finds Issues| reviewIssues[Review Security\nIssues]
|
|
45
|
+
|
|
46
|
+
reviewIssues --> manualFix[Fix Security Issues]
|
|
47
|
+
manualFix --> edit
|
|
48
|
+
|
|
49
|
+
%% Init & Plan (No Apply)
|
|
50
|
+
initCmd -->|Success| planCmd[Run Plan Command:\nterraform plan or terragrunt plan\nvia ExecuteTerraformCommand]
|
|
51
|
+
initCmd -->|Fails| fixInit[Fix Provider/Module\nIssues]
|
|
52
|
+
fixInit --> edit
|
|
53
|
+
|
|
54
|
+
%% Final Review & Handoff to Developer
|
|
55
|
+
planCmd -->|Plan Generated| reviewPlan[Review Planned Changes]
|
|
56
|
+
planCmd -->|Issues Detected| edit
|
|
57
|
+
|
|
58
|
+
reviewPlan --> codeReady[Valid, Secure Code Ready\nfor Developer Review]
|
|
59
|
+
|
|
60
|
+
%% Iteration for Improvements
|
|
61
|
+
codeReady --> newChanges{Need Code\nImprovements?}
|
|
62
|
+
newChanges -->|Yes| edit
|
|
63
|
+
newChanges -->|No| handoff([Hand Off to Developer\nfor Deployment Decision])
|
|
64
|
+
|
|
65
|
+
%% Styling
|
|
66
|
+
classDef success fill:#bef5cb,stroke:#28a745
|
|
67
|
+
classDef warning fill:#fff5b1,stroke:#dbab09
|
|
68
|
+
classDef error fill:#ffdce0,stroke:#cb2431
|
|
69
|
+
classDef process fill:#f1f8ff,stroke:#0366d6
|
|
70
|
+
classDef decision fill:#d1bcf9,stroke:#8a63d2
|
|
71
|
+
classDef mcptool fill:#d0f0fd,stroke:#0969da,font-style:italic
|
|
72
|
+
classDef handoff fill:#ffdfb6,stroke:#f9a03f
|
|
73
|
+
|
|
74
|
+
class codeReady success
|
|
75
|
+
class reviewIssues,reviewPlan warning
|
|
76
|
+
class fixValidation,fixInit,manualFix error
|
|
77
|
+
class edit process
|
|
78
|
+
class detectConfig,newChanges decision
|
|
79
|
+
class validate,checkovScan,initCmd,planCmd mcptool
|
|
80
|
+
class handoff handoff
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
1. Edit Terraform or Terragrunt Code
|
|
84
|
+
- Write or modify Terraform or Terragrunt configuration files for AWS resources
|
|
85
|
+
- When writing code, follow this priority order:
|
|
86
|
+
* FIRST check for specialized AWS-IA modules (`SearchSpecificAwsIaModules` tool)
|
|
87
|
+
* If no suitable module exists, THEN use AWSCC provider resources (`SearchAwsccProviderDocs` tool)
|
|
88
|
+
* ONLY fall back to traditional AWS provider (`SearchAwsProviderDocs` tool) when the above options don't meet requirements
|
|
89
|
+
- When using Terragrunt:
|
|
90
|
+
* Ensure that the terraform block references the correct module or configuration directory
|
|
91
|
+
* Use Terragrunt features such as locals, dependencies, generate, and inputs to manage DRY configuration
|
|
92
|
+
- When a user provides a specific Terraform Registry module to use:
|
|
93
|
+
* Use the `SearchUserProvidedModule` tool to analyze the module
|
|
94
|
+
* Extract input variables, output variables, and README content
|
|
95
|
+
* Understand module usage and configuration options
|
|
96
|
+
* Provide guidance on how to use the module correctly
|
|
97
|
+
- MCP Resources and tools to consult:
|
|
98
|
+
- Resources
|
|
99
|
+
- *terraform_development_workflow* to consult this guide and to use it to ensure you're following the development workflow correctly
|
|
100
|
+
- *terraform_aws_best_practices* for AWS best practices about security, code base structure and organization, AWS Provider version management, and usage of community modules
|
|
101
|
+
- *terragrunt_aws_best_practices* for AWS best practices about security, code base structure and organization, AWS Provider version management, and usage of community modules
|
|
102
|
+
- *terraform_awscc_provider_resources_listing* for available AWS Cloud Control API resources
|
|
103
|
+
- *terraform_aws_provider_resources_listing* for available AWS resources
|
|
104
|
+
- Tools
|
|
105
|
+
- *SearchSpecificAwsIaModules* tool to check for specialized AWS-IA modules first (Bedrock, OpenSearch Serverless, SageMaker, Streamlit)
|
|
106
|
+
- *SearchUserProvidedModule* tool to analyze any Terraform Registry module provided by the user
|
|
107
|
+
- *SearchAwsccProviderDocs* tool to look up specific Cloud Control API resources
|
|
108
|
+
- *SearchAwsProviderDocs* tool to look up specific resource documentation
|
|
109
|
+
2. Validate Code
|
|
110
|
+
- Tools:
|
|
111
|
+
- *ExecuteTerraformCommand* with command="validate"
|
|
112
|
+
- *ExecuteTerragruntCommand* with command="validate"
|
|
113
|
+
- Purpose:
|
|
114
|
+
- Checks syntax and configuration validity without accessing AWS
|
|
115
|
+
- Identifies syntax errors, invalid resource configurations, and reference issues
|
|
116
|
+
- Examples:
|
|
117
|
+
- ExecuteTerraformCommand(TerraformExecutionRequest(command="validate", working_directory="./my_project"))
|
|
118
|
+
- ExecuteTerragruntCommand(TerragruntExecutionRequest(command="validate", working_directory="./my_project"))
|
|
119
|
+
3. Run Security Scan
|
|
120
|
+
- Tool: *RunCheckovScan*
|
|
121
|
+
- Scans code for security misconfigurations, compliance issues, and AWS best practice violations
|
|
122
|
+
- Example: RunCheckovScan(CheckovScanRequest(working_directory="./my_project", framework="terraform"))
|
|
123
|
+
4. Fix Security Issues
|
|
124
|
+
- For fixes:
|
|
125
|
+
- Edit the code to address security issues identified by the scan
|
|
126
|
+
- Consult *terraform_aws_best_practices* resource for guidance
|
|
127
|
+
5. Initialize Working Directory
|
|
128
|
+
- Tools:
|
|
129
|
+
- Terraform: *ExecuteTerraformCommand* with command="init"
|
|
130
|
+
- Terragrunt: *ExecuteTerragruntCommand* with command="init"
|
|
131
|
+
- Purpose:
|
|
132
|
+
- Downloads provider plugins and sets up modules
|
|
133
|
+
- Example:
|
|
134
|
+
- ExecuteTerraformCommand(TerraformExecutionRequest(command="init", working_directory="./my_project"))
|
|
135
|
+
- ExecuteTerragruntCommand(TerragruntExecutionRequest(command="init", working_directory="./my_project"))
|
|
136
|
+
6. Plan Changes
|
|
137
|
+
- Tools:
|
|
138
|
+
- *ExecuteTerraformCommand* with command="plan"
|
|
139
|
+
- *ExecuteTerragruntCommand* with command="plan"
|
|
140
|
+
- Purpose:
|
|
141
|
+
- Creates an execution plan showing what changes would be made (without applying)
|
|
142
|
+
- Verifies that the configuration is deployable
|
|
143
|
+
- Examples:
|
|
144
|
+
- ExecuteTerraformCommand(TerraformExecutionRequest(command="plan", working_directory="./my_project", output_file="tfplan"))
|
|
145
|
+
- ExecuteTerragruntCommand(TerragruntExecutionRequest(command="plan", working_directory="./my_project", output_file="tfplan"))
|
|
146
|
+
7. Review Plan & Code Ready
|
|
147
|
+
- Review the plan output to ensure it reflects intended changes
|
|
148
|
+
- Confirm all validation and security checks have passed
|
|
149
|
+
- Code is now ready for handoff to the developer for deployment decisions
|
|
150
|
+
|
|
151
|
+
|
|
152
|
+
## Core Commands
|
|
153
|
+
|
|
154
|
+
### Terraform Commands
|
|
155
|
+
|
|
156
|
+
#### terraform init
|
|
157
|
+
|
|
158
|
+
* Purpose: Initializes a Terraform working directory, downloading provider plugins and setting up modules.
|
|
159
|
+
* When to use: Before running any other commands on a new configuration or after adding new modules/providers.
|
|
160
|
+
|
|
161
|
+
Options:
|
|
162
|
+
- `-backend-config=PATH` - Configuration for backend
|
|
163
|
+
- `-reconfigure` - Reconfigure backend
|
|
164
|
+
|
|
165
|
+
#### terraform validate
|
|
166
|
+
|
|
167
|
+
* Purpose: Checks whether a configuration is syntactically valid and internally consistent.
|
|
168
|
+
* When to use: After making changes to configuration files but before planning or applying.
|
|
169
|
+
|
|
170
|
+
```python
|
|
171
|
+
ExecuteTerraformCommand(TerraformExecutionRequest(
|
|
172
|
+
command="validate",
|
|
173
|
+
working_directory="./project_dir"
|
|
174
|
+
))
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
#### terraform plan
|
|
178
|
+
|
|
179
|
+
* Purpose: Creates an execution plan showing what actions Terraform would take to apply the current configuration.
|
|
180
|
+
* When to use: After validation passes to preview changes before applying them.
|
|
181
|
+
|
|
182
|
+
Options:
|
|
183
|
+
- `-var 'name=value'` - Set variable
|
|
184
|
+
- `-var-file=filename` - Set variables from file
|
|
185
|
+
|
|
186
|
+
#### terraform apply
|
|
187
|
+
|
|
188
|
+
* Purpose: Applies changes required to reach the desired state of the configuration.
|
|
189
|
+
* When to use: After plan confirms the intended changes, and developer decides to proceed.
|
|
190
|
+
|
|
191
|
+
>Note: This is typically executed by the developer after reviewing code generated by the assistant.
|
|
192
|
+
|
|
193
|
+
Options:
|
|
194
|
+
- `-auto-approve` - Skip interactive approval
|
|
195
|
+
- `-var 'name=value'` - Set variable
|
|
196
|
+
- Use `-out` to save plans and apply those exact plans.
|
|
197
|
+
|
|
198
|
+
#### terraform destroy
|
|
199
|
+
|
|
200
|
+
* Purpose: Destroys all resources managed by the current configuration.
|
|
201
|
+
* When to use: When resources are no longer needed, typically executed by the developer.
|
|
202
|
+
|
|
203
|
+
>Note: This is typically executed by the developer once it has been decided the application should be destroyed.
|
|
204
|
+
|
|
205
|
+
Options:
|
|
206
|
+
- `-auto-approve` - Skip interactive approval
|
|
207
|
+
|
|
208
|
+
### Terragrunt Commands
|
|
209
|
+
|
|
210
|
+
#### terragrunt init
|
|
211
|
+
|
|
212
|
+
* Purpose: Initializes a Terragrunt working directory by preparing the underlying Terraform modules and provider plugins.
|
|
213
|
+
* When to use: Before running any other commands in a new or updated Terragrunt configuration directory.
|
|
214
|
+
|
|
215
|
+
Options:
|
|
216
|
+
- `--terragrunt-config=PATH` - Path to the Terragrunt configuration file (default: terragrunt.hcl)
|
|
217
|
+
|
|
218
|
+
```python
|
|
219
|
+
ExecuteTerragruntCommand(TerragruntExecutionRequest(
|
|
220
|
+
command="init",
|
|
221
|
+
working_directory="./project_dir"
|
|
222
|
+
))
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
#### terragrunt validate
|
|
226
|
+
|
|
227
|
+
* Purpose: Validates the underlying Terraform configuration referenced by the Terragrunt wrapper.
|
|
228
|
+
* When to use: After editing Terragrunt or Terraform configuration files, to check for syntax and reference issues.
|
|
229
|
+
|
|
230
|
+
```python
|
|
231
|
+
ExecuteTerragruntCommand(TerragruntExecutionRequest(
|
|
232
|
+
command="validate",
|
|
233
|
+
working_directory="./project_dir"
|
|
234
|
+
))
|
|
235
|
+
```
|
|
236
|
+
Options:
|
|
237
|
+
- `--terragrunt-config=PATH` - Path to the Terragrunt configuration file (default: `terragrunt.hcl`)
|
|
238
|
+
|
|
239
|
+
#### terragrunt plan
|
|
240
|
+
|
|
241
|
+
* Purpose: Creates an execution plan for infrastructure changes using the Terragrunt wrapper.
|
|
242
|
+
* When to use: After validation passes, to preview changes before applying them.
|
|
243
|
+
|
|
244
|
+
Options:
|
|
245
|
+
- `-var 'name=value'` - Set variable (passed to Terraform)
|
|
246
|
+
- `-var-file=filename` - Load variables from file (passed to Terraform)
|
|
247
|
+
- `--terragrunt-config=PATH` - Path to the Terragrunt configuration file (default: `terragrunt.hcl`)
|
|
248
|
+
|
|
249
|
+
```python
|
|
250
|
+
ExecuteTerragruntCommand(TerragruntExecutionRequest(
|
|
251
|
+
command="plan",
|
|
252
|
+
working_directory="./project_dir",
|
|
253
|
+
))
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
#### terragrunt apply
|
|
257
|
+
|
|
258
|
+
* Purpose: Applies the planned changes using the Terragrunt wrapper.
|
|
259
|
+
* When to use: After plan output is approved and developer chooses to proceed.
|
|
260
|
+
|
|
261
|
+
>Note: This is typically executed by the developer after reviewing code and plan output.
|
|
262
|
+
|
|
263
|
+
Options:
|
|
264
|
+
- `-auto-approve` - Skip interactive approval
|
|
265
|
+
- `--non-interactive` - Disables all interactive approval prompts (Terragrunt as well of Terraform)
|
|
266
|
+
- `-var 'name=value'` - Set variable
|
|
267
|
+
- `--terragrunt-config=PATH` - Use a specific Terragrunt configuration file
|
|
268
|
+
|
|
269
|
+
```python
|
|
270
|
+
ExecuteTerragruntCommand(TerragruntExecutionRequest(
|
|
271
|
+
command="apply",
|
|
272
|
+
working_directory="./project_dir"
|
|
273
|
+
))
|
|
274
|
+
```
|
|
275
|
+
|
|
276
|
+
#### terragrunt destroy
|
|
277
|
+
|
|
278
|
+
* Purpose: Destroys all infrastructure managed through the Terragrunt configuration.
|
|
279
|
+
* When to use: When the infrastructure is no longer needed.
|
|
280
|
+
|
|
281
|
+
>Note: This is typically executed by the developer once the application or environment is being decommissioned.
|
|
282
|
+
|
|
283
|
+
Options:
|
|
284
|
+
- `-auto-approve` - Skip interactive approval
|
|
285
|
+
- `--non-interactive` - Disables all interactive approval prompts (Terragrunt as well of Terraform)
|
|
286
|
+
- `--terragrunt-config=PATH` - Use a specific Terragrunt configuration file
|
|
287
|
+
|
|
288
|
+
```python
|
|
289
|
+
ExecuteTerragruntCommand(TerragruntExecutionRequest(
|
|
290
|
+
command="destroy",
|
|
291
|
+
working_directory="./project_dir"
|
|
292
|
+
))
|
|
293
|
+
```
|
|
294
|
+
|
|
295
|
+
#### terragrunt run-all apply
|
|
296
|
+
|
|
297
|
+
* Purpose: Recursively runs the `apply` command across all child Terragrunt modules in a directory tree.
|
|
298
|
+
* When to use: To apply changes across an entire environment or stack, typically in a root coordination folder.
|
|
299
|
+
|
|
300
|
+
Options:
|
|
301
|
+
- `--non-interactive` - Disables all interactive approval prompts (Terragrunt as well of Terraform)
|
|
302
|
+
- `--queue-exclude-dir` - Exclude glob path that should be excluded when issuing run-all commands. If a relative path is specified, it should be relative from working-dir.
|
|
303
|
+
- `--queue-include-dir` - Include glob path that should be included when issuing run-all commands. If a relative path is specified, it should be relative from working-dir.
|
|
304
|
+
|
|
305
|
+
```python
|
|
306
|
+
ExecuteTerragruntCommand(TerragruntExecutionRequest(
|
|
307
|
+
command="run-all apply",
|
|
308
|
+
working_directory="./live/production"
|
|
309
|
+
))
|
|
310
|
+
```
|
|
311
|
+
|
|
312
|
+
### Checkov Commands
|
|
313
|
+
|
|
314
|
+
These security scanning commands are available through dedicated tools:
|
|
315
|
+
|
|
316
|
+
#### Checkov Scan
|
|
317
|
+
|
|
318
|
+
* Purpose: Scans Terraform code for security issues, misconfigurations, and compliance violations.
|
|
319
|
+
* Tool: RunCheckovScan
|
|
320
|
+
* When to use: After code passes terraform validate but before initializing and planning.
|
|
321
|
+
|
|
322
|
+
## Key Principles
|
|
323
|
+
- **Module-First Approach**: Always check for specialized AWS-IA modules before building with individual resources
|
|
324
|
+
- **Provider Selection**: When using individual resources, prefer the AWSCC provider (Cloud Control API-based) before falling back to the traditional AWS provider
|
|
325
|
+
- **Security First**: Always implement security best practices by default
|
|
326
|
+
- **Cost Optimization**: Design resources to minimize costs while meeting requirements
|
|
327
|
+
- **Operational Excellence**: Implement proper monitoring, logging, and observability
|
|
328
|
+
- **Serverless-First**: Prefer serverless services when possible
|
|
329
|
+
- **Infrastructure as Code**: Define all infrastructure declaratively using Terraform (or Terragrunt where applicable)
|
|
330
|
+
- **Regional Awareness**: Consider regional availability and constraints for services
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
|
|
2
|
+
#
|
|
3
|
+
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
4
|
+
# you may not use this file except in compliance with the License.
|
|
5
|
+
# You may obtain a copy of the License at
|
|
6
|
+
#
|
|
7
|
+
# http://www.apache.org/licenses/LICENSE-2.0
|
|
8
|
+
#
|
|
9
|
+
# Unless required by applicable law or agreed to in writing, software
|
|
10
|
+
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
11
|
+
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
12
|
+
# See the License for the specific language governing permissions and
|
|
13
|
+
# limitations under the License.
|
|
14
|
+
|
|
15
|
+
from importlib import (
|
|
16
|
+
resources,
|
|
17
|
+
) # nosemgrep: python.lang.compatibility.python37.python37-compatibility-importlib2, python.lang.compatibility.python37-compatibility-importlib2
|
|
18
|
+
|
|
19
|
+
with (
|
|
20
|
+
resources.files('awslabs.terraform_mcp_server.static')
|
|
21
|
+
.joinpath('MCP_INSTRUCTIONS.md')
|
|
22
|
+
.open('r', encoding='utf-8') as f
|
|
23
|
+
):
|
|
24
|
+
MCP_INSTRUCTIONS = f.read()
|
|
25
|
+
|
|
26
|
+
with (
|
|
27
|
+
resources.files('awslabs.terraform_mcp_server.static')
|
|
28
|
+
.joinpath('TERRAFORM_WORKFLOW_GUIDE.md')
|
|
29
|
+
.open('r', encoding='utf-8') as f
|
|
30
|
+
):
|
|
31
|
+
TERRAFORM_WORKFLOW_GUIDE = f.read()
|
|
32
|
+
|
|
33
|
+
with (
|
|
34
|
+
resources.files('awslabs.terraform_mcp_server.static')
|
|
35
|
+
.joinpath('AWS_TERRAFORM_BEST_PRACTICES.md')
|
|
36
|
+
.open('r', encoding='utf-8') as f
|
|
37
|
+
):
|
|
38
|
+
AWS_TERRAFORM_BEST_PRACTICES = f.read()
|
|
@@ -0,0 +1,166 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: awslabs.terraform-mcp-server
|
|
3
|
+
Version: 1.0.14
|
|
4
|
+
Summary: An AWS Labs Model Context Protocol (MCP) server for terraform
|
|
5
|
+
Requires-Python: >=3.10
|
|
6
|
+
Requires-Dist: asteval>=1.0.6
|
|
7
|
+
Requires-Dist: beautifulsoup4>=4.12.0
|
|
8
|
+
Requires-Dist: checkov>=3.2.402
|
|
9
|
+
Requires-Dist: loguru>=0.7.0
|
|
10
|
+
Requires-Dist: mcp[cli]>=1.23.0
|
|
11
|
+
Requires-Dist: playwright>=1.40.0
|
|
12
|
+
Requires-Dist: pydantic>=2.10.6
|
|
13
|
+
Requires-Dist: pypdf2>=3.0.0
|
|
14
|
+
Requires-Dist: requests>=2.31.0
|
|
15
|
+
Description-Content-Type: text/markdown
|
|
16
|
+
|
|
17
|
+
# AWS Terraform MCP Server
|
|
18
|
+
|
|
19
|
+
MCP server for Terraform on AWS best practices, infrastructure as code patterns, and security compliance with Checkov.
|
|
20
|
+
|
|
21
|
+
## Features
|
|
22
|
+
|
|
23
|
+
- **Terraform Best Practices** - Get prescriptive Terraform advice for building applications on AWS
|
|
24
|
+
- AWS Well-Architected guidance for Terraform configurations
|
|
25
|
+
- Security and compliance recommendations
|
|
26
|
+
- AWSCC provider prioritization for consistent API behavior
|
|
27
|
+
|
|
28
|
+
- **Security-First Development Workflow** - Follow a structured process for creating secure code
|
|
29
|
+
- Step-by-step guidance for validation and security scanning
|
|
30
|
+
- Integration of Checkov at the right stages of development
|
|
31
|
+
- Clear handoff points between AI assistance and developer deployment
|
|
32
|
+
|
|
33
|
+
- **Checkov Integration** - Work with Checkov for security and compliance scanning
|
|
34
|
+
- Run security scans on Terraform code to identify vulnerabilities
|
|
35
|
+
- Automatically fix identified security issues when possible
|
|
36
|
+
- Get detailed remediation guidance for compliance issues
|
|
37
|
+
|
|
38
|
+
- **AWS Provider Documentation** - Search for AWS and AWSCC provider resources
|
|
39
|
+
- Find documentation for specific resources and attributes
|
|
40
|
+
- Get example snippets and implementation guidance
|
|
41
|
+
- Compare AWS and AWSCC provider capabilities
|
|
42
|
+
|
|
43
|
+
- **AWS-IA GenAI Modules** - Access specialized modules for AI/ML workloads
|
|
44
|
+
- Amazon Bedrock module for generative AI applications
|
|
45
|
+
- OpenSearch Serverless for vector search capabilities
|
|
46
|
+
- SageMaker endpoint deployment for ML model hosting
|
|
47
|
+
- Serverless Streamlit application deployment for AI interfaces
|
|
48
|
+
|
|
49
|
+
- **Terraform Registry Module Analysis** - Analyze Terraform Registry modules
|
|
50
|
+
- Search for modules by URL or identifier
|
|
51
|
+
- Extract input variables, output variables, and README content
|
|
52
|
+
- Understand module usage and configuration options
|
|
53
|
+
- Analyze module structure and dependencies
|
|
54
|
+
|
|
55
|
+
- **Terraform Workflow Execution** - Run Terraform commands directly
|
|
56
|
+
- Initialize, plan, validate, apply, and destroy operations
|
|
57
|
+
- Pass variables and specify AWS regions
|
|
58
|
+
- Get formatted command output for analysis
|
|
59
|
+
|
|
60
|
+
- **Terragrunt Workflow Execution** - Run Terragrunt commands directly
|
|
61
|
+
- Initialize, plan, validate, apply, run-all and destroy operations
|
|
62
|
+
- Pass variables and specify AWS regions
|
|
63
|
+
- Configure terragrunt-config and and include/exclude paths flags
|
|
64
|
+
- Get formatted command output for analysis
|
|
65
|
+
|
|
66
|
+
## Tools and Resources
|
|
67
|
+
|
|
68
|
+
- **Terraform Development Workflow**: Follow security-focused development process via `terraform://workflow_guide`
|
|
69
|
+
- **AWS Best Practices**: Access AWS-specific guidance via `terraform://aws_best_practices`
|
|
70
|
+
- **AWS Provider Resources**: Access resource listings via `terraform://aws_provider_resources_listing`
|
|
71
|
+
- **AWSCC Provider Resources**: Access resource listings via `terraform://awscc_provider_resources_listing`
|
|
72
|
+
|
|
73
|
+
## Prerequisites
|
|
74
|
+
|
|
75
|
+
1. Install `uv` from [Astral](https://docs.astral.sh/uv/getting-started/installation/) or the [GitHub README](https://github.com/astral-sh/uv#installation)
|
|
76
|
+
2. Install Python using `uv python install 3.10`
|
|
77
|
+
3. Install Terraform CLI for workflow execution
|
|
78
|
+
4. Install Checkov for security scanning
|
|
79
|
+
|
|
80
|
+
## Installation
|
|
81
|
+
|
|
82
|
+
| Kiro | Cursor | VS Code |
|
|
83
|
+
|:----:|:------:|:-------:|
|
|
84
|
+
| [](https://kiro.dev/launch/mcp/add?name=awslabs.terraform-mcp-server&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22awslabs.terraform-mcp-server%40latest%22%5D%2C%22env%22%3A%7B%22FASTMCP_LOG_LEVEL%22%3A%22ERROR%22%7D%7D) | [](https://cursor.com/en/install-mcp?name=awslabs.terraform-mcp-server&config=eyJjb21tYW5kIjoidXZ4IGF3c2xhYnMudGVycmFmb3JtLW1jcC1zZXJ2ZXJAbGF0ZXN0IiwiZW52Ijp7IkZBU1RNQ1BfTE9HX0xFVkVMIjoiRVJST1IifSwiZGlzYWJsZWQiOmZhbHNlLCJhdXRvQXBwcm92ZSI6W119) | [](https://insiders.vscode.dev/redirect/mcp/install?name=Terraform%20MCP%20Server&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22awslabs.terraform-mcp-server%40latest%22%5D%2C%22env%22%3A%7B%22FASTMCP_LOG_LEVEL%22%3A%22ERROR%22%7D%2C%22disabled%22%3Afalse%2C%22autoApprove%22%3A%5B%5D%7D) |
|
|
85
|
+
|
|
86
|
+
Configure the MCP server in your MCP client configuration (e.g., for Kiro, edit `~/.kiro/settings/mcp.json`):
|
|
87
|
+
|
|
88
|
+
```json
|
|
89
|
+
{
|
|
90
|
+
"mcpServers": {
|
|
91
|
+
"awslabs.terraform-mcp-server": {
|
|
92
|
+
"command": "uvx",
|
|
93
|
+
"args": ["awslabs.terraform-mcp-server@latest"],
|
|
94
|
+
"env": {
|
|
95
|
+
"FASTMCP_LOG_LEVEL": "ERROR"
|
|
96
|
+
},
|
|
97
|
+
"disabled": false,
|
|
98
|
+
"autoApprove": []
|
|
99
|
+
}
|
|
100
|
+
}
|
|
101
|
+
}
|
|
102
|
+
```
|
|
103
|
+
### Windows Installation
|
|
104
|
+
|
|
105
|
+
For Windows users, the MCP server configuration format is slightly different:
|
|
106
|
+
|
|
107
|
+
```json
|
|
108
|
+
{
|
|
109
|
+
"mcpServers": {
|
|
110
|
+
"awslabs.terraform-mcp-server": {
|
|
111
|
+
"disabled": false,
|
|
112
|
+
"timeout": 60,
|
|
113
|
+
"type": "stdio",
|
|
114
|
+
"command": "uv",
|
|
115
|
+
"args": [
|
|
116
|
+
"tool",
|
|
117
|
+
"run",
|
|
118
|
+
"--from",
|
|
119
|
+
"awslabs.terraform-mcp-server@latest",
|
|
120
|
+
"awslabs.terraform-mcp-server.exe"
|
|
121
|
+
],
|
|
122
|
+
"env": {
|
|
123
|
+
"FASTMCP_LOG_LEVEL": "ERROR",
|
|
124
|
+
"AWS_PROFILE": "your-aws-profile",
|
|
125
|
+
"AWS_REGION": "us-east-1"
|
|
126
|
+
}
|
|
127
|
+
}
|
|
128
|
+
}
|
|
129
|
+
}
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
|
|
133
|
+
or docker after a successful `docker build -t awslabs/terraform-mcp-server .`:
|
|
134
|
+
|
|
135
|
+
```json
|
|
136
|
+
{
|
|
137
|
+
"mcpServers": {
|
|
138
|
+
"awslabs.terraform-mcp-server": {
|
|
139
|
+
"command": "docker",
|
|
140
|
+
"args": [
|
|
141
|
+
"run",
|
|
142
|
+
"--rm",
|
|
143
|
+
"--interactive",
|
|
144
|
+
"--env",
|
|
145
|
+
"FASTMCP_LOG_LEVEL=ERROR",
|
|
146
|
+
"awslabs/terraform-mcp-server:latest"
|
|
147
|
+
],
|
|
148
|
+
"env": {},
|
|
149
|
+
"disabled": false,
|
|
150
|
+
"autoApprove": []
|
|
151
|
+
}
|
|
152
|
+
}
|
|
153
|
+
}
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
## Security Considerations
|
|
157
|
+
|
|
158
|
+
When using this MCP server, you should consider:
|
|
159
|
+
- **Following the structured development workflow** that integrates validation and security scanning
|
|
160
|
+
- Reviewing all Checkov warnings and errors manually
|
|
161
|
+
- Fixing security issues rather than ignoring them whenever possible
|
|
162
|
+
- Documenting clear justifications for any necessary exceptions
|
|
163
|
+
- Using the RunCheckovScan tool regularly to verify security compliance
|
|
164
|
+
- Preferring the AWSCC provider for its consistent API behavior and better security defaults
|
|
165
|
+
|
|
166
|
+
Before applying Terraform changes to production environments, you should conduct your own independent assessment to ensure that your infrastructure would comply with your own specific security and quality control practices and standards, as well as the local laws, rules, and regulations that govern you and your content.
|