Capabilities

The contract model

Every capability in Oxagen is declared once in the platform contract registry. A contract declaration specifies:

• A stable id (e.g., agent.code.execute)
• Input and output schemas (Zod)
• The surfaces it is exposed on: api, mcp, and/or agent
• Risk level and approval requirements (for agent-surface capabilities)
• Default roles and effects (for IAM)

The contract registry is the single source of truth. Every API route and every MCP tool is generated from it. This means: if a capability exists, it is available on every surface it declares. Parity is structural, not maintained by hand.

Capability parity is verified automatically at build time; any gap is reported as a warning.

Capability naming and aliases

Every capability's canonical name follows one standard, domain.subject.action (ADR-022):

• domain — the top-level area (agent, graph, billing, org, …). One domain per area, no synonyms.
• subject — the entity the action operates on, singular (connection, never connections), with a multi-word concept written as a single snake_case segment (file_lock, never a fourth dotted segment).
• action — a verb from a closed vocabulary (list, get, create, update, delete, acquire, release, …).

A two-segment domain.action name is legal when the action implies the domain's root entity (connection.list = "list connections") or reads as an implied get (workflow.status = "get the workflow's status").

The model-facing tool name a coding agent sees is the same canonical string with dots replaced by underscores (agent.file_lock.acquire → agent_file_lock_acquire), except for the engine's primitive tools (read_file, bash, code_graph, …), which predate this standard and keep their established names.

Renaming never breaks an existing integration. When a capability is renamed to conform to the standard, the old name becomes a permanent alias: the registry resolves it to the canonical capability, the kernel meters and audits the call under the canonical name, and IAM matches grants keyed by either name. REST paths and MCP tool names for a capability you already integrate against do not change on a rename — only the contract's internal identity moves. For example, agent.file.lock.acquire (pre-standard) still resolves; its canonical name is now agent.file_lock.acquire.

Capability list

The following capabilities are available in the current release, grouped by domain.

Agent

Chat and conversations

Knowledge and assets

Content generation

Organization and workspace

Billing

Notifications

User preferences

API keys

Plugins

System

REST route convention

All capabilities map to REST routes under /v1/{orgSlug}/{workspaceSlug}/ using the following convention:

• Capability domain becomes the path prefix: agent.code.execute → /v1/{orgSlug}/{workspaceSlug}/agent/code/execute
• The HTTP method reflects the operation: reads use GET, mutations use POST
• List operations append /list or use a bare GET on the collection path
• The org and workspace slug path segments are mandatory on every capability route. The slugs are those associated with your API key.

The pnpm check:manifest --json script reports the full capability parity table at development time. There is no runtime /v1/capabilities endpoint.

Parity caveat

The following UI-only flows do not have corresponding contract declarations and are therefore not reachable via API or MCP:

• In-stream plan approval (requires the chat UI stream; use agent.plan.approve after the fact)
• Stripe Customer Portal redirect (UI-only billing management; billing.subscription.upgrade.start handles upgrades programmatically)
• OAuth plugin credential flows (browser redirect required)

This list is kept current automatically. As contracts are added for these flows, they will appear in the capability list above.