XO 6.7 REST API - full coverage for MCP agents, updated same day (267 tools, open source)
-
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.
-
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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login