Skip to main content
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: 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.

​
Connectors

Three kinds: Connector credentials are encrypted at rest. Details: Connectors.

​
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. Noorle documents five — Rust, Python, JavaScript, TypeScript, and 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.
  • 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. 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. 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