Skip to content
Docs menu

Docs Overview

Overview

What the capability hub is, how one MCP endpoint gives every agent your tools, and what exists today.

capabilities is a hub for people who use agents. Your MCP servers, HTTP APIs and skills, with their credentials and policies, live in one hub. Every agent reaches all of them through one MCP endpoint, and the model works through three tools instead of hundreds of tool definitions:

  • search finds your tools by what you want done and returns their addresses with one-line TypeScript signatures.
  • describe returns exact TypeScript declarations for the tools the model is about to call.
  • execute runs the model's JavaScript in a sandbox where each of your sources is a global object of async functions.

You stay in control. Reads run. Writes ask. Only a person approves, never the model. Secrets never reach the model, the sandbox, a log or a result.

Why one endpoint

Each job below comes from the design spec, with the milestone that delivers it.

  • Set it up once (M1). Import what each agent harness already has, review it on one screen, then point every harness at the hub.
  • Multi-step work without flooding context (M1). The model searches, reads typed signatures, and writes code that chains calls across sources in one execute.
  • Nothing you did not agree to (M1). Reads run, writes ask, and a tool that changes upstream asks again before it runs.
  • Reach from cloud agents (planned, M3). The same hub, hosted on Cloudflare behind OAuth, for claude.ai, ChatGPT and phones.

How a request flows

 Claude Code ─┐
 Codex ───────┼──▶  capabilities hub  ──▶  search · describe · execute
 Cursor ──────┘            │
                           ├─ sources       MCP servers over stdio or HTTP
                           ├─ connections   credentials in your OS keychain
                           ├─ policy        allow · ask · deny, per tool
                           └─ sandbox       QuickJS: no network, no files, no secrets
  1. The model calls search("open bugs") and gets back tool addresses such as github.searchIssues with their signatures.
  2. It calls describe("github.searchIssues") for the exact input and output types.
  3. It calls execute with code like await github.searchIssues({ q: "is:open label:bug" }), chaining as many calls as the task needs.
  4. Each tool call inside the run is decided by policy. A write that needs a person pauses the run and asks. When the person decides, the run resumes from its journal, so no call that already happened is made twice.

Local first, hosted later

Local hub Hosted hub
Runs On your machine, capabilities hub serve On Cloudflare, https://hub.capabilities.sh/mcp
Reaches Agents on your machine, over stdio or loopback HTTP Cloud agents: claude.ai, ChatGPT, phones
Price Free; open source under MIT when it ships Paid; pricing is not decided
Status In progress: M1 now, M2 next Planned: M3 alpha, M4 launch

Both run the same engine behind different ports, and shared conformance suites hold them to the same behavior.

What exists today

  • The hub's contracts and most of the engine are merged: search, typed declarations, policy, the MCP source kind, the guest prelude, the QuickJS sandbox, runs with journal replay, and the CLI's local ports. The rest of M1 is listed on Status.
  • The capabilities CLI exists in the repository with its census commands (list, doctor, rollback, login) and the stack preview. It is private and unreleased, and there is no npx install yet.
  • None of the capabilities hub commands on these pages runs yet. They land with M1.
  • Quickstart: the first local run, step by step.
  • Concepts: sources, namespaces, connections, policies, runs and journals.
  • The MCP surface: the three tools and what code can do inside the sandbox.
  • Security and approvals: who may approve, and what never leaves your machine.
  • For agents: llms.txt, Markdown twins and setup snippets.

Updated 2026-11-06