Using Claude Code as a Database SRE Agent with the Everpure Fusion MCP Server

Here’s the scenario: one of my SQL Server instances migrated to the DR array. The VM moved, the old volumes were destroyed, and nobody created a Protection Group on the destination. There were no alerts. Nothing failed.

The DR environment just quietly had no data protection. No snapshots, no replication. We’d have had no idea until we needed to recover. Ok, well this was in my lab, but this could really happen in the real world.

I found out because Claude Code told me.

I’ve been building a Database SRE agent using Claude Code, the Everpure Fusion MCP server, and a custom set of skill files that encode my fleet topology, SLA tiers, and compliance policies. Two prompts, about 50 API calls, and it produced a compliance report that would have taken me a couple of hours of manual REST API work to build.

This is part two of a series on MCP and SQL Server. In Giving AI Agents Visibility Into SQL Server with MCP, I built a custom MCP server that gives an agent direct DMV access into SQL Server itself. This post does the same thing one layer down, at the storage underneath it, using Pure Storage’s Fusion MCP server instead.

In this post I’ll show how it’s set up, what it ran against a live fleet, and what it found. Let’s go.

Update, September 2026: since I first published this, mcp-server-demos split the single database-sre-agent.md file into a skills/ directory, one file per topic, and added new skills for provisioning, ticketing, incident response, DR readiness, and volume mapping, plus a mandatory FlashBlade backup-compliance check. The links below point at the current file structure. The report output further down is the original run and predates that FlashBlade requirement; I call out where that matters as we get there.

What Is the Fusion MCP Server?

MCP (Model Context Protocol) is an open standard that lets AI agents interact with external tools and systems in a structured way. The Everpure Fusion MCP server exposes the Fusion Fleet API as a set of MCP tools that a Claude Code agent can call directly from your terminal or IDE. You can find it at PureStorage-OpenConnect/fusion-mcp-server.

Once it’s configured, Claude Code can query your entire Everpure Fusion fleet, pull performance metrics, inspect Protection Groups, read volume tags, and check replication status, all without you writing a single line of PowerShell, Python or REST calls.

In my lab, that’s six FlashArrays and two FlashBlades, spread across two sites and three availability zones. The FlashBlades were out of scope when I first ran this, since I was focused on SQL Server block storage, but they’re configured so the agent has full fleet visibility. The skill set has since grown a mandatory FlashBlade backup-compliance check, which I’ll call out when we get to Compliance & Audit.

The Database SRE Skill Files

The key to making this work well is giving the agent skill files, Markdown documents that define its role, priorities, thresholds, and decision-making rules. Think of it as a runbook combined with a persona definition. Two of them drive the reports in this post: 04-operational-visibility.md for “Real-Time Operational Visibility” and 02-compliance-audit.md for “Compliance & Audit,” both in the mcp-server-demos repo.

Here’s the current shape of the operational-visibility skill, showing its procedure and thresholds:

# Skill: Real-Time Operational Visibility

**When this applies**: the user asks for current health, capacity, or performance
posture of the fleet — alerts, hardware health, replication lag, "days to full,"
or latency against SLA.

## Procedure

- Surface active alerts with severity, affected resource, and estimated time-to-impact.
- Report array hardware health (controllers, drives, power, fans).
- Monitor replication lag — RPO violations in a financial environment are a
  compliance issue, not just an operations issue.
- Highlight unencrypted replication links; all replication should be encrypted
  in a regulated environment.
- Report physical capacity utilization per array with a `% used` column.
- Calculate "days to full" projections from historical space samples over a
  defined window, and state the window used.
- Flag provisioning overcommit; use `used_provisioned / capacity`, not
  `space.thin_provisioning`.
- Track latency per array and per volume against workload tier SLAs.

## Thresholds: what "good" looks like

| Metric | Healthy | Warning | Critical |
|---|---|---|---|
| Capacity `% used` | < 70% | 70–85% | ≥ 85% (escalate), ≥ 90% (critical) |
| Tier 1 latency (trading, OLTP) | < 0.5 ms | — | ≥ 0.5 ms |
| Tier 2 latency (general databases) | < 2 ms | — | ≥ 2 ms |
| Tier 3 latency (batch, archive) | < 10 ms | — | ≥ 10 ms |

