Plugin catalogue

Almost everything the gateway does at the edges is a plugin: every backend that a tool dispatches to, every identity provider, every policy engine, every transform, and every telemetry sink loads as a signed plugin. The gateway core owns sessions, governance orchestration, and dispatch; the plugins own the integrations.

This page is the catalogue of the plugins that ship with MCPG — first-party, built and signed by the project, published as OCI artifacts under ghcr.io/mcpg-dev/source-code/plugins/. You load one by listing it under plugins[] with a source, and reference it from a binding's backend.kind (for backends) or by its governance role.

How plugins are identified

Every plugin declares a reverse-DNS id and a class. The id convention is dev.mcpg.<category>.<name>; a handful of older plugins use a bare dev.mcpg.<name> (noted in the tables). The class is a fixed taxonomy the gateway uses to decide where in the request lifecycle the plugin runs:

A plugin's signature.policy (disabled / warn / enforce) controls trust on load — use enforce in production. See Plugin security for the signing and trust model.

plugins:
  - id: dev.mcpg.policy.cedar
    source:
      oci: "ghcr.io/mcpg-dev/source-code/plugins/policy-cedar:1.0.0"
    signature:
      policy: enforce

Backends

A binding selects a backend with backend.kind. The non-LLM backends:

The kafka and nats backend crates also register a watch plugin (dev.mcpg.watch.kafka_topic, dev.mcpg.watch.nats_topic, class WatchStrategy) so resource bindings can stream topic updates.

LLM backends

The LLM backends expose one backend.kind per modality. All kinds use underscores (openai_chat, never openai.chat):

That's 27 backend kinds total (10 non-LLM incl. the built-in pipeline, plus 17 LLM kinds). Every kind and its config keys are in the configuration reference.

Identity providers

Resolve the caller. Built-in OIDC JWT verification lives in governance.access; these plugins add the other credential types under plugins[] (class IdentityProvider).

Policy engines

Authorize a resolved caller against a tool (class PolicyEngine). Declare one under governance.policy.engine[] and load it under plugins[].

Tool-gates

Run in the pre-dispatch gate chain (class ToolGate) — each can allow, deny, or challenge a call before it reaches a backend.

Payment

Meter and charge tool usage (class ToolGate). One per billing protocol:

Transforms

Rewrite arguments or results in the pipeline (class Transform).

Credentials & secrets

Mint upstream credentials for cred:// references (CredentialIssuer) and resolve secrets from external stores (SecretProvider).

Observability

Audit, metrics, traces, and logs fan out to sinks. stderr / stdout / file log sinks and the local-file audit sink are built into the gateway; these plugins add the external destinations.

Audit is a governance concern, not an observability sink — see Audit trail. The built-in dev.mcpg.builtin.audit.local-file sink writes the hash-chained ledger; off-node audit sinks load as their own plugins.

Infrastructure

Cross-instance coordination, response caching, and content stores.

Single-node clustering is built in; set cluster.kind to one of the above for HA — see Clustering.

A note on id conventions

Most ids follow dev.mcpg.<category>.<name>, but several predate the convention and use a bare dev.mcpg.<name>: dev.mcpg.rate-limit, dev.mcpg.circuit-breaker, dev.mcpg.response-cache, dev.mcpg.audit, dev.mcpg.call-logger, dev.mcpg.guardrails, dev.mcpg.ip-allowlist, dev.mcpg.webhook, and dev.mcpg.tool-gate-slack-approval. Use the exact id shown above — the gateway matches on it verbatim.