Infrastructure teams spend a disproportionate amount of time on operations that are well-defined but tedious to execute by hand: scanning HBAs, provisioning storage, configuring FC zoning, standing up datastores. The goal was to validate natural-language orchestration workflows.
The problem isn’t capability, it’s interface with simplicity and automation in mind. Engineers shouldn’t need to context-switch between five tools and three runbooks to get a routine task done.
This proof-of-concept demonstrated the feasibility of combining MCP, LLMs, VMware APIs, and Hitachi Ansible modules to simplify operational workflows. Further evaluation would be required before considering production use cases.
At its core, the assistant is built on a simple stack: FastAPI for the application layer, Ollama for local LLM inference, and a pair of Model Context Protocol (MCP) servers that give it safe, structured access to real infrastructure In this case, the VMware vSphere and Hitachi VSP One environment.
The separation between the two MCP servers is deliberate and reflects the different operational domains they serve and how they can work together to solve operational and business needs.
vSphere MCP Server acts as the virtualization operations layer. It provides visibility into the VMware environment through inventory discovery, host and cluster status checks, VM inspection, datastore visibility, and configuration queries. It also supports vSphere-native administrative actions such as powering virtual machines on or off, managing snapshots, and creating datastores from storage that has already been provisioned and presented to the ESXi hosts. Its responsibility begins and ends within the VMware ecosystem, making it the primary interface for day-to-day virtualization management.
Ansible MCP Server acts as the infrastructure orchestration layer. It is responsible for workflows that extend beyond vSphere and require coordination across storage, SAN, and virtualization platforms. This includes HBA rescans, Hitachi VSP One storage provisioning, Brocade Fibre Channel switch zoning, storage presentation to hosts, and end-to-end datastore deployment from newly allocated storage. While some outcomes may overlap with vSphere operations—for example, a datastore ultimately appearing in vSphere, the Ansible MCP Server is responsible for the underlying infrastructure changes that make those operations possible.
In practical terms, the vSphere MCP Server is responsible for operations within the VMware ecosystem, providing visibility and control over existing virtual infrastructure. The Ansible MCP Server is responsible for orchestrating the underlying storage and SAN infrastructure, automating the provisioning and configuration workflows that extend beyond VMware itself.
The automation underneath
The assistant doesn't generate infrastructure workflows dynamically. Instead, it orchestrates an Ansible automation framework (hv-playbooks-HIS-VMware) built and tested against VMware Cloud Foundation 9 and Hitachi VSP One Block environments as part of this proof-of-concept.
Independent testing of this automation framework demonstrated approximately 79% reduction in deployment time across a 23-task workflow.
The MCP layer adds a conversational interface that makes these automation capabilities accessible through natural language rather than manual execution. As showcased in the interaction between each of these components in the diagram below.
How the MCP architecture fits together
Governance and Auditability
Because all infrastructure changes are executed through Ansible:
Several architectural decisions were made to minimize operational risk:
- The LLM never communicates directly with infrastructure endpoints.
This project focuses on reducing friction in infrastructure operations rather than introducing autonomous infrastructure management.
The platform enables engineers to perform common VMware Cloud Foundation and Hitachi VSP One operational tasks more efficiently while maintaining existing governance, security, and operational controls.
Disclaimer: This project is an internal proof-of-concept and technology validation exercise developed to explore the integration of Model Context Protocol (MCP), VMware automation, Hitachi Ansible modules, and conversational AI capabilities. It is not an official Hitachi Vantara product, service, or supported offering.
For more information, and reference, use the following links to download the components used in this test environment:
vSphere MCP Servers (reference implementations)
Ansible / Automation MCP Servers