How it works
Jaguar integration
Halo doesn't run against a sandbox. It commands incidents on Jaguar — a real, live product — reached entirely through the MCP Gateway.
What Jaguar is
Jaguar is a real, deployed product (jaguaralpha.xyz) — workers, ingestion, deploys, and all. Halo treats it as the subject of an incident: it reads Jaguar's live state to diagnose what broke, and — only behind a human approval gate — acts on Jaguar to recover it. The point of running against something live rather than a toy is that the failure modes are real: a worker actually falls over, a deploy actually regresses, an upstream credential actually expires.
Reaching it over MCP
Halo never imports a Jaguar SDK or calls its REST API directly. The product is reached only through MCP. Jaguar's MCP server is registered in the TrueFoundry MCP Gateway as a remote endpoint:
https://www.jaguaralpha.xyz/api/mcpAlongside it, Halo's own incident and runbook APIs are turned into tools with OpenAPI-to-MCP (incident-api, runbooks-api). Everything the agent can see or touch is therefore a governed MCP tool behind the gateway — which is what makes the read / write split, guardrails, and tracing enforceable in one place.
The read / write split
The Jaguar tools are split across two virtual MCP servers, so an agent's capability is decided by which server it gets handed — not by trusting the model to behave:
| Virtual server | Boundary | What it grants |
|---|---|---|
jaguar-observe | Read-only | Health, deploys, errors, incident context, status events, runbooks. No way to mutate Jaguar. |
jaguar-act | Approval-gated writes | A tightly scoped set of recovery actions, each held at the approval gate before it runs. |
The servers are curated, not wide-open: the chaos / fault-injection tools Jaguar exposes (failNextCall, delayNextCall, returnBadPayload), deletes, and shell-style tools are excluded from both servers entirely.
Tools Halo uses
The read path is deliberately small and specific:
getHealthSummary— current worker / service health.getRecentDeploys— the deploy timeline to line failures up against.getTopErrors— the loudest current errors.getIncidentContext— incident-scoped state for the run.getRecentStatusEvents— recent status transitions.searchRunbooks/getRunbook— match the symptoms to a known runbook.
Halo gathers this evidence, lines it up against the deploy timeline, and works out the actual root cause before it proposes anything — see Architecture for the full workflow.
The approval bridge
Writes never go straight from the model to Jaguar. The agent drafts a recovery action (for example, a worker restart) and parks it at the approval gate. When an operator approves it in the war room, Halo's backend — not the model — calls the Jaguar MCP endpoint directly to resolve it, as a JSON-RPC tools/call:
approve_actionon approve,reject_actionon reject.- Authenticated with a Bearer API key plus a separate
X-Operator-Secretheader — so executing a real action needs a credential the model never holds. - Bounded by a short timeout, with HTTP / transport errors surfaced as a clean failure rather than a guess.
This bridge is configured with a handful of environment variables on the API:
HALO_JAGUAR_MCP_URL=https://www.jaguaralpha.xyz/api/mcp
HALO_JAGUAR_MCP_API_KEY=...
HALO_JAGUAR_OPERATOR_SECRET=...
HALO_JAGUAR_ACTION_TIMEOUT_SECONDS=20Mode-aware access
Which Jaguar server the agent gets is tied to Halo's operating mode. In Normalit has jaguar-observe plus the approval-gated jaguar-act. When Halo steps down to Degraded or Blackout, it is handed the observe server only — it can keep investigating, but it structurally cannot write to the live product when it's no longer safe to act. See Resilience & modes.