Custom (HTTP/SSE + REST)

If none of the first-party adapters fit — you’re building something exotic, in a language we don’t ship, or behind a service mesh that doesn’t allow stdio MCP — there’s still a path. PLUR Enterprise exposes the same engine over HTTP/SSE (for MCP-style streaming) and a versioned REST API.

Two transports, one engine

Transport	Best for	Spec
HTTP/SSE MCP	Anything that already speaks MCP — just change the transport from stdio to streaming HTTP.	MCP streamable_http_transport spec.
REST API	Non-MCP clients — CI, automation, custom integrations, dashboards, mobile.	OpenAPI 3, served at /api/v1/openapi.yaml.

Both share the same underlying data, permission model, and audit trail.

HTTP/SSE MCP

Most MCP clients support streamable_http_transport. Point them at your Enterprise server:

{
  "mcpServers": {
    "plur": {
      "transport": "streamable_http",
      "url": "https://plur.your-org.com/mcp",
      "headers": {
        "Authorization": "Bearer ${PLUR_TOKEN}"
      }
    }
  }
}

Tools, schemas, and behaviour are identical to the local stdio MCP server. The only differences:

• Auth header (Bearer <token>) is required.
• Scopes resolve against your server-side identity (OIDC/SAML/GitHub/GitLab), not your local user.
• Audit log records every call.

See Enterprise self-hosting for the server-side setup.

REST API

The REST API is at https://your-server/api/v1/. Full OpenAPI spec available at /api/v1/openapi.yaml and documented inline in the REST API reference.

Quick taste:

# List engrams in a scope
curl -H "Authorization: Bearer $TOKEN" \
  "https://plur.your-org.com/api/v1/engrams?scope=group:platform"

# Save an engram
curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"statement":"Deploys must run migrations first.","type":"procedural","scope":"group:platform"}' \
  https://plur.your-org.com/api/v1/engrams

# Recall
curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"deploy migrations","limit":5}' \
  https://plur.your-org.com/api/v1/recall

# Inject for a task
curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"task":"Add a new POST /users endpoint","scope":"group:platform"}' \
  https://plur.your-org.com/api/v1/inject

Every REST endpoint enforces the same permission model as MCP. Same engrams, same audit trail. Use whichever fits your client.

Building a first-party adapter

If you want to ship something more idiomatic — a Go plugin, a Rust agent, a Ruby gem — the recipe is:

1. Pick a transport (stdio MCP for local, HTTP/SSE for remote, REST for non-MCP).
2. Implement the four core flows: inject (before LLM call), learn (after correction), feedback (after task), session (start/end).
3. Add lifecycle hooks if your runtime has them — that’s where the magic lives.
4. Surface the tool names verbatim. Agents trained on PLUR tools expect exact names; don’t rename.

Looking at how @plur-ai/claw (OpenClaw, TypeScript) and plur-hermes (Python) handle the same engine over different runtimes is the cleanest reference. Both are open source.

Webhooks (Enterprise)

If you want PLUR to push at you rather than the other way around, register a webhook in the admin dashboard and PLUR will POST signed payloads on:

• engram.created
• engram.updated
• engram.retired
• pack.installed
• session.ended
• audit.entry

Each delivery carries an X-PLUR-Signature HMAC-SHA256 header for verification. Retries with exponential backoff, auto-disable after persistent failure. See Webhooks.

What you don’t have to build

• Search ranking (BM25 + RRF live server-side).
• Engram schema validation.
• Auth — Enterprise handles OIDC/SAML/GitHub/GitLab/API keys/SCIM for you.
• Permission enforcement — scope checks happen server-side; your client just sends requests.

The custom adapter’s job is mapping your runtime’s lifecycle to PLUR’s calls. Everything else is provided.