Library Reference

Knot provides several libraries in the knot.* namespace for interacting with the platform from scripts.

Available Libraries

Library	Description
`knot.ai`	AI client for chat completions, embeddings, and streaming responses.
`knot.apiclient`	Transport layer used by all knot.* libraries for HTTP and AI connectivity.
`knot.audit`	Audit log search and filtering functions.
`knot.event`	Event emission in space-side scripts and payload accessors in sink scripts.
`knot.files`	File storage from scripts — read, write, list, copy and delete files in buckets, and manage the buckets.
`knot.group`	Group management functions including quotas and membership.
`knot.healthcheck`	Functions for space health monitoring in agent-side health check scripts.
`knot.identity`	The authoritative requesting-user surface for plugin and tool code - a real User object with permission checks, over the gated loopback.
`knot.jobs`	Scheduled job management for spaces.
`knot.mcp`	MCP tool discovery and execution across all execution environments.
`knot.methods`	Register JSON-RPC methods for the current space from startup scripts.
`knot.methods.schema`	Build JSON Schema fragments for method params and result definitions.
`knot.permission`	Permission constants and a function to list available permissions.
`knot.plugin`	Call plugins' declared handlers as the requesting user - in-process between plugins, over the authenticated loopback from user-created tools.
`knot.pool`	Manage space pools that keep a desired count of identical spaces running.
`knot.role`	Role management functions for creating roles and assigning permissions.
`knot.script`	Script management and execution functions for stored and inline scripts.
`knot.server`	Exposes server-wide information such as version, wildcard domain and tunnel domain.
`knot.skill`	Manage skills — markdown knowledge base content for AI agents.
`knot.slash_command`	Manage slash commands — reusable prompt templates invoked from the AI chat.
`knot.space`	Space management functions for creating, running, and editing spaces.
`knot.stack`	Stack template management and stack lifecycle functions.
`knot.template`	Template management functions for space configuration definitions.
`knot.token`	Manage API tokens — mint scoped keys, list them, revoke them.
`knot.user`	User management functions including permissions, quotas, and SSH keys.
`knot.vars`	Template variable management functions including protected variables.
`knot.volume`	Volume management functions for CSI volume definitions attached to spaces.

Scriptling libraries

The full scriptling.* library set is documented on the Scriptling website, including:

scriptling.grep — fast file content search
scriptling.find — find files by name, type, mtime, and size
scriptling.net.resolve — DNS resolution for IP, SRV, and srv+http URLs
scriptling.provision.file — idempotent file provisioning
scriptling.provision.fetch — download files and unpack zip archives over HTTP/HTTPS

Standard Python-compatible libraries (os, pathlib, glob, tempfile, shutil, shlex, subprocess, re, json, time, etc.) are also available — see the Scriptling library reference for the full list. Availability varies by execution environment; see Library Availability for details.

Usage

Import libraries using standard Python import syntax:

    
    
  
import knot.space as space
import knot.ai as ai
import knot.mcp as mcp

# Use the libraries
spaces = space.list()
client = ai.Client()
tools = mcp.list_tools()

Environment Compatibility

Each library’s availability depends on where the script runs. Not every library is available in every context — most notably, MCP tool execution, event sink and plugin handler environments do not provide knot.methods, and MCP tool and event sink environments have no system access libraries. Every reference page opens with an Execution Environment table showing exactly where that library works.

Summary of the embedded execution contexts:

MCP tool execution, event sink scripts, plugin handlers, remote/space scripts, and knot run-script register the Go-provided knot.apiclient transport, so the API libraries (knot.space, knot.user, knot.group, knot.role, knot.audit, knot.files, knot.permission, knot.vars, knot.volume, knot.script, knot.skill, knot.slash_command, knot.server, knot.template, knot.stack, knot.pool, knot.jobs, knot.token), plus knot.ai and knot.mcp, are available and authenticated automatically.
knot.methods / knot.methods.schema are agent-side only: remote/space scripts, knot run-script, and knot methods register. They are not available in MCP tool execution, event sink scripts or plugin handlers.
knot.event is context-sensitive: emit() runs in space-side scripts, MCP tool execution, plugin handlers, and external standalone scripts; the payload/metadata accessors run only in event sink scripts, where emit() is not available.
knot.healthcheck runs in every agent-side (space) script — health check scripts, startup scripts, knot run-script — but not in MCP tool execution, event sink scripts or plugin handlers.
knot.identity and knot.plugin are server-side only: MCP tool execution, event sink scripts and plugin handlers.
Health check scripts run agent-side in the space and share the full Space environment; they have no knot.apiclient transport, so the API libraries are not usable there.

For standalone scripts running outside knot (the scriptling CLI), the Python implementations resolve over HTTP via knot.apiclient configuration (knot.event.emit() included); knot.methods, the knot.event sink accessors, knot.healthcheck, knot.identity and knot.plugin have no standalone form.

Authentication

Scripts automatically authenticate using the context they’re running in — no explicit token handling is needed. The knot.apiclient transport is pre-configured by the runtime.