> ## Documentation Index
> Fetch the complete documentation index at: https://noorle.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Capabilities
> The three capability kinds — built-in, plugin, connector — how they are named as tools, and the exposure scope that decides which surfaces can see them
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.
| Kind | Who writes it | Where it runs |
| ------------- | ------------- | ------------------------------------- |
| **Built-in** | Noorle | The platform |
| **Plugin** | You | A WebAssembly sandbox |
| **Connector** | Someone else | Their server, called over the network |
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.
| Capability | Tools | Available to |
| -------------------- | ----------------------------------------------------------------------------------------- | -------------------- |
| Files | `ls`, `read`, `write`, `append`, `rm`, `rmdir`, `mkdir`, `cp`, `mv`, `stat`, `exists` | agent, MCP, workflow |
| Web Search | `search` | agent, MCP, workflow |
| HTTP Client | `request` | agent, MCP, workflow |
| Knowledge Retrieval | `search`, `list`, `get_by_id` | agent, MCP, workflow |
| Code Runner | `python`, `javascript` | agent, MCP, workflow |
| Sandbox | `exec`, `read_file`, `write_file` | agent, MCP, workflow |
| Browser | `markdown`, `content`, `extract_json`, `screenshot`, `scrape`, `links`, `pdf`, `snapshot` | agent, MCP, workflow |
| Memory | `store`, `recall`, `forget` | agent, MCP, workflow |
| **Computer** | `status`, `reboot`, `run`, `read`, `write`, plus optional browser tools | **agent only** |
| **Plugin Builder** | `build`, `cancel`, `status` | **agent, MCP** |
| **Skill Builder** | `manage`, `status` | **agent, MCP** |
| **Workflow Builder** | `generate`, `status` | **agent, MCP** |
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.
| Tier | Tools |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Read** | Files `ls`/`read`/`stat`/`exists`; Memory `recall`; all of Web Search and Knowledge Retrieval |
| **Act** | Every other Files tool; Memory `store`/`forget`; all of HTTP Client, Code Runner, Browser; **every plugin tool; every connector tool** |
| **Privileged** | All of Sandbox, Computer, Plugin Builder, Skill Builder, Workflow Builder |
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](/docs/learn/concepts/webassembly) 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](/docs/learn/concepts/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:
```
file_read file_write file_ls ...
web_search
http_request
knowledge_search knowledge_list knowledge_get_by_id
run_python run_javascript
sandbox_exec
browser_markdown browser_screenshot ...
memory_store memory_recall memory_forget
computer_run computer_status ...
plugin_build skill_manage workflow_generate
```
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
Twelve capabilities, already seeded, nothing to deploy. Most agents never need more.
If the system already has a REST API or an MCP server, a connector is minutes of configuration and no code to maintain.
Reach for WebAssembly when the behavior is proprietary, must be deterministic, or handles data you want kept inside a sandbox.
Computer is agent-only for a reason. If you are composing a gateway for outside callers, check what each capability actually exposes.
***
Next: [Agents](/docs/learn/concepts/agents) — what runs the loop that calls these.