Skip to main content
Every new account is seeded with twelve built-in capabilities. They are not installed or purchased — they are already there, dormant until you bind them to an agent or a gateway.

​
The twelve

Plugin Builder builds a plugin from a description you give it, and what it produces is Rust. Plugins you write and upload yourself can be written in Rust, Python, Go, JavaScript, or TypeScript — the Build tab covers that path.

​
Tool names

A tool’s wire name is {namespace}_{tool}. So Files’ read tool is file_read, not files_read; code execution is run_python and run_javascript; memory is memory_store / memory_recall / memory_forget. The namespace is a column on the capability row, unique per account. The built-in namespaces are platform constants — every account is seeded with the ones in the table above.

​
Exposure scopes

Each built-in declares which of three surfaces it may appear on — Agent, MCP, Workflow — and the platform filters tools/list accordingly. This is code, not configuration; you cannot widen it.
  • Computer is agent-only. It never appears on an MCP gateway, and its own tool listing returns empty for non-agent callers as a second guard.
  • The three builders have no workflow scope, because a workflow execution context carries no authenticated user principal.
  • Everything else is available on all three surfaces.
Connector and plugin capabilities are not scope-filtered — exposure scoping applies to built-ins only.

​
Workspace anchoring on gateways

Some tools need a workspace to read and write. The platform derives that workspace server-side from the gateway plus the authenticated user; nothing about it comes off the wire. An anonymous caller on a public gateway has no workspace, so those tools are removed from tools/list and from the discovery corpus — they are not callable by name either. Browser’s markdown, content, extract_json, scrape, and links stay available without a workspace. Agent and workflow surfaces are unaffected.

​
Risk tiers

Each tool declares a tier, which is what the autonomy gate acts on:
  • Read — Web Search, Knowledge Retrieval, Memory recall, and Files’ ls / read / stat / exists.
  • Act — HTTP Client, Code Runner, Browser, Memory store / forget, and Files’ mutating tools. Plugin and connector tools are Act, kind-wide.
  • Privileged — Sandbox, Computer, and the three builders.
See Autonomy and approvals.

​
Binding a capability

Bind on the resource that will use it:
  • Agent — Agents → (agent) → Capabilities, under “Built-in capabilities”. The same view has “Plugins” and “Connectors” cards.
  • Gateway — Gateways → (gateway) → Capabilities.
Some capabilities carry per-binding configuration. Web Search takes a search depth; Knowledge Retrieval takes the knowledge bases it may search; Browser takes an allowed-tool list; Computer takes shell and browser subsystem settings.

​
What is not a capability

  • Skills — skills_list, skills_view, skills_search appear once an agent has bound skills. Authoring skills is the separate, bindable Skill Builder.
  • Journal search — journal_message_search and journal_tool_call_view. Agent surfaces only; never on a gateway.
Workflows attached to an agent or a gateway also appear as tools.

​
Next