Supabase

What it gives Plexward

• Product metrics in briefings: signups this week, active records, queue depth.
• Schema context for sessions working on the entity's platform code, so an agent can check a column before inventing one.
• Migration and advisor visibility when you are operating the project rather than just reading it.

Layer

account. The Supabase connector is attached to your Claude account and sees the organizations and projects that account can reach. Per-entity scoping is by project id, enforced in the routing doc.

{ "name": "Supabase", "layer": "claude.ai", "svc": "Product DB", "account": "acme project" }

Prerequisites

• A Supabase account with access to the entity's project.
• The connector attached on claude.ai.
• The project id, pinned in the entity's brain.

Setup steps

1. Attach the connector on claude.ai and authorize it.
2. Confirm from the brain: claude mcp list | grep -i supabase.
3. Record the project id in the brain's integration patterns file, with a one-line description of what each table the agent will read actually means.
4. Declare it in catalog/declarations.json.

Per-entity routing

## Owned Integrations
| MCP Tool | Service | Account | Notes |
|---|---|---|---|
| Supabase | Product DB | Acme project `<project-id>` | Account layer. Read-only by convention. |

## NOT This Company
- Any other Supabase project on the account.

Read-only by convention. Nothing prevents a write or a migration from an agent session. If the entity's database is production, say in the routing doc that migrations are a human step and keep it true.

Verify

cd ~/brains/acme-brain && claude mcp list | grep -i supabase

Then list the tables for the pinned project and confirm it is the right project, not a sibling.

Common failures

• The wrong project. Organizations with several projects make this easy and silent. Always pass the pinned project id.
• Advisors ignored. Security and performance advisories exist and are worth reading before changing anything; skipping them is how a permissive row-level security policy ships.
• A long query in a briefing loop. Loops have time budgets. Aggregate in SQL, do not pull rows and count them in the agent.
• Self-hosted instances are not the same connector. An entity running its own Supabase stack on its own server is reachable over the network, not through the account-layer connector. Declare it as a service layer entry.

What Plexward does with it once connected

Briefings carry product numbers next to operational ones, so a daily brief can say what the business did as well as what the agents did. Sessions working on the entity's platform read the live schema instead of a stale local copy.