ClawQL plugin registry

Status: Living reference (June 2026)
Audience: Operators, contributors, third-party plugin authors
Companion: ClawQL plugin model (concepts and target architecture)

This page is the registry of ClawQL plugins: what exists today, what horizontal packages are becoming plugins, and how to enable or compose each one. For the full explanation of “becoming a plugin” vs package extraction, read the plugin model.

1. Plugin kinds

Not plugins: search, execute, cache, and audit are gateway core — always composed in clawql-api, not optional plugin Layers.

2. Registry (all plugins)

Legend: ✅ Shipped · 📋 Planned or partial (logic may exist; Plugin.onRegister not wired)

3. MCP tools by owning plugin (target)

When plugin registration lands, each tool will be registered only if its plugin is composed.

4. Composition at startup (target)

createClawQLApi({
  plugins: [
    createPanguardProxyPlugin(), // mcp-proxy — always unless disabled
    MemoryPlugin, // when memory tier enabled
    DocumentsPlugin, // when documents tier enabled
    AutomationPlugin, // when schedule/notify enabled
    // LendingPlugin, AcmeWidgetsPlugin, …
  ],
})

Today only PanguardProxyPlugin is passed through createClawQLApi(\{ plugins \}). Horizontal packages are imported by src/tools.ts directly.

5. Third-party plugin checklist (roadmap)

When the public registration API stabilizes:

1. Publish clawql-yourname-feature depending on clawql-core + clawql-api (not clawql-mcp transport).
2. Export a Plugin factory and (eventually) an Effect Layer.
3. Implement onRegister to register MCP tools and declare requiredSpecs.
4. Document the Operator toggle or CLAWQL_ENABLE_* flag.
5. Add a row to this registry via PR (or published manifest in a later phase).

Until then, contribute in-repo via providers/ and MCP tools in the monorepo.

6. References

ClawQL plugin model — horizontal packages and MCP tools

Status: Partially shipped (June 2026)
Audience: Contributors, integrators, and third-party plugin authors
Related: Modularization implementation status · Effect + plugin plan · Plugin registry · Contributor Technical Specification §1.1

This document explains what it means for clawql-memory, clawql-documents, and clawql-automation to become plugins, how that differs from today’s layout, and how third-party plugins will work.

1. One-sentence summary

A plugin is how a package tells clawql-api: “When I’m enabled, register my MCP tools, wire my background workers, declare my provider dependencies, and participate in gateway hooks — and when I’m disabled, leave zero footprint.”

For memory, documents, and automation, yes — the plugin’s main visible job is registering the respective MCP tools (memory_ingest, memory_recall, ingest_external_knowledge, schedule, notify). Plugins also own lifecycle and optional pipeline hooks, not just tool names.

2. Today: packages exist, tools.ts still owns registration

Extraction phases 1–9 moved business logic into workspace packages. MCP registration did not move with it.

Transport-only concerns stay in src/ today:

• Zod schemas at server.tool(...) registration time
• wrapMcpToolHandler (OpenTelemetry)
• logMcpToolShape (payload shape logging, no secrets)
• CLAWQL_ENABLE_* gates in registerTools()

So the split is intentionally incomplete: packages are libraries; tools.ts is still the switchboard that decides which tools exist.

3. Target: each horizontal package ships a Plugin

At gateway startup, composition looks like:

createClawQLApi({
  plugins: [
    PanguardProxyPlugin, // kind: mcp-proxy — policy chokepoint, no new tools
    MemoryPlugin, // registers memory_* tools when enabled
    DocumentsPlugin, // registers ingest_external_knowledge when enabled
    AutomationPlugin, // registers schedule + notify; starts schedule worker
    // future: LendingPlugin, YourCompanyPlugin, …
  ],
})

When CLAWQL_ENABLE_MEMORY=0 (or the Operator CRD omits the memory Layer), MemoryPlugin is not composed → listTools has no memory_ingest / memory_recall, and heavy vault/sql.js paths are not loaded for that process tier.

3.1 MCP tools each horizontal plugin will register

Core tools search, execute, cache, and audit stay in the gateway / core tier — not owned by these horizontal plugins.

3.2 Conceptual onRegister (not shipped yet)

The contributor spec defines the target contract: onRegister receives ClawQLApi and registers tools via Effect. A simplified illustration:

const MemoryPlugin: Plugin = {
  id: 'clawql-memory',
  version: '1.0.0',
  onRegister: (api) =>
    Effect.gen(function* () {
      yield* api.registerMcpTool(
        'memory_ingest',
        memoryIngestSchema,
        handleMemoryIngest,
      )
      yield* api.registerMcpTool(
        'memory_recall',
        memoryRecallSchema,
        handleMemoryRecall,
      )
    }),
  onTeardown: (api) =>
    Effect.gen(function* () {
      // Close pools, flush workers if any
    }),
}

Handlers call into clawql-memory (runMemoryIngest, etc.). Transport wrappers (logMcpToolShape) may remain in a thin MCP adapter or move behind a small registration helper on ClawQLApi — that detail is implementation, not the model.

4. Plugins are more than tool registration

Tool registration is what most integrators see. The full plugin contract (see Contributor Technical Specification §1.1) also includes:

4.1 Panguard: plugin without tools

PanguardProxyPlugin is already shipped. It does not register MCP tools. It implements beforeCallTool so policy/ATR runs on every tool invocation. Same Plugin interface, different role — shows that “plugin” ≠ “adds tools” only.

5. Shipped vs target (honest matrix)

6. What extraction already did vs what “becoming plugins” finishes

Becoming plugins does not mean moving more files — it means owning MCP surface area and lifecycle when enabled, instead of centralizing registration in tools.ts.

7. Third-party and vertical plugins

The same model extends to verticals (clawql-lending, clawql-legal, …) and community extensions:

1. Publish an npm package (e.g. clawql-acme-widgets) depending on clawql-core + clawql-api — not on clawql-mcp transport internals.
2. Export a Plugin (and eventually an Effect Layer).
3. Implement onRegister to register your MCP tools and declare requiredSpecs if you need Postgres, Onyx, etc.
4. Document the Operator toggle or CLAWQL_ENABLE_* flag that includes or omits your Layer.

Until Layer composition is stable, in-repo extensions should continue via bundled providers (providers/) and MCP tools in the monorepo. Third-party registration without forking tools.ts is explicitly roadmap, not current API.

8. Request flow (target)

Agent (stdio / HTTP / gRPC)
        │
        ▼
  MCP transport (src/server*.ts, thin tools adapter)
        │
        ▼
  createClawQLApi({ plugins: [...] })
        │
        ├── Core: search / execute / cache / audit (always on)
        │
        ├── PanguardProxyPlugin.beforeCallTool (every tool)
        │
        └── If MemoryPlugin composed:
              memory_ingest / memory_recall → clawql-memory
            If DocumentsPlugin composed:
              ingest_external_knowledge → clawql-documents
            If AutomationPlugin composed:
              schedule / notify → clawql-automation

9. References