What MCP access to vCenter actually provides
An administrator can request a readable inventory, compare VMs, or prepare migration questions without manually copying every screen. The model asks; the MCP server calls an authorized API; the model summarizes the result. Summary quality depends on returned data and scope.
Start with a bounded goal: understand lab VMs. Keep operational changes within the established change procedure. Examples use fictional names and require no guest credentials.
1. Select a specific server implementation
MCP is a protocol, not a universal VMware API. A Workstation server need not support vCenter or ESXi. Review the primary repository, ownership, dependencies, license, tests, and tools before installing.
This guide uses community project michaelrice/vcenter-mcp as a case study. Its manifest declares Python ≥3.10, version 0.1.0, Apache-2.0, and mcp/pyVmomi dependencies. Those facts are neither Broadcom certification nor a compatibility matrix. Record your vCenter/ESXi build, Python and client versions, and server SHA.
The repository does not establish universal vSphere compatibility. Validate the target with the platform owner and retain required platform licenses and API rights. AI subscription and data-processing terms are separate considerations.
2. Define the read boundary
The project documents list_vms alongside create_vm, power_on_vm, power_off_vm, and delete_vm. Inventory supports a read pilot; the complete server is write-capable.
Use two controls. A reviewed variant or trusted gateway must expose and accept only the selected tool. The vSphere identity must independently reject writes. Hiding a tool in the interface while leaving it callable is insufficient.
Do not assume a READ_ONLY setting exists. Implement and test a versioned change or choose another implementation if necessary. Verify both tools/list discovery and tools/call enforcement.
| Layer | Recommended control | Evidence |
|---|---|---|
| MCP server | Allow only list_vms | Discovery and direct calls filtered |
| vSphere | Dedicated read identity | Effective privileges exclude writes |
| AI client | Bound session tools and permissions | No unnecessary shell or connector |
| Network | Management host → authorized target | Bound destination and flow |
3. Create a limited vSphere identity
Create a dedicated identity such as svc-ai-inventory through an approved provider. Assign Read-only at the smallest scope that supports the collection, checking required parents and propagation. A datacenter query filter is not authorization.
Broadcom separates privileges, roles, and per-object permissions. Review direct, inherited, and group assignments; other memberships may broaden rights. Supply neither global Administrator, ESXi root, nor guest passwords.
Positively test pilot visibility and negatively test out-of-scope objects. Have an authorized administrator examine effective privileges. Any denied-write tests belong in a disposable lab; do not attempt production deletion merely to demonstrate denial.
4. Prepare a reproducible management host
Use a protected workstation or dedicated VM reaching vCenter by its DNS name over HTTPS. Run the process without local administrative rights where possible. Bound filesystem access, network destinations, and other agent tools.
The commands below install dependencies and change the host; they are not read-only collection. Replace the fictional SHA before running. Retain an approved dependency lock; pip freeze records packages but does not audit vulnerabilities.
Before client registration, implement and test tool restrictions and TLS verification described below. Successful installation is not production approval.
# CHANGE: isolated lab installation after source review.
git clone https://github.com/michaelrice/vcenter-mcp.git /opt/lab/vcenter-mcp
cd /opt/lab/vcenter-mcp
# Pin the reviewed source; replace the placeholder with a full approved SHA.
git switch --detach <APPROVED_COMMIT_SHA>
python3 -m venv .venv
.venv/bin/python -m pip install -e .
.venv/bin/python -m pip freeze
# Configure only the dedicated read-only identity:
.venv/bin/python -m vcenter_mcp setup5. Protect TLS and secrets before collecting inventory
The README reports an unverified SSL context by default and a configuration file containing a password. Adapt both before enterprise use. An internal network does not establish server identity.
Verify the target certificate and hostname through the SDK. This Python fragment illustrates the required context and must be integrated into the real connection call in the reviewed build. Untrusted CA and wrong-hostname tests must fail before authentication.
The CA file contains public trust certificates, not a private key. Use an approved secret mechanism or tightly protect the required configuration file. Do not expose that file, secret variables, or authentication traces to the agent’s file-reading tools.
- Keep passwords out of command arguments, repositories, and prompts.
- Restrict process identity and configuration-file permissions.
- Plan rotation, revocation, and existing-session handling.
- Retain logs without secrets under a defined policy.
# Design example: integrate into the reviewed connection helper.
# Does NOT patch the project automatically.
import ssl
context = ssl.create_default_context(
cafile="/etc/company-pki/vcenter-trust.pem"
)
# Pass this context to the actual SDK connection.
# Keep hostname verification enabled and connect with the certificate DNS name.6. Connect a local client using the correct transport
This example uses Claude Code and local stdio. The client launches Python using an absolute path; that process connects to vCenter. No public MCP listener is required.
Anthropic documents stdio and configuration scopes. Select local scope for the pilot. Registration does not automatically restrict SDK rights; validate the previous controls first.
A cloud client cannot simply launch Python on your local network. Remote use needs an implementation supporting its transport, authentication, HTTPS, and access rules. This guide does not turn the project into an HTTP/OAuth connector or promise identical setup across clients.
# CHANGE: register only the hardened, reviewed lab build.
claude mcp add --transport stdio --scope local vcenter-lab -- \
/opt/lab/vcenter-mcp/.venv/bin/python -m vcenter_mcp
# Read local connector status:
claude mcp list
claude mcp get vcenter-lab7. Validate tools, data, and errors first
Discover tools in the client and compare names and schemas with the approved build. Reject unexplained changes after upgrades. MCP specifies tools/list and tools/call; safety annotations are not authorization evidence.
Compare a small inventory with vSphere Client under the same scope. Empty output may mean missing visibility, a wrong target, or a failure; do not automatically translate it into no VMs. Preserve errors.
This case study supports VM inventory. Do not request performance history, backup status, or snapshots unless the tool provides them. Missing IP or guest data needs source validation before conclusions.
8. Three practical pilot prompts
These prompts structure a report, not security, capacity, or compliance evidence. Review results with the responsible administrator. Bound response size and request frequency to protect vCenter and model context capacity.
- “Using authorized inventory from lab-vcenter, create a table of visible VMs and their state. Include target, scope, collection time, and missing fields.”
- “Compare APP-LAB-01 and APP-LAB-02 using returned values only. Separate observed differences from hypotheses. Execute no changes.”
- “Prepare migration validation questions from this inventory. Identify additional evidence needed for each; do not infer application compatibility from VM names.”
9. Treat inventory as untrusted input
VM names, annotations, and returned text may contain malicious instructions. Treat them as data, never authorization to execute a command, read a secret, or invoke another connector.
A read-only prompt helps behavior; permissions, filtering, and isolation enforce the boundary. Do not give this session messaging connectors, privileged shell access, or guest credentials without a precise need.
Read access can reveal topology, names, and addresses. Decide which fields may leave the environment, which models are approved, and what retention applies. A local MCP server does not imply a local model; client-provider infrastructure may receive tool results.
10. Pilot, logging, and rollback
Record owner, objective, build, SHA, identity, and visible objects. Measure load, errors, and report accuracy. Log tool, target, status, duration, and client user without secrets.
In a lab, verify successful reads, rejected unauthorized tools, failed invalid certificates, and inaccessible out-of-scope objects. Test misleading instructions embedded in data and confirm no additional action executes.
Rollback removes client MCP configuration, stops the process, and revokes identity or permissions according to plan. Check platform sessions close; do not assume password rotation alone terminates them. Restore only reviewed files and dependencies.
Infrastructure and AI integration consulting can prepare this pilot, validate controls, and assess useful team workflows. This remains separate from a full vSphere assessment or operational change-automation project.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →