XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. axeldunkel
    3. Posts
    A Offline
    • Profile
    • Following 0
    • Followers 0
    • Topics 1
    • Posts 1
    • Groups 0

    Posts

    Recent Best Controversial
    • 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.

      posted in REST API xoa mcp
      A
      axeldunkel