> ## 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. # When to build a plugin > Decide between a built-in capability, a connector, and a WASM plugin — what each one covers, and the cost of choosing the last one. Writing a plugin is the most expensive way to add a tool. It is also the only one that runs your code. Work through the cheaper options first. ## Ask in this order **1. Does a builtin already do it?** Twelve built-in capabilities are seeded into every account and maintained by Noorle. They cover a lot of what people reach for first. **2. Is it an HTTP API?** A REST connector needs no code — point it at a base URL and define the operations, or import an OpenAPI 3.x or Swagger 2.0 document and get them generated. **3. Is there an MCP server for it?** Add one from the MCP registry, or point Noorle at your own MCP server over Streamable HTTP. **4. Is it computation you own?** Now write a plugin. ## The twelve builtins Names and descriptions exactly as they are seeded into a new account — this is the text you see next to each one in the Portal: | Capability | What it does | | ---------------------- | -------------------------------------------------------------------------------------------------------------- | | **WebSearch** | Search the web for any topic and get clean, ready-to-use content. | | **Memory** | Store, recall, and forget durable facts that persist across conversations | | **Browser** | Browse, render, screenshot, and extract data from web pages using a headless browser | | **HTTPClient** | Make HTTP API requests to any URL. Supports all methods, custom headers, and request bodies. | | **KnowledgeRetrieval** | Search through indexed knowledge bases and documents | | **Files** | Direct access to read, write, and manage files in the shared workspace | | **CodeRunner** | Run Python and JavaScript snippets instantly with shared workspace access | | **Sandbox** | Disposable Linux environment with shared workspace access | | **Computer** | A persistent, always-on dedicated Linux machine with shared workspace access | | **PluginBuilder** | Autonomously build new capabilities from natural language — if a tool doesn't exist, create it on the fly | | **SkillBuilder** | Author reusable skills from natural language — create, import, generate, and refine the skills your agents run | | **WorkflowBuilder** | Generate multi-step, durable workflows from natural language to orchestrate complex tasks | Two exposure notes: **Computer** is available to agents only — it never appears on a gateway. The three builders are available to agents and gateways but not inside workflows, because a workflow step carries no authenticated user. Details: [Built-in capabilities](/docs/run/capabilities/overview). ## Connectors Three kinds: | Kind | Use it for | | ---------------- | ----------------------------------------------------------------------------------------- | | **REST** | Any HTTP API. Define operations by hand, or import an OpenAPI 3.x / Swagger 2.0 document. | | **MCP registry** | A server published to the MCP registry, added by name and version. | | **Custom MCP** | Your own MCP server, dialled over Streamable HTTP. | Connector credentials are encrypted at rest. Details: [Connectors](/docs/run/connectors/overview). ## When a plugin is the right answer A plugin runs your compiled code inside the platform sandbox. Reach for one when: * the work is **computation you own** — a transformation, a scoring function, a parser, a proprietary algorithm — rather than a call to someone's API; * you want **several calls collapsed into one tool**, so the model sees one decision instead of five; * you need logic to run **under a policy you declare** — a named host allowlist, no filesystem, credentials it can never read — and want that boundary enforced rather than reviewed; * an existing API needs **non-trivial glue** before its output is useful to a model. ## What you take on * **Code you maintain.** A connector's provider ships changes; a plugin's bugs are yours. * **A build toolchain.** The component must be a valid WASI Preview 2 component that passes [admission validation](/docs/build/plugins/overview#admission-validation). Noorle documents five — [Rust](/docs/build/languages/rust), [Python](/docs/build/languages/python), [JavaScript](/docs/build/languages/javascript), [TypeScript](/docs/build/languages/typescript), and [Go](/docs/build/languages/go) — each with a working example. * **A tighter runtime than a normal process.** Default 30-second wall clock, 128 MB memory, 100 outbound HTTP requests per execution, no host filesystem, no raw sockets. See [Permissions](/docs/build/plugins/permissions). * **A coarser approval story.** Every plugin tool is classified `Act` kind-wide — there is no way to mark a read-only tool `Read`, so where autonomy enforcement is on, each one pauses for approval under `Supervised` until it is auto-approved. ## Worth knowing before you decide **Cost.** Plugin executions are metered, as connector and HTTP-client calls are. What each one costs shows up in your account's usage — see [Usage and limits](/docs/run/platform/usage-and-limits). **You do not have to write it yourself.** Plugin Builder takes a natural-language requirement and produces a plugin through the same validation and registration path — **Plugins → New plugin → Build with AI** in the Portal, or bind the Plugin Builder capability to an agent. See [generating a plugin](/docs/build/plugins/overview#generating-a-plugin). **CodeRunner is not a plugin substitute.** It runs a Python or JavaScript snippet with workspace access, which is excellent for one-off computation inside a turn and wrong for a tool you want listed, versioned, and callable by name. ## Next * [How plugins run](/docs/build/plugins/overview) * [Quickstart](/docs/build/plugins/quickstart)