Skip to main content
@error-bar/mcp exposes the management API as MCP tools, so an agent can read your evals, pull failure clusters, compare two models, or repoint an alias without you writing a single HTTP call. One tool per API operation — 76 of them — generated from the platform’s route contracts, so the tool surface cannot drift from the API it wraps. Inputs are validated with the same field names and casing the REST API accepts, and responses come back exactly as the API returned them (JSON pretty-printed, exports as text), including the API’s own error status and message. An agent that has read the API reference already knows how to drive this. This is the management surface. To send inference through errorbar, point your OpenAI client at the gateway instead; to capture traffic you’re running elsewhere, see the integration paths.

Connect

The server talks to https://gateway.errorbar.ai by default; --base-url URL or ERRORBAR_BASE_URL points it elsewhere. Every environment variable also accepts its previous OMNIA_* spelling.
The package was renamed from @omnia-voice/mcp on 2026-08-30. The old name is still published as a shim that forwards here, so existing configs keep working — update yours when convenient.

What the key can do

The server does no permission logic of its own: it sends your key and reports what the platform says. So the key is the sandbox, and the useful move is minting one that can’t do more than the agent should. A key acts as the user who minted it, and the money-spending and traffic-redirecting operations require that user to be a workspace owner or admin — see key permissions and roles. A key minted by a regular member is therefore a safe read-and-infer credential for an agent, and it fails closed with 403 rather than silently doing less than you asked. Each tool’s description names the permission it needs. Across the 76:

Keeping an agent inside the lines

Eleven tools start billable work. They say SPENDS MONEY in their description and are deliberately not marked readOnlyHint, so any MCP client that confirms before non-read-only calls will stop and ask: create_eval · create_batch · suggest_criteria · run_criterion_alignment · auto_improve_criterion · scan_criterion_suspects · create_dedicated_endpoint · update_dedicated_endpoint · create_fine_tuning_job · start_fine_tuning_bakeoff · start_grpo_run Client-side confirmation is a prompt, though, and prompts get click-through. For a guarantee, don’t expose the tools at all:
Pair the two layers. --read-only on a member-minted key means neither the tool list nor the credential can spend, so a prompt-injected agent has nothing to escalate into. Reach for --no-spend when the agent genuinely needs to write — curating datasets, editing criteria — but should never start a run.

Programmatic use

The server is a library too, so you can embed it in your own agent with the guards already applied:

Tool inventory

Each tool’s description carries the full contract: every query and body field, what the response contains, and the gotchas (feature flags, 400 conditions, cursor semantics). The complete 76-row table, tool by tool with its route and permission, is in the repository README. The manifest is generated from the platform’s route inventory and pinned by a test, so a new API route fails the suite until the manifest covers it. What the API can do, the MCP server can do.