A toolkit is the unit of capability — packaged sandboxed WebAssembly that does one thing, authored in any language, run isolated, and shipped inside a workbook. This is the integration ecosystem: the catalog of external services and local capabilities a workbook (or its agent) can reach, plus how you author and add new ones.

New to the idea? Read the deep explanation once, then come back: Giving it abilities · Safe powers · Who sees what. The thin concept stub is What is a toolkit — this page is the library, not the lesson.

A toolkit declares an #+EXEC shape (how it's called), the #+CAPS it needs (what the host must grant), and a #+TRUST posture (how isolated the host runs it). The host holds the credentials and owns egress: a toolkit that calls a service never sees the API key and never opens its own socket — it asks a capability across the Dock, and the host does the work. An ungranted capability simply does not exist for it.

flowchart LR
  wb["workbook / agent"] -->|invokes| tk["toolkit · WASM"]
  tk -->|"declares #+CAPS"| dock{{the Dock}}
  dock -->|"holds creds, owns egress"| svc["external service"]
  dock -. "ungranted = does not exist" .-> x["✕"]

For why it is built this way — capability gating, isolation tiers, the host-as-broker — read the canonical pages under /learn. This section never re-explains them; it links them and gets on with the catalog.

The same toolkit appears under three indexes. Pick whichever matches how you're thinking about the problem.

The Zapier-style view: "Workbooks + <service>". Each links a detail page (see the integration page template).

the intended integration* — the toolkit may be a stub or compose existing primitives. Always trust the toolkit's own #+STATUS: and its detail-page maturity drawer over this summary row.

Group by the #+CAPS a toolkit needs. The cap names and the profiles that grant them are defined in policy.ex (minimal / network / posix; the fail-closed default compute = vfs only).

See Dock capabilities for the exhaustive, tangled-from-code cap list.

Group by #+EXEC. Same package format, same trust model — the shape only selects how the artifact is invoked.

The six shapes in depth: The six shapes · field reference: #+EXEC shapes.

Two motions: link an existing one (you want a capability) and author a new one (the capability doesn't exist yet).

The intended one-liner — pull a toolkit from the library into the current workbook by id:

wbx toolkit add fly          # resolve from the library, grant its #+CAPS
wbx toolkit list             # what this workbook can reach

Until the registry ships, you reference a toolkit by its id and the runtime resolves it from toolkits/<id>/ in the tree. The credentials it needs are held by the host (see each detail page's "How to add it"), never embedded in the workbook.

When the capability doesn't exist, write one. The full guide is Pick a shape → The Dock SDK; the manifest minimum is:

#+TOOLKIT:    my-tool
#+EXEC:       command
#+TRUST:      first-party
#+BUILD_LANG: rust
#+BUILD_SRC:  path:src
#+CAPS:       vfs net

The runtime compiles your source to WASM inside its own sandbox — no toolchain to install, and untrusted source never touches a native compiler. Authoring canon lives in toolkits/AUTHORING.org.

The intended flow — sign your toolkit and publish it to the shared library so others can wbx toolkit add it:

wbx toolkit sign my-tool      # third-party signature (planned)
wbx toolkit publish my-tool   # push to the library (planned)

• Concept: What is a toolkit · The Dock & capabilities · Isolation tiers

• Build: Pick a shape · The Dock SDK · Authoring skills

• Reference: Toolkit catalog & status · Manifest fields · Dock capabilities

• Honesty: Capability Matrix

• Integration page template: _template.org