LLM agents that can reason about your deployments.
Xolver exposes an MCP server. Any compatible LLM agent can analyze trajectory failures, synthesize reward configurations, and propose curriculum edits — without touching the runtime contract.
Known limitations today
- Snapshot-based, not live. The MCP server reads a resolved deployment snapshot. New evidence requires regenerating the snapshot — there is no streaming connection yet.
- stdio only. The supported transport today is stdio. Other MCP transports are not wired up yet.
- One snapshot per server. Each MCP server instance maps to a single resolved deployment, not a fleet.
What this is
Modern AI agents — Claude, GPT-4o, and others that support the Model Context Protocol — can be connected to Xolver as a reasoning layer above the safety boundary. The agent sees evidence, proposes changes, and explains what went wrong. It does not actuate.
This is the correct architecture. An LLM is the right tool for reasoning about what a robot did and what it should do differently. It is not the right tool for deciding what happens next in a 250Hz control loop. Xolver keeps those concerns separate.
What MCP tools are exposed
analyze_trajectory_failure
Receives a trajectory from the evidence record and returns a structured causal analysis. Why did the motion stop? What constraint was violated? Was the failure a model issue, a scene state issue, or a hardware timing issue?
synthesize_reward_config
Given a failure analysis, proposes a reward configuration update for fine-tuning. The proposal is structured, grounded in the evidence, and returned as a reviewable object. It does not modify anything.
propose_curriculum_edit
Suggests changes to the training scene or task curriculum based on the current failure pattern. Proposals only.
propose_layout_resolution
Runs layout optimization on the current scene geometry and returns a proposed resolution. Does not mutate the scene or the runtime contract.
resolve_reward_deployment_input
Converts an approved reward configuration into a deployment input, ready for the training pipeline.
The proposal boundary
Every tool returns a structured proposal object — never a direct action. Proposals carry a type, a summary, evidence references, and a payload. They cannot mutate runtime contracts. They cannot execute hardware commands. The agent proposes. A human approves. The system acts.
No proposal can mutate a runtime contract. Ever.
This guarantee is enforced in the orchestration boundary itself — the layer between the agent and everything downstream — not left to convention or developer discipline.
How to connect
xolver mcp --deployment-snapshot ./snapshots/cell-001.json
This starts the MCP server over stdio. Connect any MCP-compatible client — Claude Desktop, a custom agent, or your own tooling.
The server requires a resolved deployment snapshot. The snapshot defines which evidence is available and which tools are enabled.
What this is not
The MCP server is not a command interface for the robot. It is a reasoning interface for understanding deployments and proposing improvements. The robot's runtime contract, safety shield, and hardware adapters are outside its authority by design.
The agent can
- Analyze failure trajectories
- Propose reward configuration changes
- Suggest curriculum edits
- Explain what went wrong and why
- Propose layout resolutions
The agent cannot
- Mutate the runtime contract
- Send commands to hardware
- Override the safety shield
- Approve its own proposals
- Trigger actuation of any kind
Read the MCP specification
Contact us for the full MCP tool schema, proposal type reference, and integration guide. We support Claude Desktop, custom agent frameworks, and any client that speaks the Model Context Protocol over stdio.
hello@xolver.aiRelated