Building an MCP Server for High-Performance NAS. Architecture, Health Checks, Multi-Agent Workflows, and Safety Boundaries
Lafayette
Wed Sep 30 | 4:35pm
Abstract
Storage systems are starting to sit inside AI-driven operations, and the usual GUI, CLI, and static automation don't cover what that requires. This talk is about an MCP server we built to manage a high-performance NAS: the control-plane integration, the operational workflows, the continuous health checks, and the interaction patterns that keep AI agents from doing something stupid.
I'll go through the server architecture, how management is modeled, and how we actually built it, with the goal of exposing storage capabilities to agents without giving up determinism, observability, or safety. I also want to be honest about the hard parts. Translating storage operations into something an agent can use correctly is harder than it sounds. Keeping stateful workflows from drifting is harder still. Getting end-to-end health checks to mean something, and blocking actions that are unsafe or just ambiguous, took more iterations than I'd like to admit.
The second half is about multi-agent systems talking to storage, why that's interesting, and what it unlocks. I'll walk through scenarios pulled from real situations: agents handling monitoring, diagnosis, and operational work against the NAS through the MCP layer. Then the more uncomfortable ones, where agents try to route around constraints we deliberately put in their way.
Related Sessions
NVMe 2.3 Power Limit Config: Giving Hosts Better Control of SSD Power Behavior
As SSDs are designed into thinner systems, tighter thermal envelopes, and more dynamic platform power budgets, hosts need better ways to manage storage power without relying on static assumptions or bespoke implementations. NVMe 2.3 introduces Power Limit Config, a new feature that lets software express an SSD power target in watts and receive a revised power-state view from the controller.
This session explains what that seemingly simple capability changes in practice. We will look at how a watt-level limit reshapes the power states exposed to the host, how that affects autonomous power transitions and power-management policy, and what firmware and platform software must get right as limits change over time. We will also place the feature alongside related NVMe power-management capabilities to show how it fits into real platform design.
Attendees will learn:
* Why dynamic SSD power limits matter for modern systems
* How NVMe 2.3 translates a watt cap into host-visible power choices
* What implementation issues SSD, firmware, BIOS, and OS teams should anticipate
NVMe SSD Management: What NVMe-MI is, What is in use, & What to work on next year?
Whether your use-case for NVMe(tm) SSDs is for computation, bulk storage, or AI, NVMe-MI(tm) is the management interface standard for PCIe(r) attached SSDs. NVMe-MI defines the architecture and command set for out-of-band management of an NVMe SSD as used by most BMC implementations. The OCP NVMe SSD Specification, a set of requirements for Enterprise and Data Center SSDs, requires support of NVMe-MI and specific NVMe-MI features.
This session will be presented by the co-chairs of NVMe-MI. Attendees should learn:
* an overview of NVMe-MI's capabilities;
* the NVMe-MI features required in the OCP NVMe SSD Specification;
* what has previously changed and has just changed in 2026 version of NVMe-MI; and
* what big capabilities are likely to be explored in the coming year.
The NVMe™ Live Migration Story
With the support of Exported NVM Subsystem for PCIe® NVMe SSDs and management of bandwidth/IOPS for each NVMe controller, NVM Express™ has completed the Live Migration story which allows a host itself to perform the SSD hardware abstraction or allow the SSD to perform the hardware abstraction as directed by the host. This presentation tells the entire Live Migration story by tying in how the capabilities that exist in NVMe 2.3 work with the newly ratified proposals that completed the story.
Unified Fabric Management & Orchestration: Bridging CXL Fabric Manager APIs
As composable infrastructure scales, operational complexity is becoming a critical barrier for hyperscalers. This session presents a unified approach to fabric management by integrating CXL Fabric Manager (FM) APIs with SNIA Swordfish®, creating a seamless northbound interface for orchestration.
This session will introduce the CXL-to-Swordfish Mapping Specification, which allows Redfish-native orchestration tools to discover, configure, and monitor memory pools as first-class storage/memory resources. In this scenario, CXL defines fabric operations, resource pooling, and multi-level switching, while SNIA Swordfish leverages a Redfish-based model for storage management, including persistent memory. Attendees will gain insight into how this integration reduces operational complexity, enhances interoperability, and accelerates adoption of composable architectures across modern data centers.
Building an MCP Server for High-Performance NAS. Architecture, Health Checks, Multi-Agent Workflows, and Safety Boundaries
Storage systems are starting to sit inside AI-driven operations, and the usual GUI, CLI, and static automation don't cover what that requires. This talk is about an MCP server we built to manage a high-performance NAS: the control-plane integration, the operational workflows, the continuous health checks, and the interaction patterns that keep AI agents from doing something stupid.
I'll go through the server architecture, how management is modeled, and how we actually built it, with the goal of exposing storage capabilities to agents without giving up determinism, observability, or safety. I also want to be honest about the hard parts. Translating storage operations into something an agent can use correctly is harder than it sounds. Keeping stateful workflows from drifting is harder still. Getting end-to-end health checks to mean something, and blocking actions that are unsafe or just ambiguous, took more iterations than I'd like to admit.
The second half is about multi-agent systems talking to storage, why that's interesting, and what it unlocks. I'll walk through scenarios pulled from real situations: agents handling monitoring, diagnosis, and operational work against the NAS through the MCP layer. Then the more uncomfortable ones, where agents try to route around constraints we deliberately put in their way.
Extending DNA Data Storage Standardization with SNIA Swordfish for the Data Center
SNIA Swordfish® has been a Storage Management standard for 10 years, with full support for block and file as well as extended NVM Express® technology capabilities. In January 2026, the Swordfish Technical Working Group released a working draft of a management model and mockups showing a preliminary proposal of the Swordfish API managing and monitoring DNA Data Storage systems.
The SNIA DNA Data Storage Alliance was formed in 2020 with the mission to create and promote an interoperable storage ecosystem based on manufactured DNA as a data storage and compute medium. The group includes biotech and technology companies working together to deliver a low-cost archival data storage solution alternative to current storage technologies.
The approach to extend SNIA Swordfish to manage and monitor DNA Data Storage systems includes:
* Starting with data center primary functionality, mapping to equivalent Swordfish resources, create new resources where needed
* Adding Object stores to Swordfish, plus DNA-specific extensions
Integrating new models to support new archive storage technologies into existing data center management standards (Redfish and Swordfish) provides consistency and simplification for implementers and users.
In this talk, presenters will explain how the Swordfish specification and schema models are being extended to support standardization of DNA Data Storage using an object-storage model, including an update on discussions happening through 2026.