Capabilities and Command Lifecycle
How Noxgild's 70 curated capabilities sit behind its compact AI-facing orchestration layer.
Noxgild separates what a computer can do from how an AI client orchestrates that work.
Capability catalog
The internal catalog is fixed at 70 capabilities:
| Layer | Count | Examples |
|---|---|---|
| Machine | 28 | files, directories, shell, managed processes, system state |
| Browser | 21 | navigation, snapshot, forms, screenshots, network inspection |
Desktop (desktop.*) | 21 | native UI, windows, apps, clipboard, displays, file dialogs |
Every capability owns a complete execution contract including schema, risk, idempotency, retry behavior, timeout, verification, and worker.
AI-facing orchestration
The public MCP interface intentionally exposes a small set of orchestration tools that can:
- list authorized computers,
- discover the capability catalog,
- execute or submit a capability,
- approve one exact command,
- read or wait for command state,
- cancel eligible work,
- and perform Noxgild's Wake-on-LAN orchestration.
This is by design. The 70 capabilities are not supposed to appear as 70 separate top-level MCP tools.
Command lifecycle
Noxgild stores durable command state. Work moves through explicit states instead of relying on an unverified client-side guess.
Terminal outcomes include success, failure, cancellation, and UNKNOWN when the system cannot safely prove the final side-effect state.
Retry behavior
Safe reads can be retried differently from operations whose side effects require verification or must never be automatically retried.
The capability catalog is the authority for those rules.