Tool Registry

Governance → Tool Registry is the org-scoped catalog of admitted tools — the admission gate for what can reach an agent. A skill's tool dependencies must come from this registry: a skill that references an unregistered tool is rejected when the skill is saved and again when an agent builds. Registering a tool is how an org admin says "agents in this org may depend on this."

Every workspace member can view the registry (the skill builder's tool picker reads from it), but registering, refreshing, and removing entries requires the org admin role — the platform enforces this on every write, regardless of what the console displays.

Some entries are labeled auto: they were back-filled from the binaries existing skills already used, recorded for visibility rather than registered by hand.

What an entry contains

Every entry has a key (lowercase, e.g. bin.kubectl, mcp.linear, api.member-service — unique within the org; registering a duplicate key is rejected), an optional description, and a list of operations. Operations are the governable unit: each carries a name, a description, and a side-effect class — read, mutating, or destructive — that classifies what the operation does. Side-effect classes are declarative today: they describe the operation and will seed policy defaults as admission enforcement grows.

The registry table shows each entry with its operations expandable inline, each operation with its side-effect chip.

Three kinds of entry

The Register tool form offers three entry types, each with its own fields.

Command-line tools

A binary the agent may invoke from its scripts. The form asks for the executable name, an optional package (the system package that provides it), and an optional digest (recorded for provenance, not verified at build). You can decompose the binary into named operations, each with its own side-effect class; if you don't, the entry gets a single whole-binary operation classified as mutating.

MCP servers

A remote tool server speaking the Model Context Protocol. The form asks for the server URL and how agents authenticate to it:

• none — the server is called unauthenticated.
• bearer / static token — the platform assigns a token variable name derived from the entry's key. The registry stores only the name: whoever configures an agent that uses the tool is prompted for the token value at finalize, and the value is vaulted per agent — never stored on the registry.
• oauth — before registering, the console resolves and displays the server's declared authorization endpoints and advertised scopes for review; you choose which scopes to request. Registering pins what you reviewed and opens a one-time consent so the connection can be validated and the server's tools listed. Consent as a dedicated service account, not a personal login — the identity you authorize is the identity on every agent read of this server.

By default, registration connects to the server and discovers its tools; each discovered tool becomes a registry operation. If the server requires authentication to list its tools, you can paste a discovery token — used once for that listing call and never stored, independent of how agents authenticate at runtime. You can also skip discovery and refresh later.

APIs from an OpenAPI spec

A REST API registered from its OpenAPI 3.x document. The form asks for:

• Base URL — the host agents call (must be an http(s) URL; egress from an agent to this host is governed like any tool call).
• The spec — paste the OpenAPI document as JSON, or give a spec URL the platform fetches at registration. For a protected spec URL you can supply a one-shot spec fetch token — used once for that fetch, never stored.
• Auth — none, bearer, or static token, with the same platform-assigned token variable convention as MCP servers. OAuth is not accepted for API entries; an API registration that requests it is rejected.

The platform decomposes the spec into operations: each path-and-method pair becomes an individually governed operation, named after the spec's operationId (or a name derived from the method and path when the spec doesn't provide one). The operation's side-effect class comes from the HTTP method — GET/HEAD/OPTIONS are read, DELETE is destructive, and POST/PUT/PATCH are mutating. Each operation's parameters and JSON request body are captured as its typed argument fields — the exact vocabulary compliance rules are authored against.

What registration feeds

Registered operations are what the rest of the platform builds on:

• Skills declare them as dependencies. A skill lists the registered tools it uses, and the configure screen collects any tokens they need — see Skills.
• Compliance rules are keyed on them. A registered operation is addressed as <server>__<operation> in Compliance and tool-call decisions; only operations of registered tools can be governed.
• Connections bind to them. For servers whose tools act with a workspace or user identity, the accounts live per workspace under Connected Accounts — the registry is the org-level admission surface, not where credentials live.

Keeping entries current

MCP entries have a Refresh action that re-runs discovery against the live server and reports the drift before saving it: operations added, operations removed, and operations whose input schema changed. Like registration, refresh accepts an optional one-shot token for servers that require authentication to list tools.

For OAuth entries, refresh also re-reads the server's advertised authorization metadata and compares it against what was admitted. A mismatch is surfaced — with the admitted and now-advertised values side by side — and recorded on the activity feed, but the admitted values are always kept; drift never silently rewires where an agent authenticates.

Refresh applies to MCP entries; binary and API entries keep the operations they were registered with.

Removing an entry

Remove deletes an entry from the registry — but the platform refuses while any skill still references it, naming the agents involved. Remove the skill references first, then the entry.