Skip to main content

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.

Noorle plugins are WebAssembly (WASM) modules that run in a secure sandbox, enabling custom compute logic while maintaining strict security and resource boundaries.

​
How Plugins Work

​
Compilation to WebAssembly

Your plugin source code (Rust, Python, TypeScript, etc.) is compiled to WASI Preview 2 WebAssembly, a standards-based binary format that runs on any platform.

​
Secure Sandbox Execution

Plugins execute in Wasmtime, a WebAssembly runtime that provides:
  • Process isolation - Plugins cannot access host system
  • Resource limits - Memory, CPU, and execution time constraints
  • Permission gates - Explicit allow/deny for network, filesystem, environment
  • Zero trust - Everything denied by default

​
Plugin Package Format (.npack)

Plugins are distributed as .npack files, which are gzip-compressed tar archives containing: 
my-plugin.npack (tar.gz)
├── plugin.wasm          (required)
├── noorle.yaml          (optional)
├── world.wit            (optional)
└── .env                 (optional)

​
Required Files

plugin.wasm
  • The compiled WebAssembly module
  • Contains your plugin’s tools and business logic
  • Compiled to WASI Preview 2 target

​
Optional Files

noorle.yaml
  • Plugin metadata (name, description, author, tags)
  • Runtime profile selection
  • Security permissions (network, filesystem, environment)
  • Resource limits (memory, timeout)
world.wit
  • Component Model World Interface definition
  • Documents your plugin’s exported functions and their signatures
  • Enables introspection and discovery
.env
  • Environment variables for your plugin
  • Encrypted at rest, visible only to your plugin
  • Not included in source control

​
Component Model Integration

Noorle plugins use the WebAssembly Component Model, a standardization effort that defines:
  • Tools as exported functions with typed parameters and return values
  • Resources as opaque handles managed by the host
  • Host functions that plugins can import (I/O, networking, etc.)
Example Component Interface (WIT): 
package noorle:plugin;

interface tools {
  get-weather: func(city: string, units: string) -> string;
  search-news: func(query: string, limit: u32) -> list<article>;
}

world my-plugin {
  export tools;
}

​
Capability Integration

Plugins integrate with Noorle’s unified capability system:

​
Tool Definition

Tools are the main interface your plugin exposes. Each tool:
  • Has a name - Used to invoke the tool (my_plugin_my_tool)
  • Takes inputs - JSON Schema-defined parameters
  • Returns output - JSON or structured data
  • Is discoverable - Listed via the tools/list MCP method
Example tool definition: 
{
  "name": "my_plugin_get_weather",
  "description": "Fetch current weather for a city",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": { "type": "string" },
      "units": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"]
      }
    },
    "required": ["city"]
  }
}

​
Execution Flow

When a tool is invoked: 
1. Agent/MCP Gateway calls tool
   ↓
2. Capability Service looks up plugin
   ↓
3. Permission engine validates access
   ↓
4. Tool invocation passed to Wasmtime
   ↓
5. Plugin WASM executes in sandbox
   ↓
6. Result serialized and returned

​
Version Management

Plugins support multiple versions: 
my-plugin (Capability)
├── v1 (archived)
├── v2 (archived)
└── v3 (active)
  • Active version - The version currently used by agents/gateways
  • Previous versions - Available for rollback or A/B testing
  • Version history - Audit trail of all deployments

​
Key Concepts

ConceptDescription
ToolExported function from your plugin with inputs and outputs
CapabilityAbstraction representing a plugin, builtin, or connector
SandboxWasmtime runtime with strict resource and permission boundaries
PermissionAllow/deny rules for network, filesystem, environment access
Component ModelW3C standard for WebAssembly module composition
WASI Preview 2Standard system interface for WebAssembly modules

​
Why WebAssembly?

WebAssembly provides:
  • Portability - Runs on Linux, macOS, Windows, and cloud platforms
  • Performance - Near-native execution speed
  • Security - Strict sandboxing prevents access outside defined boundaries
  • Language agnostic - Compile from Rust, Python, Go, TypeScript, etc.
  • Standardized - W3C standard ensures long-term stability

​
Next Steps