Artificial Intelligence is becoming increasingly useful in DevOps, but most AI tools still rely only on their training data. This means they can suggest solutions, but they often can’t interact with your real infrastructure or validate whether their suggestions actually work.
In this beginner-friendly guide, I’ll walk through my hands-on experience using Model Context Protocol (MCP) with Claude Code to audit, fix, and verify Terraform security issues automatically. By the end, you’ll understand what MCP is, why it matters, and how it enables AI to safely work with real tools like Terraform and AWS.
What is Model Context Protocol (MCP)?
Model Context Protocol (MCP) is a framework that allows AI models to connect to external tools and data sources in a structured and secure way. Instead of relying only on static knowledge from training, MCP lets AI access:
- Local development tools (like Terraform or Git)
- Cloud APIs (such as AWS)
- Project files and configurations
This means the AI can not only suggest changes but also validate and execute them using real software.
Why MCP is Important for DevOps
In traditional AI-assisted development, you might ask a model how to fix a Terraform issue, and it would generate code based on patterns it learned during training. However, it cannot confirm whether:
- the syntax is correct,
- the provider version supports the configuration,
- or the change actually resolves the problem.
With MCP, the AI can:
- Analyze your real Terraform files.
- Modify them.
- Run Terraform commands to validate the changes.
This creates a much safer and more reliable automation loop for infrastructure work.
My Setup: Connecting Claude Code to Terraform and AWS
To enable this workflow, I configured two MCP servers in my project:
- Terraform MCP server running in Docker
-
AWS API MCP server using Python’s
uvxruntime
These were defined in a .mcp.json file at the root of my project. This file tells Claude Code which tools it is allowed to start and how to communicate with them.
Sensitive information such as AWS credentials was stored separately in .claude/settings.local.json to keep secrets out of version control.
Once everything was configured, I ran the /mcp command in Claude Code and confirmed both servers were successfully connected.
Running a Real DevOps Workflow: Audit → Fix → Verify
To test the setup, I ran a simple but realistic workflow on my Terraform project.
Step 1: Auditing Terraform for Security Issues
I asked Claude Code:
Audit my Terraform files for security issues
The security-auditor agent scanned my Terraform configuration and flagged a problem:
My S3 bucket did not have server-side encryption enabled.
This is a common security issue because unencrypted storage can expose sensitive data if accessed improperly.
Step 2: Automatically Fixing the Issue
Next, I asked Claude:
Add S3 server-side encryption to my Terraform code using AES256
The tf-writer agent updated my Terraform configuration by adding a server-side encryption block to the S3 bucket resource. Behind the scenes, it used the Terraform MCP server to ensure the syntax and resource configuration were valid for my environment.
This step was important because it ensured the AI-generated code was not just theoretically correct but actually compatible with the Terraform version and provider I was using.
Step 3: Verifying the Fix
Finally, I ran the audit again:
Audit my Terraform files for security issues
This time, the encryption issue was no longer reported. The system confirmed that the configuration was now compliant with recommended security practices.
This completed the full audit → fix → verify loop without me manually editing a single Terraform file.
Understanding the Role of AI Agents in This Workflow
One of the most interesting lessons from this exercise was how different AI agents used MCP differently.
The Security Auditor Did Not Need MCP
The security-auditor agent only needed to read Terraform files and apply known security best practices. Since Terraform is a text-based configuration language, the AI could analyze it without running any external tools.
The Terraform Writer Did Need MCP
The tf-writer agent, on the other hand, needed MCP because it had to:
- generate new Terraform code,
- validate it using the real Terraform binary,
- and ensure the configuration would not break the infrastructure deployment.
This clearly showed that reasoning tasks can often be done without tool access, while execution and validation tasks require MCP.
Key Takeaways for Beginners
If you’re new to MCP and AI-assisted DevOps, here are the main lessons from this experience:
- MCP allows AI to work with live tools instead of relying only on training data.
- This makes AI-generated changes more reliable and safer to apply in real environments.
- Separating configuration (
.mcp.json) from secrets (settings.local.json) is critical for security. - Not every AI task needs tool access — but any task that modifies or validates infrastructure usually does.
Why This Matters for the Future of DevOps
As infrastructure becomes more complex, the ability to automate not just code generation but also validation and compliance checks will be a major advantage. MCP represents a step toward AI systems that can act as true assistants in DevOps pipelines, capable of performing real tasks while still operating within controlled and secure boundaries.
For beginners, learning MCP now provides a strong foundation for understanding how AI will integrate into future cloud and platform engineering workflows.
If you’re exploring Terraform, cloud security, or AI-assisted development, experimenting with MCP is a great way to see how these technologies can work together in practical, real-world scenarios.
Till next time, always stay positive 👍
Shout out to Pravin Mishra, Lead Co-Mentor: Praveen Pandey
🤝 Co-Mentors: Egwu Oko, Tanisha Borana, Ranbir Kaur
P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this
Discord community ( https://lnkd.in/e4wTfknn ).
Top comments (0)