Notice these are hard numbers, not “seems high” or “looks fine.” That’s what makes the report repeatable instead of a vibe check.

You can get the whole skill set here: skills/, starting with 00-global.md for the persona, guardrails, and the routing table that tells the agent which of the other files to load.

What the Skill Files Encode

The skill set also encodes fleet-specific knowledge, most of it now consolidated in 00-reference.md: which arrays are in which availability zones, what the HA placement rules are for SQL Server pairs, and how to use volume and protection group tags (sql_instance, databases, windows_drive) to correlate FlashArray volumes and protection groups back to SQL Server databases and their instances.

Before this, a compliance check against this fleet meant opening each array’s REST API/PowerShell/Python individually, cross-referencing PG configurations against notes or a configuration database, checking retention schedules and encryption status on each PG. For six arrays and five SQL Server instances, that’s easily an hour or two of careful (and brittle) work. Work that’s easy to skip when things seem fine. This skill-file approach means the agent does that consistently, every time you ask.

Running the Agent

CLAUDE.md bootstraps the agent automatically at session start, pointing it at skills/00-global.md and skills/00-reference.md, which always load first, plus a routing table that sends it to whichever topic file the task needs. The @ prefix in the prompts below is Claude Code’s file-mention shorthand; it inlines a file’s contents into the context. I use it explicitly in demos so the audience can see what’s directing the agent’s behavior. Here are the two prompts that drove the workflows in this post:

You're a Database SRE agent. Your skills and workflows are defined in @skills/04-operational-visibility.md. Produce the "Real-Time Operational Visibility" report.

Great, now do the "Compliance & Audit" report.

Each of those prompts drives the agent through dozens of API calls, cross-references the results against policy, and produces a structured report. The second one doesn’t even need to name a skill file explicitly; the global routing table it already loaded tells it to route to 02-compliance-audit.md on its own. We’ll look at some example output in a minute.

Fleet Awareness

Before running any workflow, 01-fleet-awareness.md tells the agent to establish fleet topology first, before anything else, so every other skill queries against a known map instead of guessing. It calls the list_arrays tool to identify which arrays are configured with direct API access, then calls get_fleet_overview with brief=false and include_alerts=true to see all fleet members and their alerts.

That brief=false detail isn’t decoration. get_fleet_overview defaults to brief=true, and include_alerts is only honored when brief is false, so passing include_alerts=true alone still comes back as a clean, alert-free fleet. It’s exactly the kind of field trap that reads as a passing report while quietly hiding every alert on the fleet, and it’s why a dedicated Field Traps reference file exists now, cataloging the fields whose obvious reading gives a confident, wrong answer.

Here’s the fleet topology from the agent’s output:

Note: sn1-x90r2-f05-27 and sn1-x90r2-f05-33 are not members of the Fusion fleet and each is configured with API tokens and queryable directly. Fleet-level operations can’t route through the gateway to these arrays. Their Purity versions are not available via fleet overview. You can interact with these arrays directly via the Fusion MCP Server but they can’t be managed by tools that operate at the fleet level like get_fleet_overview. The skill files now have a name for this: a fleet-management gap, one of two coverage gaps they check for in both directions, the other being a fleet member with no direct API access configured at all.

Real-Time Operational Visibility

Once fleet topology is established, the agent ran the Real-Time Operational Visibility workflow. It queries every configured array and produces a report covering hardware health, active alerts, capacity utilization, and performance against tier SLA thresholds…all the things a database SRE would be interested in at a specific point in time.

In the next sections of this post, I’ll walk you through the output of this report, starting with the first section “Health and Alerting” here:

That connecting state on sn1-x90r2-f06-27’s fleet link is the biggest issue in this section. The alert query timed out through the gateway, so the actual alert state of that array is unknown without querying it directly. This array in my lab is intentionally broken for demonstration purposes, in real life you’ll want to correct this error before relying on any fleet-routed operations against it.

