How to Use a MCP Server with Terraform: 6 Prompts for Infrastructure Teams

Platform engineers spend a surprising amount of time on questions that should answer themselves: which workspaces failed overnight, whether anything has drifted, whether last week's compliance posture looks the same as this week's. These checks happen constantly, in standups, in incident channels, before deploys, and they almost always require someone to go looking for the answer manually.

Scalr's MCP server changes that. When you connect it to an AI client like Claude, your entire Scalr account becomes conversational: workspaces, run history, environments, variables, policy groups, access controls, billing data. The prompt you type is the interface.

The six prompts below are starting points. Each one is worth saving, either as a reference or as a standing instruction in your AI client so it applies the right structure automatically, without you having to repeat yourself each time.

Before you start: make your prompts specific

Scalr MCP has read access to your account, which means broad prompts return broad results. The more context you give, the more useful the output.

Four things narrow a prompt down quickly:

• Which workspaces or environments are you asking about?
• What condition are you filtering for, such as a run status, a version, or a missing configuration?
• What time window matters, such as last 7 days, last 30, or a specific date?
• How do you want the output, such as a table, a ranked list, or a Slack ready summary?

The prompts

1. Morning infrastructure check

Most teams have some version of a daily status check: a Slack message, a dashboard tab, a quick scan of recent runs. This prompt replaces that manual round.

"Give me a status overview of all workspaces in my Scalr account. Group by environment, include current run status and Terraform version, and flag anything that's failed or hasn't had a successful run in the last 14 days."

The 14 day staleness flag is the part that tends to surface things no one's actively watching. Workspaces don't always announce when they stop working. Sometimes they just quietly stop.

Save it as a morning standing instruction so your AI automatically applies the same grouping and staleness threshold every time you ask for an overview, without you specifying it.

2. Incident triage

When something breaks, the first few minutes are about narrowing scope: is this one workspace or several, is it a provider authentication issue or a resource conflict, is it production or just dev? This prompt is built for that moment.

"Show me all failed or errored runs from the last 24 hours. For each one, include the workspace, the environment it belongs to, and a summary of what the plan log says went wrong."

The plan log summary does the real work here. A bare list of failed workspaces tells you where to look; the log summary tells you what you're looking at when you get there.

For teams that want this broken out by risk level: add "separate production from non production environments, and group any non production workspaces that share the same error type." That small addition changes a flat failure list into a triage ready breakdown.

3. Drift triage

Drift accumulates quietly. A manual change here, a partially applied run there, and suddenly your Terraform state and your actual infrastructure disagree in ways that won't show up until something tries to use them.

"Which workspaces currently have drift? List by environment and include how long each workspace has been in a drifted state and when it last had a successful apply."

Duration is the detail most drift views leave out, and it's the most useful signal. A workspace that's been drifted for three hours is probably a recent incident. A workspace that's been drifted for three weeks is a different conversation.

Save it as a standing instruction that ranks by drift duration and flags anything over 48 hours, so you always see the highest risk drift first instead of sorting through an alphabetical list.

4. Variable and secrets hygiene

Variables are where configuration inconsistencies and security gaps tend to live. Sensitive values stored without the sensitive flag set, workspace level overrides quietly contradicting environment level settings, the same variable defined differently across workspaces that are supposed to be in sync. None of this shows up in run logs until it causes a failure.

"List all variables across my workspaces. Flag any that appear to contain sensitive values (credentials, tokens, keys) that aren't marked as sensitive. Also flag any variable that's defined differently across workspaces within the same environment."

If you run this regularly, add: "Separate Terraform input variables from shell environment variables, and show workspace level overrides separately from environment level settings." Without that separation, the source of a variable conflict is much harder to read.

5. Policy and access coverage

Policy groups and access assignments tend to drift over time, not dramatically, but persistently. New workspaces get added without being assigned to a policy group. Service accounts accumulate access that no one's reviewed recently. This prompt makes a periodic governance check something you can run in thirty seconds instead of an hour.

"Which workspaces aren't assigned to any OPA policy group? Group by environment and include each workspace's last run date. Also flag any environments where a service account's access hasn't been reviewed in the last 90 days."

One important addition when using this prompt for governance work: ask for a preview before anything gets changed. Policy and access modifications at scale are difficult to undo, and the review step creates a natural record of what was assessed and what decision was made.

6. The standing report

The weekly infrastructure update. The prerelease health check. The quarterly compliance summary. Whatever recurring report your team produces on a schedule, it probably covers the same ground every time, and the time spent producing it is mostly formatting, not thinking.

"Generate an infrastructure health report for the production environment covering the last 7 days. Format it for Slack: key status metrics, anything that needs immediate attention, and one recommended action."

The prompt gets you the report. The standing instruction makes it repeatable:

"For weekly infrastructure reports, always include: workspace count by status, the most notable change from the previous week, one workspace or environment behaving outside the norm, and a single recommended action. Five bullets, no more. Write it for engineers who already know the context."

The five bullet constraint is worth keeping. It forces prioritization, which is what a standing report should do: surface what matters, not document everything.

Using prompts together

The prompts above are most useful when you treat them as a sequence rather than isolated checks. A useful pattern: start with scope, narrow to signal, go deep on the instance.

In practice:

1. Run the drift triage prompt to surface everything that's out of sync.
2. Ask a follow up on the highest priority workspaces: what changed, and when relative to recent runs?
3. Pull the run history for the workspace with the longest drift: what was different in the days before it started?

Three prompts. You've gone from "there's drift somewhere" to a specific root cause hypothesis. The same pattern works for failures (fleet → environment → specific workspace logs) and for variable issues (full audit → flagged workspaces → history of changes for the ones that matter).

Getting started: Connect the Scalr MCP server in your AI client settings. Once it's connected, you have live access to your account. No SQL, no API calls, no switching tabs.