Docs menu
Docs Concepts
Concepts
The hub's vocabulary, from source and namespace to run, journal and decision. Generated from the project glossary so it always matches the code.
These are the words the hub, its CLI and this site use, each with one meaning. They come straight from the project glossary (CONTEXT.md), copied into this site at a pinned commit and regenerated whenever that copy is refreshed.
The two relationships that matter most:
- A source yields a manifest of tools. Each tool has an address (
namespace.tool) and a contract digest. The index is built from every manifest. - A tool call is decided by policy against the tool's address and the connection it uses, and recorded in the run's journal with that decision.
The hub
Hub
The service that holds a person's sources, connections, policies and skills and serves them over one MCP endpoint. It runs locally (capabilities hub serve) or hosted (one tenant per account); both are the same engine behind different ports.
Not to be called: gateway, proxy, executor.
Source
Where a hub's tools come from: a remote MCP server, a local stdio MCP server (local hub only), or an OpenAPI document. An MCP-server capability becomes a source when it is added to a hub.
Not to be called: integration, plugin, connector.
Namespace
The identifier a source's tools appear under in code (github, linear). Unique per hub, chosen when the source is added, and stable across refreshes.
Tool address
<namespace>.<tool>, how a run's code, policies and journals name a tool (github.createIssue). The tool part is the source's own name for it, normalized to a JavaScript identifier.
Connection
One named credential for one source (github/work). It holds references to secrets, never their values. A source has zero or more connections and at most one default; code picks another with a call option ({ connection: "work" }).
Not to be called: account, binding, credential (the credential is the secret a connection points at).
Policy
The rule that decides a tool call: allow, ask (a person must approve) or deny. It attaches to a source or a tool, optionally narrowed to one connection. The most specific rule wins, except that a narrower rule can never loosen a deny.
Not to be called: permission, guardrail.
Tool contract
The digest of what a tool claims to be (name, description, input and output schemas, annotations), recorded when a person approves the tool. A refresh that changes the digest puts the tool back to ask until it is reviewed, so the hub never widens its own authority. The tool-level counterpart of a Shape.
Index
The hub's searchable record of every tool and skill it can serve, built from each source's manifest. search reads it.
Not to be called: catalog (that is the public listings repo), registry.
Run
One execute request's lifecycle: its code, status (running, awaiting_input, completed, failed, cancelled, expired), journal, result and logs. A run can take several sandbox attempts, one per resume. Its id is how the model and the person refer to it.
Not to be called: session, job.
Journal
A run's append-only record of tool calls (address, connection, argument digest, outcome) and of the nondeterministic values its code read. Resuming a run replays its journal, so a call that already happened is never made twice.
Profile
A named, curated view of a hub: which namespaces, tools and skills are visible, and whether they are served in code mode or as direct tools. Each profile has its own endpoint. Profiles only curate; they grant nothing and carry no policy. Every hub has a default profile.
Not to be called: toolkit, scope.
Sandbox
The isolated JavaScript runtime that runs a run's code: QuickJS compiled to WebAssembly on a local hub, a Worker Loader isolate on a hosted hub. It has no network, no filesystem and no secrets; its only way out is the tool bridge.
Decision
A person's answer to one pending tool call: once, run, always or deny, recorded with its channel (client prompt, approval page, CLI or dashboard). Never made by the model. Hub text calls asking for one "an approval"; it is distinct from a Shape Approval.
Not to be called: consent, grant.
Also used
Capability
One installable unit — an MCP server or a Skill. The Phase 0 contract accepts exactly three shapes: local MCP server (npm, stdio), remote MCP server (HTTP/SSE), and git-hosted skill pinned to a commit.
Not to be called: plugin, extension, tool (a "tool" is what an MCP server exposes, not the capability itself).
Client
A coding agent whose config the stack workflow writes. Write-client coverage is defined in ADR-0002; the separate read registry follows ADR-0003.
Not to be called: agent (ambiguous with the running LLM session), editor.
Secret store
Where secret values live on a machine: the OS keychain (macOS security, Linux Secret Service) with ~/.capabilities/.env (mode 600) as fallback. Keyed by env var name, shared across capabilities. Values never enter the stack repo; the repo records names only.
Updated 2026-11-06