Every capability in Opbox is a verb, and every verb lives in one registry. The kernel is a single Rust binary that is both the opbox CLI and the HTTP/MCP server, and all three doors - chat, command line, and the agent’s MCP transport - dispatch through that one registry over one Postgres pool. There is no second backend. This page is about the registry itself: how a verb is registered with its tier, risk, and egress class, and how the MCP front door projects a deliberately narrow slice of that registry to the caged agent so it sees exactly what it is allowed to call and nothing more.
What it does
One registry, one dispatch, three doors. Each verb is registered once with its metadata and dispatched through the same path no matter where the call came from. The CLI, the POST /v/:verb HTTP route, and the POST /mcp agent transport all resolve the same registry and the same pool, so a verb run by an agent and a verb run by a person obey identical checks and leave identical audit trails. The MCP layer is a translator, not a second engine: it parses the JSON-RPC envelope, projects the registry into the tool list, and routes every call straight into the one dispatch. See the kernel for the full front-door model.
A tiered view for the agent, not a second permission system. Every verb carries a tier - Core, OnDemand, Vertical, or AdminOnly - and the MCP tools/list surface advertises only the verbs at or below the session’s active ceiling. Core (the everyday actions) loads by default; the agent can step the ceiling up to pull in OnDemand or Vertical verbs when a task actually needs them. AdminOnly verbs are never exposed over MCP, regardless of ceiling: sensitive administration and infrastructure actions are reachable only by an authorised person through the CLI or HTTP door, and even then the permission check still applies. The tiering keeps the agent’s tool surface small and on-task; it is not where access is decided. That is still tier, autonomy, and scope at dispatch.
The egress chokepoint, declared on every verb. Each verb declares whether its handler makes an outbound call that leaves the box, and on which rail. Most verbs are pure-Postgres and never egress, so they are exempt by construction. The ones that do reach out are gated at the dispatch chokepoint against a per-workspace policy. egress.policy.set writes a per-rail, max-classification allow for a workspace: the floor is set by the substrate, the policy can only ever tighten it, and regulated material is never allowed out by default. Because the rail is declared on the registry row, an undeclared-but-egressing verb is a build-time finding, the egress twin of the rule that an unregistered verb cannot be called at all.
A rendered export through one governed seam. render.export takes the output of a read verb and renders it to a finished file in a chosen format, all through the same permission-checked, audited dispatch as any other verb. It is rated Sensitive and runs at Member tier, so exporting a record out of the system is a deliberate, recorded act rather than a quiet side channel.
Object visibility, set in the open. object.visibility.set adjusts the visibility of an object through the access-control path (it writes against acl.write), so a change to who can see something is itself a governed verb call on the record, not an out-of-band toggle.
A health probe that proves the door is up. system.health is a live liveness probe that registers the health check the kernel was built around. It is a Read-tier verb, so it is dispatchable through the registry like any other; separately, the kernel exposes an unauthenticated GET /health for plain liveness that discloses no version. Together they let an operator (or a durable orchestrator) confirm the box is answering without reaching any client data.
How you use it
Let the agent reach for the right tools. The agent starts with the Core verbs loaded - the ordinary create, get, list, edit actions of every area. When a task needs something less common, it raises its tier ceiling and the OnDemand or Vertical verbs appear in its tool list. You do not hand it a key; you let the registry surface widen on demand, while the real authority checks stay at dispatch.
Set what may leave the box. As an admin, set a per-rail egress policy for a workspace so that outbound calls on a given rail are allowed only up to a stated classification. The policy can tighten the substrate floor but never loosen it, and regulated data stays in unless you say otherwise.
Export a record. Run render.export against a read verb’s output to produce a finished file in the format you need. The export is Sensitive and audited, so the act of taking data out is always on the record.
Check the box is live. Call system.health for a governed liveness probe, or hit the unauthenticated /health endpoint for a bare status with no version disclosure - useful for a load balancer, a monitor, or a retrying orchestrator.
The kernel verbs behind it
Every action below goes through the one front door - permission-checked and audited before it runs (see Security & permissions). These are the verbs most specific to the registry and the MCP door.
egress.policy.set- set a per-rail, max-classification egress allow for a workspace; tighten-only over the substrate floor, regulated-never-by-default.object.visibility.set- change an object’s visibility through the access-control path, as a governed write on the record.render.export- render a read verb’s output to a finished file in a chosen format; Sensitive and audited.system.health- a live health probe, registering the M0-built health check so it is dispatchable like any other verb.
For the whole catalogue and how the tiers work, see Capabilities and the full Verb reference.