Skip to main content
A capability is anything an agent, gateway, or workflow can call. Noorle has exactly three kinds, and they differ in who wrote the code and where it runs. Every capability, whichever kind, is bound to an agent, an MCP gateway, or a workflow — and every one of them reaches the model as an MCP tool.

​
Built-in capabilities

There are twelve, seeded into every account at signup. Web Search is backed by Tavily. Code Runner executes Python and JavaScript as WebAssembly components — those two languages, not a general language runner.

​
Exposure scope

Each built-in declares which surfaces may see it, as three independent flags: AGENT, MCP, WORKFLOW. This lives in code, not in the database, and it is enforced when the tool list is assembled.
  • Computer is AGENT only. It never appears on an MCP gateway, no matter how it is bound.
  • The three builders are AGENT | MCP, never WORKFLOW — workflow execution contexts carry no authenticated user principal, and authoring a construct needs one.
  • Everything else is all three.
Exposure scoping applies to built-ins only. Plugins and connectors are visible on any surface they are bound to.

​
Risk tiers

Each tool carries a risk tier that the autonomy gate reads when deciding whether a call proceeds, pauses for approval, or is denied. Note that HTTP Client is Act across the board — its verb lives in the arguments, so even a GET rides the Act tier. And plugins and connectors are Act kind-wide: the platform cannot see inside them to classify per tool.

​
Tools that need a workspace

Some tools need somewhere to put bytes. On an MCP gateway with no authenticated caller there is no workspace to anchor them to, so they are withheld from the tool list entirely rather than advertised and then failed:
  • Files — all tools
  • Sandbox — all tools
  • Browser — screenshot, pdf, snapshot only. markdown, content, extract_json, scrape, and links stay available.
Agent and workflow surfaces are unaffected. Guessing a withheld tool’s name and calling it returns the same error as an unknown tool, which does not confirm that the tool exists.

​
Plugins

A plugin is a WebAssembly component you upload as a .npack archive. It runs in a Wasmtime sandbox under WASI Preview 2, with a capability-based filesystem, an allowlist for outbound hosts, and hard caps on memory and CPU. Use a plugin when the logic is yours and you do not want it leaving your control: proprietary scoring, a calculation you need to be deterministic, something that touches values you would rather not hand to a model. See WebAssembly Plugins for the format, the sandbox, and the limits.

​
Connectors

A connector points at something that already exists. Three kinds:
  • REST — a base URL and a list of operations, each with a method, path template, and input schema. An OpenAPI 3.x or Swagger 2.0 document can be imported to generate them.
  • MCP Registry — a server from the public MCP registry, referenced by its registry name and version.
  • Custom MCP — your own MCP server, reached over Streamable HTTP.
Credentials are encrypted at rest with AES-256-GCM. OAuth 2.1 is supported for REST and MCP connectors; tokens refresh under a distributed lock. See Connectors for the detail.

​
How a capability becomes a tool name

Every capability row carries a namespace, unique per account. The wire name a model sees is {namespace}_{tool}. For an account provisioned by current code, the built-in namespaces produce:
Note file_, singular — not files_.
Namespaces are seeded per account at signup. Accounts created before the current seed may carry different values. Read the tool list from your own gateway rather than assuming these names.
A collision guard drops any bound tool whose namespaced name would collide with a system tool or one of the four meta-tools (unified_tool, discover_tools, get_tool_schema, execute_tool).

​
System tools are not capabilities

Some tools appear without being bound to anything. They are system tool surfaces, not capabilities, and you cannot attach or detach them:
  • skills_list, skills_view, skills_search — appear once an agent has bound skills
  • workflow_run, workflow_info
  • journal_message_search, journal_tool_call_view — agent surfaces only
  • render_approval_form, render_input_form — interactive surfaces only
Most of these are unavailable on an MCP gateway. Journal tools are agent-only by construction; skills tools need an agent id, which a gateway call has no notion of; form tools need an interactive surface. On a gateway, the workflow tools are the only system tools you will see.

​
What is not configurable per binding

Some things that sound like they should be per-capability knobs are not:
  • There is no per-capability rate limit and no per-capability cost cap.
  • There is no per-capability execution timeout override. WASM plugin timeouts come from the plugin’s own declared limits, clamped against platform config.
  • There is no “require confirmation” flag on a binding. Whether a call pauses for a human is decided by the autonomy gate, from the tool’s risk tier and the agent’s autonomy level.

​
Choosing

Start built-in

Twelve capabilities, already seeded, nothing to deploy. Most agents never need more.

Connector for anything with an API

If the system already has a REST API or an MCP server, a connector is minutes of configuration and no code to maintain.

Plugin for logic you own

Reach for WebAssembly when the behavior is proprietary, must be deterministic, or handles data you want kept inside a sandbox.

Mind the exposure scope

Computer is agent-only for a reason. If you are composing a gateway for outside callers, check what each capability actually exposes.
Next: Agents — what runs the loop that calls these.