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 skills file that encodes 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.

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.

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 are out of scope for this post since we’re focused on SQL Server block storage, but they’re configured so the agent has full fleet visibility.

The Database SRE Skills File

The key to making this work well is giving the agent a skills file, a Markdown document that defines its role, priorities, thresholds, and decision-making rules. Think of it as a runbook combined with a persona definition. Additionally, the skills file I’m developing includes compliance reports like the “Real-Time Operational Visibility” and “Compliance & Audit”, which you can find in the mcp-server-demos repo.

Here are some snippets from the skill file showing how the two reports are constructed:

## Real-Time Operational Visibility

### Health & Alerting

- 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.

### Capacity Management

- Report physical capacity utilization per array with a `% used` column.
- Calculate "days to full" projections based on recent growth trends.
- Flag thin provisioning overcommit ratios — high overcommit on a near-full array is a risk.
- **Thresholds**: warn at 70%, escalate at 85%, critical at 90%.
- Always present snapshot consumption separately from primary data consumption.

### Performance SLA Monitoring

- Track latency per array and per volume against workload tier SLAs:
  - Tier 1 (trading, OLTP): < 0.5 ms
  - Tier 2 (general databases): < 2 ms
  - Tier 3 (batch, archive): < 10 ms
- Note: latency values from the API are in **microseconds** (`usec_per_*`); divide by 1000 for milliseconds.
- Identify latency outliers — volumes or arrays performing significantly worse than their peers.
- Track IOPS and throughput trends to detect degradation before users notice.

You can get the whole file here database-sre-agent.md.

What the Skills File Encodes

The skills file also encodes fleet-specific knowledge: 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. The skills file approach means the agent does that consistently, every time you ask.

Running the Agent

I include database-sre-agent.md in CLAUDE.md so Claude Code loads it automatically at session start. The @ prefix in the prompts below is Claude Code’s file-mention shorthand; it inlines the 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 @database-sre-agent.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 re-specify the skills file; the agent already has that context from the first prompt. We’ll look at some example output in a minute.

Fleet Awareness

Before running any workflow, the skills file tells the agent to establish fleet topology. It calls the list_arrays tool to identify which arrays are configured with direct API access, then calls the get_fleet_overview tool to see all fleet members.

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 cannot 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 cannot be managed by tools that operate at the fleet level like get_fleet_overview.

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 will 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. Thresholds: warn at 70%, escalate at 85%, critical at 90% as defined in the skills file.

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 the skill file 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 tier SLA thresholds defined in the skills file which are:

 Track latency per array and per volume against workload tier SLAs:
  - Tier 1 (trading, OLTP): < 0.5 ms
  - Tier 2 (general databases): < 2 ms
  - Tier 3 (batch, archive): < 10 ms

One detail worth calling out: the Pure Storage REST API returns latency in microseconds (usec_per_read_op, usec_per_write_op). The skills file explicitly tells the agent to divide by 1000 before comparing against SLA thresholds, which are expressed in milliseconds. Without that instruction encoded in the skills file, 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.

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 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 the skill file.

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 the skills file’s replication policy.

The skills file 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 our skills file 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 the skills file 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:

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:

Leveraging tags in Purity allows you to immediately focus on what matters most in your environment, the data. Using Tags and Fusion MCP you can very quickly identify the risk in your environment and mitigate that risk.

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 skills file is what makes the answer specific to my environment rather than generic. Without it, I’d get answers framed around what the API surface exposes. With it, 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 skills file takes effort to write and keep current. Fleet topology changes, policies get updated. But a well-maintained skills file 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 a skill file like this for state and have it just focus on the rules.

Get the Code

The Fusion MCP server is available at PureStorage-OpenConnect/fusion-mcp-server. My database-sre-agent.md skills file is in 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.