Marketplace authoring

Integrations are manifests, not code — until you want custom tools.

Three tiers

Paste-a-key — vendor MCP server URL + bearer token. Tools appear on their own via the MCP bridge. Zero per-tool code.
OAuth via manifest — declare authorize/token URLs and setup fields; the generic flow handles start, callback, refresh, and per-user accounts.
Custom tools — hand-written functions with schemas, policy verdicts, secret redaction, and mock fallbacks (the Google tier).

Manifest anatomy (`plugins/<id>/manifest.yaml`)

id: zoom
name: Zoom
accounts: multi
auth:
  kind: oauth2            # or: mcp
  authorize_url: https://zoom.us/oauth/authorize
  token_url: https://zoom.us/oauth/token
  token_auth: basic       # or: body
  scopes: []
setup_fields:             # per-user values (client id/secret…)
  - key: client_id
secret_fields: []         # per-account secrets (tokens, URLs)
tools: []                 # tool names this plugin owns
write_tools: []           # subset needing approval

Shared vs per-user credentials

A server env app (e.g. one Google Cloud client) covers everyone; users with their own app can override per-user via setup fields. Either way, each person's tokens are stored per account, encrypted at rest, and tools always act as the chatting user.

Grants

Default-allow: every agent gets every plugin until you turn it off for that agent, per bot. Bots drive install/connect/accounts themselves through cards — secrets never pass through the model.

MCP bridge

Reviewed catalogue servers become gateway-governed tools. Catalogue reads stay reads; unknown or custom MCP tools are treated as writes and need approval.