CoreBase

Use case · Virtualization

Ask your Proxmox or VMware cluster in plain English

Your hypervisors expose everything over an API — nodes, VMs, storage, backups, tasks — but answering “which VMs are low on disk?” still means a CLI session or clicking through a console. CoreBase connects an AI assistant to your Proxmox VE or VMware vSphere API so you can just ask. Read-only, on-prem, behind your firewall.

View CoreMCP on GitHub

The problem

Virtualization platforms are API-rich but query-poor for humans. The data to answer “which node is most overcommitted?” or “which backups failed last night?” is all in the API — but pulling it means remembering the right pvesh call or REST path, parsing JSON, and correlating across endpoints. And the API lives inside your datacenter, often air-gapped, where cloud AI tools can't reach it at all.

How CoreBase handles it

CoreMCP runs inside your network and talks to the hypervisor API over its REST source. You expose only the read endpoints you want, so the assistant can answer questions about cluster state without touching your control plane. vSphere's OpenAPI spec turns its read endpoints into typed tools automatically; for Proxmox you point at the API root and pick the endpoints to surface.

coremcp.yaml — VMware vSphere

sources:
  - name: "vsphere"
    type: "rest"
    base_url: "https://vcenter.local/api"
    # vSphere Automation API ships an OpenAPI spec —
    # its read endpoints become typed tools automatically
    spec_url: "https://vcenter.local/api/openapi.json"
    headers:
      vmware-api-session-id: "${VSPHERE_SESSION}"
    timeout: 30

coremcp.yaml — Proxmox VE

sources:
  - name: "proxmox"
    type: "rest"
    base_url: "https://pve.local:8006/api2/json"
    api_key: "${PVE_API_TOKEN}"  # PVEAPIToken=user@pam!id=secret
    headers:
      Accept: "application/json"
    # Proxmox has no standard OpenAPI spec — surface the read
    # endpoints you want (nodes, VM status, storage, tasks) as tools
  • Read-only by design
    You expose only the GET side of the API as tools. The assistant reports on cluster state — it can't start, stop, or reconfigure anything. An exploratory AI stays well clear of your control plane.
  • Reaches the datacenter API
    CoreMCP runs on a box inside your network and dials out on 443 only. A vCenter or Proxmox API with no public endpoint is reachable without opening any inbound ports — air-gap friendly.
  • Correlates across endpoints
    One question can fan out across nodes, VMs, storage, and tasks — the agent calls the tools it needs and stitches the answer together, instead of you parsing JSON from five separate calls.
  • Works from any MCP client
    Self-host the open-source agent and wire it into Claude Desktop, Cursor, or Zed over MCP — or run it through CoreBase Cloud for the panel, audit log, and team access.

What it looks like

Example prompts

  • “Which VMs are using more than 90% of their disk?”
  • “List nodes sorted by memory commitment.”
  • “Did any backup jobs fail in the last 24 hours?”

The agent calls the relevant read endpoints, correlates the results, and answers in one reply — no CLI, no JSON spelunking, nothing changed on the cluster.

Why this approach

vs. a monitoring dashboard
Dashboards show what you pre-built a panel for. An assistant answers the ad-hoc question you didn't anticipate — across endpoints — without you building a new view first.
vs. a cloud AI tool
Cloud AI can't reach an API inside your datacenter, let alone an air-gapped one. CoreMCP runs in your network and connects outbound only — no inbound exposure of your hypervisor.
vs. scripting it yourself
API auth, endpoint discovery, JSON correlation, and a natural-language layer add up. CoreBase is one config file, and the read surface is yours to scope.

Related

Frequently asked

Can the assistant start, stop, or change VMs?

No — by default it reads. You expose only the read endpoints (the GET side of the API) as tools, so the assistant answers questions about cluster state without the ability to act on it. That keeps an exploratory AI well clear of your control plane.

How does it connect to Proxmox VE?

Through CoreMCP's REST source, pointed at the Proxmox API root (e.g. https://pve.local:8006/api2/json) with an API token. Proxmox doesn't publish a standard OpenAPI spec, so you define the specific read endpoints you care about — nodes, VM status, storage, tasks — as tools the assistant can call.

How does it connect to VMware vSphere?

vSphere ships an OpenAPI spec for its Automation REST API, so you point spec_url at it and the read endpoints become typed tools automatically. Authentication uses a session token passed in the headers.

Does this work for an on-prem or air-gapped datacenter?

Yes — this is the point. The CoreMCP agent runs inside your network and connects outbound only (443), so a hypervisor API that has no public endpoint is still reachable without opening inbound ports. In air-gap mode nothing leaves your perimeter at all.

Is this useful for a homelab too?

Absolutely. The open-source CoreMCP agent runs anywhere — point it at your homelab Proxmox node, wire it into Claude Desktop or Cursor over MCP, and ask about your cluster in plain English. No CoreBase Cloud account required for the self-hosted path.

Point it at your cluster

Self-host the open-source agent for your homelab, or book a demo to wire it into your datacenter with audit and team access.

View CoreMCP on GitHub