The agent reported physical utilization and snapshot consumption separately from primary data, and calculated days-to-full projections for each array, judged against the same capacity thresholds from the table above.

Here’s the output from the capacity section of the report:

The agent also reports that:

sn1-c60-e12-16 is within capacity thresholds but 19.9 TiB of its 36.4 TiB used space is snapshots — 49% snapshot share on a DR array is worth monitoring for runaway growth.

But the reality of this, is that this is a FlashArray //C being used primarily as a snapshot target, so this usage is actually fine. So this becomes an opportunity to go back to 04-operational-visibility.md and embed this knowledge there so it can properly interpret the data here.

The agent pulled latency, IOPS, and throughput per array and mapped results against the same tier SLA thresholds from the table above.

One detail worth calling out: the Pure Storage REST API returns latency in microseconds (usec_per_read_op, usec_per_write_op). That conversion used to live inline in the performance section of the old file; it’s now centralized in 00-reference.md’s Key Formulas & Units table, which every skill file cites instead of restating. Same rule, one source of truth instead of five copies that could quietly drift apart. Without that instruction encoded somewhere the agent actually reads, every latency comparison would be off by a factor of 1000.

Here’s what the agent reported across the configured arrays:

Every array is within SLA this run. This is my lab array, so not a TON of production grade workloads here — your mileage will certainly vary once you point this at something bigger.

Some highlights:

• sn1-x90r2-f05-27 is carrying the heaviest read load in the fleet at 4,532 read IOPS and 212.5 MB/s, yet latency sits at 0.151 ms well within Tier 1.
• sn1-x90r2-f05-33 has a san_usec_per_read_op of 206 µs, the highest SAN fabric latency in the fleet by a wide margin. Most arrays show 22–87 µs for SAN read latency; f05-33’s fabric is contributing nearly as much latency as the array itself. This is an outlier worth investigating before it becomes user-visible.
• sn1-c60-e12-16 (DR) is at 0.405 ms read latency within Tier 1 but the closest to the 0.5 ms threshold in the fleet.

Compliance & Audit

This is where the agent found the most actionable findings. For each SQL Server instance, the Compliance and Audit workflow checks whether volumes are in a Protection Group, whether the PG has active replication, whether the link is encrypted, and whether snapshot schedules and retention meet policy. Here we’ll walk through the highlights of the report; you can find the full report definition in 02-compliance-audit.md in the mcp-server-demos repo. For my five SQL Server instances (aen-sql-25-a through aen-sql-25-dr), the agent runs through each subsection in turn.

Here’s the current layout of my SQL Server instances and their local and remote snapshot configurations.

Looking at the table above you’ll find two CRITICAL findings are at the bottom. aen-sql-25-dr migrated to sn1-c60-e12-16 with no Protection Group created on the destination. No snapshots, no replication. The DR environment itself has no DR. aen-sql-25-d looks protected on paper (the PG name exists), but the PG contains zero volumes with both schedules disabled. It’s an empty shell that gives a false sense of coverage.

aen-sql-25-c is a different but equally serious situation: snapshots are running locally, but the only replication target is gso-cbs-azure and its status is disallowed. No remote copies exist. One array failure and there’s no offsite recovery path. aen-sql-25-a and aen-sql-25-b are the healthiest in the set but still have gaps: local retention is 3 days when policy requires 7, and every functioning async link is unencrypted.

Why Tagging Matters

I heavily use tags in Purity to help add database context to storage objects like volumes and protection groups. In my tagging scheme for SQL Server the required tags per volume are sql_instance, databases, and windows_drive. Protection Groups must also carry an sql_instance tag. This means I can come along later and easily correlate which SQL Server and also which databases live where in my environment. So I can quickly answer the question…“if f07-27 is down, which databases are impacted”.

Any gaps in my tagging scheme means I’ll have blind spots on where data lives in my infrastructure. Below, the agent is reporting on which SQL Servers are not compliant with my tagging policy defined in 02-compliance-audit.md.

I also included in the compliance report what good looks like for replication of my protection groups between AZs and between data centers as well as stating that all replication links should be encrypted.

Here’s what the agent surfaced in the report based on 02-compliance-audit.md’s replication policy.

00-reference.md encodes the rule: A+B must be in different AZs; C+D must be in different AZs; systems ending in DR must be in the DR zone.

Here’s the current layout of my HA placement in my Fleet:

Managing configuration drift can be challenging in a large enterprise. In 02-compliance-audit.md we encoded knowledge about what good looks like in our environment, and now the agent can easily expose this drift to us in our report.

Here’s what it found in my lab environment that’s a bit…askew.

Now, I also defined in 02-compliance-audit.md that I want it to give me a summary by severity which will help me understand the current state of my environment at a macro level, very quickly. Here’s that section of our report.

Here’s that listing of findings by severity:

Once the audit was done, I asked for a remediation plan. Below is what came back, ordered by severity and effort. We have a lot of work ahead of us to sort this environment out. So perhaps the next step is to have the agent create tickets for each of these issues so we can go about remediating the environment to get things back into shape.

Here’s the prioritized remediation plan:

What’s Changed Since This Run

The Compliance & Audit skill has grown a hard requirement since I captured this report: every SQL Server backup landing zone, an NFS or SMB share, an S3 bucket, wherever BACKUP TO DISK or backup-to-URL actually lands, now has to replicate to the DR site, checked against the same fleet topology table used for Protection Groups. sn1-s200-c09-33 and slc6-fbs200-n3-b35-12, the two FlashBlades I called out of scope earlier, are exactly the arrays this new check runs against. Run this report again today and you’d get a Backup Landing Zone DR Replication table alongside everything below, scored CRITICAL for any landing zone with no DR copy, the file-and-object equivalent of a volume with no Protection Group. The report captured here predates that check.

Bringing Database Context to the Storage World

Remember I told you earlier how much I like tagging, here’s why…after running the full compliance audit, I asked the agent to rank every database by risk based off the current state of my environment.

Here’s what the agent is telling me is at risk in my environment in database terms, not storage terms:

Tags in Purity keep the focus on what actually matters here: the data. With tags and Fusion MCP, you can find the risk in your environment fast, and fix it just as fast.

Will You Use Agents to Monitor Your Environment?

The finding that stuck with me was aen-sql-25-dr. I migrated a SQL Server instance to the DR array. The VM moved, the old volumes were destroyed. But I didn’t create a Protection Group on the destination. The system ran perfectly. No alert fired. From every operational signal, everything looked fine. It just had no recovery path.

That’s the kind of gap you only catch by actually checking, not by waiting for an alert that’ll never come. The agent answered a different question than “are there any active alerts.” It asked: “is every SQL Server instance in this fleet actually protected, and does that protection meet policy?” In a regulated environment, those are two different questions.

The skill files are what make the answer specific to my environment rather than generic. Without them, I’d get answers framed around what the API surface exposes. With them, the agent knows that aen-sql-25-dr should be in the DR zone, that Protection Groups need to survive VM migrations, that local retention below 7 days is a policy violation, that HA pairs must span availability zones. It knows my fleet, not just the API.

The honest tradeoff: the skill files take effort to write and keep current. Fleet topology changes, policies get updated. But a well-maintained skill set means a 10-minute compliance audit instead of a 2-hour one and one that actually runs consistently instead of when someone has time. Further, you could integrate this into a configuration management system or deployment system so that the agents know the starting points of the environment…which will shift you from managing skill files like these for state and have them just focus on the rules.

Get the Code

The Fusion MCP server is available at PureStorage-OpenConnect/fusion-mcp-server. My skill files now live in the skills/ directory of the mcp-server-demos repo, along with the demo scripts.

Wrapping Up

Those aren’t hypothetical findings. If you’re running SQL Server on Pure Storage today, I’d encourage you to point something like this at your environment and see what it finds. The gaps that matter most are rarely the ones with active alerts.

Let me know how it works in your environment.

MCP + SQL Server series:

1. Giving AI Agents Visibility Into SQL Server with MCP
2. Using Claude Code as a Database SRE Agent with the Everpure Fusion MCP Server (This Post)
3. Building a DBA Agent for Your SQL Server Estate with MCP