agents
For agents and operators
omni is built on a shared stack of small Rust libraries, so the same binary is also an MCP server, reports its own failures to an issue board, and updates itself from tagged releases.
MCP server
omni mcp stdio serves the Model Context Protocol over standard input and output; omni mcp tools prints the same tool list as JSON without starting a server. Agents can do more than read status: send types into a device and devices shows which devices are connected.
| Tool | Arguments | Does |
|---|---|---|
send | text, key, combo, scroll, relay, device, token | Casts one command. Through a relay it reports delivery, where 0 means the device is not connected; otherwise it returns the wire line |
devices | relay, token | Lists device ids connected to a relay hub |
status | Name, version, update repository and capabilities | |
config | The resolved targets and transports | |
doctor | probe | Read-only health checks, optionally with reachability probes |
self_update_status, _check, _run | Self-update state, a check for a newer release, and an update | |
feedback_report | kind, summary, detail, severity, labels, … | Reports a structured event through the configured route |
feedback_status | The resolved feedback route, without secrets |
{ "mcpServers": { "omni": { "command": "omni", "args": ["mcp", "stdio"] } } } The CLI stack
| Library | Gives omni |
|---|---|
| mcp-cli | A typed command surface that is also the MCP tool list, and JSON envelopes for --json |
| updatable-cli | omni update and the staged-update promotion at start-up |
| feedback-cli | Structured error, performance and feedback events, sent to standard error or a webhook |
The same stack and conventions are shared with the owner's other command-line tools, so their flags, envelopes and update behaviour look alike.
Feedback to issues
Failures, performance observations and explicit feedback are emitted as events. By default they go to standard error. Pointed at a webhook, each becomes a JSON object posted to it; a receiving service, such as an agent orchestrator's bead hook, decides what happens next (here: open an issue on the omni-cli board).
{"kind":"error","component":"omni","summary":"…","detail":"…"} | Variable | Effect |
|---|---|
FEEDBACK_WEBHOOK_BASE_URL | A shared hook namespace; omni posts to base/omni-cli, so each tool reports to its own path |
FEEDBACK_WEBHOOK_URL | An explicit full URL, which wins over the base URL |
FEEDBACK_WEBHOOK_TOKEN_ENV | The name of the variable that holds the bearer token |
FEEDBACK_COMPONENT, FEEDBACK_PROJECT | Override the defaults omni and omni-cli; the project is also the path appended to the base URL |
With neither URL set, events go to standard error. The token itself is never a flag or a file in the repository; only the name of the variable that holds it is configured.
Self-update
omni update checks the repository's tagged releases and stages a newer binary as omni_next. On the next start, omni promotes the staged binary atomically and runs it before doing anything else. Under Nix the service modules prefer a self-updated ~/.local/bin/omni when one exists (preferLocalBinary), so updates do not wait for a system rebuild.
omni statusomni v0.3.0update repo: harryaskham/omni-clifeedback: true (stderr)