Capability registry
Every governed action in Oxagen is a typed capability contract: declared once, enforced on every surface, and listed in the governance catalog.
A capability is the unit of action in Oxagen. The in-process registry declares each one once as a typed contract, and Oxagen exposes it the same way on every surface it opts into: the REST API, the MCP server, the in-app agent, and the CLI. Calls to these capabilities run through the invoke() kernel, which applies IAM, metering, and audit.
What a contract declares
| Field | Meaning |
|---|---|
| Name | Verb-first snake_case identifier, for example query_audit_log. See Capability naming. |
| Domain | Functional grouping (billing, graph, agent, …) |
| Surfaces | Where it is mounted: api, mcp, agent, cli |
| Sensitivity | Data sensitivity classification. Approval behavior is declared separately in agent metadata and IAM grants. |
| IAM grants | Default role grants, each with one effect: allow, deny, or require_approval |
| Entitlement gate | Which plan or entitlement pack unlocks it |
| Input/output specs | Typed field schemas, validated on every call |
| Layers | Declared coverage: schema, api, mcp, unit, e2e, docs, app |
Browsing the catalog
Read the generated Architecture atlas for the contract catalog. Organization → Roles shows roles and the permissions they carry, not a complete route and schema browser.
An MCP client can request tools/list for the tool names and input schemas its server exposes.
Per-capability reference
The source contracts in packages/oxagen/src/contracts/ define surfaces, inputs, and outputs. The repository's docs/capabilities/ pages explain individual capabilities. Check the contract when a hand-maintained page disagrees with it.