Capabilities, not tools
An ordinary oRPC procedure plus governance metadata is a capability. One definition serves your UI, AI runtimes, MCP clients, and tests — no duplicated schemas that drift.
Make agents first-class clients of your oRPC application — the same typed procedures, with explicit exposure, policies, approvals, audit, and tracing.
2.0, published to npm. An independent community project — not affiliated with, endorsed by, or maintained by the oRPC project.
New here? Getting started — from an existing oRPC app to a governed tool call in five steps. Want the idea first? Architecture overview — the thesis, the layers, the five core objects. Want to see it work? Customer-support agent — nine capabilities, three surfaces, one approval that a human decides. Upgrading from 1.x? Migration guide — one breaking change, and it may not affect you.
Four ways in, depending on why you are here.
"Should we adopt this?"Architecture overview → Security model → the worked example → FAQ
"I'm integrating it."Getting started → Defining capabilities → Capability exposure → the rest of the guides → Reference
"I'm reviewing its security."Security model (SI-1 … SI-12) → Authorization → Prompt injection → Sensitive data → Idempotency and retries → Execution pipeline → Threat model
"I want to know why it works this way."Architecture overview → Execution pipeline → Decision records
New to the vocabulary? The glossary is short, and every distinction in it is load-bearing. Something not working? Troubleshooting is indexed by what you saw.