XO 6.7 REST API - full coverage for MCP agents, updated same day (267 tools, open source)

axeldunkel

Congrats on the 6.7 release! The REST API expansion is the part we care about most, so here's a small show-and-tell from a long-time XCP-ng/XO shop.

We maintain an open-source, declarative description of the entire XO REST API (a "DADL" - one YAML file) that turns it into an MCP server for AI agents - Claude, GPT, whatever speaks MCP. Our gateway (ToolMesh, Apache 2.0) serves it at runtime; there is no per-endpoint code and no separate server process to maintain. When 6.7 landed today, updating meant editing the description, not rebuilding a server: an LLM drafted the diff from the 6.7 changelog and API reference, we reviewed and tested it, and the refreshed version went live the same day. That workflow is rather the point of a declarative format - compact enough for a model to maintain, readable enough for a human to verify every line of the diff.

Current state, if you want the numbers:

267 tools, covering the full REST surface for XO 6.4 through 6.7
6.7 additions are in: the new host lifecycle actions, reboot-persistent maintenance mode (autoEnable), create_sr, the VDI PATCH endpoint, backup repository health check + throughput benchmark, and traffic-rule updates (SDN controller plugin)
Version floors are explicit: tools that need 6.7 say so in their description and return a clean 404 hint on 6.6.x
Honest gaps: backup RESTORE is not exposed over REST (that stays GUI/JSON-RPC), and the deprecated routes scheduled for removal in Sep/Oct are intentionally excluded
What started as ~60 endpoints in May is now the full surface - maintaining a description scales very differently from maintaining wrapper code

To be clear about positioning: XO's built-in MCP server is the right quick start - this is the complement for when an agent needs the full API surface with authorization, audit logging and fail-closed checks in front of it (the gateway holds the token; the model never sees it). Your Insights piece this month about the Hugging Face incident makes that case better than we ever could - the boundaries that held were the ones drawn in advance.

Everything is open: https://www.dadl.ai/d/xen-orchestra/ (endpoint matrix, setup, raw YAML, GitHub link). If you run agents against your XO and something is missing or wrong, tell me here - real-world corrections are the fastest way this improves.

poddingue

Congrats on getting this out so fast after 6.7, and thanks for the writeup, genuinely interesting approach. The declarative angle instead of wrapper code per endpoint makes sense to me, especially given how often the REST surface grows.

One thing I keep wondering about: you framed the auth/audit/fail-closed checks as sitting in front of the gateway. What happens when the model actually asks for something destructive, a VDI delete, a host disable, that kind of thing? Does the gateway block it outright, or does a human need to sign off somewhere in there?

I'm asking because that's close to the exact boundary question our own Insights piece touched on this month. I'm community manager here, not a developer, so I'd rather ask than guess at how the security model actually behaves. Want to understand it properly before I say more.

Passing this along internally too. No promises on timing, but it's the kind of thing worth a closer look.

axeldunkel

@poddingue
Thanks - great question, and the answer is simpler than you might expect.

Every tool in the catalog is classified right in its description: read, write, admin, dangerous. That classification ships with the DADL itself - nobody has to sort 267 endpoints by hand before letting an agent near them.

From there it is a ladder:

Each agent (or user) gets a maximum access level. Our reviewing agent is capped at "read" - so a VDI delete is not blocked with a warning, it is simply not on the table. And this holds even though the gateway itself holds an admin token towards XO: the agent's reach ends at the classification, not at the token. The model cannot talk its way past a label.
Exceptions are a one-line override: "read-only, but snapshot_vm is allowed" - or the other direction, "writes allowed, but nothing classified dangerous".
For the fine-grained cases - "read-only, except never touch this one VM" for example - there are policies that can filter on parameters, not just functions.

Underneath it all, one rule: fail-closed. If any check cannot complete, the call does not run.

The detail we find most underrated: refused attempts are logged as first-class events. A reviewing agent that suddenly asks for a delete is not a near-miss - it is a signal, because it usually means the model read something it should not have trusted. Which is your Insights piece's "boundaries drawn in advance", applied literally.

Happy to go deeper on any of this - the boundary question is exactly what the gateway exists for.

poddingue

That is clearer than I expected, thank you.
The part that lands for me is that the cap sits on the agent rather than on the token, so a delete is not refused after the fact, it simply never appears in the catalogue the model can see.
I had assumed most of the work would live in a policy engine, and it sounds like the bulk of it is classifying the 267 tools once and shipping that classification with the description itself.
Treating a refused call as a signal rather than a near miss is the bit I want to borrow if/when we talk about this, because it turns the log from an audit trail into something closer to a smoke alarm.
I am not deep enough in MCP to have a useful opinion on where this model breaks, so I will read the endpoint matrix properly before asking anything else.
Passing it on internally as promised.

axeldunkel

@poddingue
Borrow away - "smoke alarm" is a better name for it than anything we had, so we might borrow it right back.

Since you mentioned reading the matrix - here is the classification you would be reading, straight from the file:

grep access: dadl/xen-orchestra.dadl | sort | uniq -c
     49       access: admin
     21       access: dangerous
    122       access: read
     75       access: write

122 of the 267 tools are plain read - that is the entire surface a review-capped agent gets. The other 145 exist in the same file, but for that agent they might as well not. The whole security taxonomy is greppable plaintext - which is rather the point of a declarative format.

And if anything in the matrix looks wrong or missing, this thread is exactly the right place - real-world corrections are how it improves.