Product

Extend the runtime itself

Plugins add new tools, providers and UI to AGNT — built from chat, installed with hot-reload, and shared through the marketplace.

Download free See plugin docs

How it works

Build from a conversation

Describe the tool you need; the plugin builder scaffolds, installs and reloads it.

First-class tools

Plugin tools appear in workflows and agent toolkits like any built-in.

Local and inspectable

Every plugin is readable source on your disk — no black boxes.

Who it’s for

For when the tool you need does not exist yet

AGNT ships a large set of nodes and speaks MCP, and eventually you still hit the internal API, the proprietary database or the vendor nobody else uses. A plugin is how you add that tool yourself and have every agent be able to call it.

Setting it up
  1. A plugin is a folder: a manifest.json, a package.json and an index.js. Each tool it exposes declares an inputSchema, so agents discover parameter types instead of guessing.
  2. Install from the marketplace, from a local .agnt file, or straight from a GitHub repository.
  3. Editing one locally? POST /api/plugins/reload picks up your changes without restarting the app.
  4. Read before you trust: GET /api/plugins/installed/:name/source returns the actual files of anything installed.
  5. Before installing, the disclosure report shows integrity state, the capabilities detected in the code with file-and-line evidence, the permissions declared, and the difference between the two.
Declaring a tool, and calling it
Illustrative example — not a screenshot
What the plugin declares:

  {
    "type": "acme-lookup-customer",
    "title": "Look up an ACME customer",
    "category": "action",
    "schema": {
      "inputSchema": {
        "type": "object",
        "properties": {
          "email": { "type": "string" }
        },
        "required": ["email"]
      }
    }
  }

What you then say to any agent:

  "Check whether dana@example.com is on a paid plan."

What comes back, because the schema told the agent the shape
of the call without anyone documenting it in a prompt:

  {
    "success": true,
    "plan": "team",
    "seats": 12,
    "renews": "2027-02-01"
  }
Limitations worth knowing
  • A plugin is Node code running locally with the application’s privileges. Install ones you trust, and read the source endpoint first — the disclosure report exists to make that judgement possible, not to make it unnecessary.
  • Installs and updates go through a staged path: stage, validate, permission-diff, then an atomic swap. An update requesting new permissions returns requiresConsent and changes nothing on disk until it is re-called accepting them. That gate covers permission escalation specifically — it is not a claim that every action a plugin can take is individually approved.
  • Versions that are not semver (local, latest, unknown) report as unknown-version: never compared against the catalog, never auto-updated over.
  • A plugin can report status: "error" or isValid: false. A broken plugin is visible rather than quietly doing nothing, but it is still broken until you fix it.
  • Uninstalling shows which agents, workflows, skills and widgets the plugin owns, flagged by whether you have modified them, so you can see what would be deleted before agreeing to it.

Next: the Plugins & MCP API reference, or connect an MCP server if the tool you want already speaks that protocol.

Give AI a job. Get the proof.

Download free See pricing