Most agent integrations give a model a thin wrapper around a CLI and hope for the best. Unimatrix0 exposes the cluster through the open Model Context Protocol — tools, resources and prompts — with the same permissions, approvals and audit trail as a human at the console.
Shelling out to a hypervisor API gives an agent the full privilege of a root operator with none of the structure: no declared schemas, no capability scoping, no approval gates, no record of what was actually executed.
| Property | Shell wrapper | Proprietary API plugin | Unimatrix0 MCP fabric |
|---|---|---|---|
| Client compatibility | One bespoke client | Vendor's runtime only | Any MCP client, today |
| Input validation | Whatever the shell accepts | Vendor-specific | Schema-validated at the boundary |
| Permission scoping | All or nothing | Token-scoped | Per-tool, per-role |
| Human approval gate | Absent | Varies | Required on destructive operations |
| Audit trail | Shell history at best | Vendor logs | Caller, tool, arguments, surface, result |
| Live state access | Poll and parse | Vendor API calls | Addressable, subscribable resources |
| On-premises model assist | No | No | Sampling capability, local inference |
| Lock-in | Total | High | None — open protocol |
Clients connect over the standard HTTP transport to any node. Inside the cluster, calls travel over the message bus. Nothing depends on a session living on a specific host, which is what makes it survive node loss.
MCP CLIENT / HOST Claude Desktop · Cursor · LangChain · your own agent · operator laptop │ MCP over standard HTTP ▼ ┌───────────────────────────────────────────────────────────────────────┐ │ NODE ENDPOINT (present on every node, no exceptions) │ │ │ │ catalogue ← built locally from this node's registry │ │ authentication · role filtering · approval policy │ │ schema validation · audit │ └───────────────────────────────────────────────────────────────────────┘ │ host-local operations │ appliance operations ▼ ▼ ┌─ CORE ─┐ ┌─ EXTENSIONS ─┐ │ VMs · nodes · HA · stora │ │ backup · network · AI │ │ networks · tasks · logs │ │ storage · gateway · prox │ │ │ │ │ │ runs in the hypervisor │ │ runs in isolated applian │ └──────────────────────────┘ └──────────────────────────┘ No leader. No replication of state. No session affinity. Any node can serve any request — that is the stateless design paying off.
MCP distinguishes things you do, things you read, and reusable procedures. Unimatrix0 maps each to something concrete rather than inventing a private vocabulary.
Every operation the cluster supports, declared with a schema and safety annotations.
unimatrix_create_vm name, vcpus, memory, disks, networks, image, target unimatrix_drain_node node, mode: live|cold ai_assign_workload model, replicas, placement, queue backup_snapshot target, scope
Live cluster state as stable URIs. An agent reads the hypervisor directly instead of inferring reality from logs.
xen://node/domains live domains + state sanlock://leases who owns which disk xen://node/logs hypervisor events gpu://inventory cards, VRAM, temp task://id progress, subscribable
Operating knowledge packaged as prompts, so the good runbook is available to every agent that asks — not just the engineer who wrote it.
debug-node-failure binds logs + lease state into a root-cause context optimize-placement RAM, VRAM, thermal → rebalance plan backup_restore_plan point-in-time restore for a given VM
Appliances declare their operations, resources, prompts and events in a manifest. The platform generates everything else. Your engineers write the handler — not four integrations.
// a manifest entry, once operation: name: drain_node input: schema/drain.in.json output: schema/task.json safety: read_only: false destructive: false idempotent: true long_running: true surfaces: [rest, mcp, cli, ui] // generated from that declaration — // no second file to keep in sync REST POST /api/v1/node/drain MCP tools/call drain_node CLI borg node drain <node> UI drain control on the node panel
Sign the work you did not write. Appliance manifests and console bundles are signed. The platform ships with the vendor release key and will load an unsigned or incompatible appliance only if an administrator explicitly trusts its key.
The safety model is not bolted on for agents. It is the same model that governs the web console and the command line — agents simply arrive through a different door.
| Operation class | Behaviour |
|---|---|
| Read-only | Runs immediately if the token's role permits it |
| Non-destructive write | Runs if permitted; the token can be constrained to read-only entirely |
| Destructive / flagged | Creates a pending approval. A human accepts. The agent is told to wait |
| Out of scope | Not listed at all — the client cannot discover what it may not do |
Point a desktop assistant at a node endpoint and ask operational questions in plain language: what is hot, why did this restart, drain that rack.
Standard protocol support in the major orchestration and agent frameworks. No custom SDK, no bespoke connector.
A built-in assistant command sends your request to a model and executes the resulting tool calls — subject to exactly the same approvals as any other caller.
Exposure boundary. By default the endpoint listens on the management network only. An optional hardened gateway appliance handles TLS termination, rate limiting and tenant policy if you need to expose the fabric beyond it. Where a client supports it, the approval gate surfaces directly in the client's own interface.
We will walk your team through the tool list, the resource URIs, the permission model and the approval workflow on a live cluster — with the engineers who wrote them.