Supabase

DESTRUCTIVE — apply named, versioned DDL to a preview BRANCH's database. THIS IS THE ONLY PATH TO A SCHEMA CHANGE IN THIS CONNECTOR. It takes a BRANCH ID, never a project ref: Agentic Fabriq asks Supabase for that branch's own database ref and applies the migration there, so there is no argument that could name the production project. The workflow the permission model assumes is: create a branch, apply the migration here, review it with supabase_get_branch_diff, and promote it with supabase_merge_branch — which is a SEPARATE grant. Always supply `rollback`: Supabase stores it as the migration's undo, and without it the change has no recorded reverse.

DESTRUCTIVE — replace the metadata of several edge functions in one call. Supabase treats the list you send as the new state, so a function you leave out of an entry you do send is a field you have cleared. Call supabase_list_functions IMMEDIATELY BEFORE this and send back the entries it gave you with only the fields you meant to change edited — that read is the only source of the `id`, `status` and `version` each entry requires, and it is also the only copy of what you are overwriting. This changes metadata, not code: supabase_deploy_function replaces a function's source.

Cancel an in-flight resume of a paused project.

Ask whether a vanity subdomain is free. A POST at the provider and a pure read: it reserves nothing and activates nothing.

Create a preview branch on one project. This provisions a SEPARATE database and leaves the parent project untouched, which is why it is not destructive — and it is the first step of the only schema-change workflow this connector supports. Branches bill by the hour, so delete them when done. Requires branching on the organization's plan; check supabase_get_organization_entitlements.

Create a named restore point on this project. Additive and non- destructive: it records a moment, it does not change data. This is the PRECONDITION that makes a risky write bounded — take one before supabase_execute_write or supabase_merge_branch, and the customer has a named moment to recover to. Requires point-in-time recovery on the organization's plan; check supabase_get_organization_entitlements.

DESTRUCTIVE — delete ALL preview branches on a project at once. The parent project is untouched, but every branch's database and any work held only on it is gone. Requires `confirm: true`; without it the call is refused before any request leaves Agentic Fabriq. List the branches first and say how many you are about to remove.

DESTRUCTIVE — delete one preview branch and the separate database behind it. The PARENT PROJECT IS UNTOUCHED: the loss is bounded to whatever was only ever on the branch, which is what makes this shippable where deleting a project is not. Branches bill by the hour, so never being able to clean one up is its own cost. Refuses anything that is not a branch id.

DESTRUCTIVE — remove an edge function. Every caller of its URL starts getting a 404 immediately. It IS recoverable, and only because supabase_get_function_body exists: fetch the source first and supabase_deploy_function puts it back under the same slug. Doing this without fetching the body first is the one-way door.

DESTRUCTIVE AND PERMANENT — delete a Supabase project. The database, every row in it, every storage object, every edge function and every backup go with it, and NOTHING in Agentic Fabriq or Supabase brings them back. There is no paused state, no recycle bin and no undo; supabase_pause_project is the reversible action and it is what almost every request for this one actually means. Requires the projects:destroy permission, which is granted to nobody by default, AND the project's own reference repeated in `confirm`. Read supabase_get_project and say out loud which project and which organization you are about to destroy before calling this.

DESTRUCTIVE — deploy an edge function, REPLACING whatever code is currently running under that slug. Agentic Fabriq cannot restore the previous version: call supabase_get_function_body FIRST if you want to be able to put it back. `verify_jwt` defaults to true and should stay true — setting it false publishes an endpoint anyone on the internet can invoke without authentication, on the customer's own project.

Lift Supabase's automatic read-only mode for a short window so space can be freed. NOT destructive and not permanent: Supabase re-applies read-only mode when the window ends or the disk fills again. The recovery step that pairs with supabase_get_project_readonly_status.

DESTRUCTIVE — run one INSERT, UPDATE or DELETE against a project's Postgres database with the project owner's privileges. A statement that runs cannot be undone through Agentic Fabriq. THREE separate things must be true for this to work: this action granted to the agent, `allow_writes` enabled on the Supabase connection itself, and the statement passing the guardrails. There is no read_only argument — reading is supabase_run_read_query, a different grant. Schema changes (CREATE, DROP, ALTER, TRUNCATE, SELECT INTO), privilege changes, MERGE, COPY and the auth/vault/pgsodium schemas are refused here in every mode; schema changes go through supabase_apply_migration against a branch.

Generate TypeScript type definitions for the project's schema. A complete, machine-readable description of every table and column without running a single query.

Supabase's own lints for a project: tables exposed through the Data API without row-level security, functions with a mutable search_path, missing indexes, unused indexes. For a control layer this is the most valuable read Supabase offers — it is the one thing an agent can do about a project's security posture without changing anything. Run it after any migration. Supabase marks both advisor endpoints `deprecated` in the live spec; they still answer, and the replacement has not been published.

API request counts for this project, bucketed over time. Answers 'is something hammering this project' before the bill does.

The total API request count for this project over the current billing window.

How often this project is backed up and how long backups are kept. Both are plan-gated, so this is also the honest answer to 'can we recover from yesterday'.

The paid add-ons on this project — compute size, point-in-time recovery, custom domain, IPv4. What the customer is being charged for, and what recovery options they actually have. Read-only: changing an add-on spends the customer's money and is permanently excluded.

Get one branch's configuration and status, including the branch's OWN project ref — which is what supabase_apply_migration requires and what distinguishes a branch from the production project.

Get one branch action run with its per-step status.

The logs of one branch action run — the actual error when a branch migration failed, rather than the status word.

Look one branch up by its name rather than its id.

Return the SQL diff between a branch's schema and its parent project's. THIS IS THE MANDATORY REVIEW STEP BEFORE supabase_merge_branch: merging applies exactly this to the production database. Read it, and say what it contains, before promoting anything. Beta endpoint.

The custom domain configured for this project's API and its verification state. Read-only: creating, activating and deleting a custom hostname change the DNS identity of the customer's API on the public internet and are not exposed.

The OpenAPI description PostgREST generates for this project — every table, view and database function the Data API exposes, with its columns and types. The cheapest complete schema read there is.

Whether this project's disk grows automatically, and within what limits. Determines whether filling the disk is an outage or a bill.

The project's disk type, size and throughput. Read-only: resizing a disk is a billed change.

How full this project's disk is. The direct cause of Supabase putting a project into read-only mode, so read it alongside supabase_get_project_readonly_status.

Get one edge function's metadata — status, version, entrypoint, whether it verifies a JWT, when it was last updated. Does not return the source; supabase_get_function_body does.

Return the SOURCE of a deployed edge function. THIS IS THE READ THAT MAKES A DEPLOY RECOVERABLE: supabase_deploy_function replaces the running code and Agentic Fabriq cannot restore the previous version, so fetch the body first and you hold the only copy of what you are about to overwrite. Pure GET; changes nothing.

Invocation counts, error rates and execution times for this project's edge functions. The diagnostic that pairs with supabase_deploy_function: it is how you find out the deploy made things worse.

Whether just-in-time database access is enabled for this project and how it is configured. Read-only: granting, inviting and revoking JIT access are all deliberately not exposed — they decide which HUMANS can reach the production database.

Whether this project's temporary database access window is currently open, and whether the last change to it was applied successfully. Different from supabase_get_jit_access_config, which returns the settings rather than the live state — read both when investigating why someone can or cannot reach the database right now. Marked Beta by Supabase. Read-only: opening the window is not exposed.

Get one JWT signing key's metadata and public JWK. Public material only, as with the list.

Query this project's logs — API, Postgres, auth, storage and edge function logs in one stream. Debugging the function you just deployed or the query that just failed. Takes a SQL-shaped `sql` filter in Supabase's log dialect (ClickHouse on projects created since June 2026, BigQuery on older ones), so start without one and narrow. Rate limited to about 30 requests/minute, and retention is plan-gated: 1 day on Free, 90 days on Enterprise. LOGS CARRY REQUEST-LEVEL INFORMATION ABOUT THE CUSTOMER'S OWN END USERS.

Get one applied migration by version, including the SQL it ran. The review step before supabase_update_migration, and the way to see what a previous migration actually did.

Which CIDR ranges may reach this project's database. A wide-open range here is the single most consequential misconfiguration in a Supabase project. Read-only: changing it is not exposed, because the failure mode of a mistaken call is silently opening a production database to the internet.

Get one organization by slug, including its plan and opt-in tags.

List what this organization's plan actually includes — branching, point-in-time recovery, log drains, custom domains, read replicas, SSO. CHECK THIS FIRST before offering a branching or backup workflow: a surface the organization's plan does not include will fail at Supabase with an error that does not name the plan.

One organization webhook delivery in full.

Get one organization webhook endpoint's configuration.

The legacy PgBouncer pooler configuration, for projects still on it.

The Supavisor connection pooler's settings and connection strings (without the password). Answers 'why am I running out of connections'.

The project's Postgres server settings — work_mem, connection limits, statement timeout, logging. Read-only; the matching PUT is not exposed.

Which schemas the project's Data API exposes, the maximum rows it returns and its extra search path. A SECURITY POSTURE READ: a schema listed here is reachable from the internet with the project's publishable key, subject only to row-level security.

Get the Supabase account this connection authenticates as — id, username, primary email. Answers 'whose permissions am I actually using', which is the first question of any access review.

Get one project by reference, including its region, status and organization. This returns the project RECORD's status; for whether the services are actually up, use supabase_get_project_health.

Per-service health for one project — database, auth, rest, realtime, storage. 'Is the project up, and which service is down' is the first question of every incident, and supabase_get_project cannot answer it: that returns the project record's status, not the services'.

This project's metrics in Prometheus exposition format — CPU, memory, disk, connection counts. The numbers behind 'the database feels slow'.

Whether Supabase has put this project's database into read-only mode — which it does automatically when disk is nearly full. The diagnostic for 'every write is failing and nothing changed'.

The status of resuming a paused project. Read this before and after supabase_restore_project; resuming is not instant.

The v2 API's consolidated view of a project's service configuration. Marked Alpha by Supabase and may change shape without notice; prefer the specific config reads where one exists.

Whether this project can be upgraded to a newer Postgres version, and what would block it. Read-only: performing the upgrade is not exposed.

The status of an in-flight or completed Postgres upgrade on this project.

One webhook delivery in full, including the response the destination returned.

Get one project webhook endpoint's configuration, including its destination URL and which events it subscribes to.

The Realtime service's configuration for this project — connection limits, channel limits, whether database change broadcasting is on. Read-only; neither the PATCH nor the shutdown endpoint is exposed.

Get one saved SQL snippet including its content.

Whether this project requires TLS on database connections. Read- only: the PUT that changes it is the customer's own perimeter decision and is not exposed.

Get one SAML SSO provider's configuration.

The storage service's limits for this project — maximum file size, whether image transformation is enabled. Read-only; the matching PATCH is not exposed.

Get one third-party authentication integration's configuration.

The vanity subdomain configured for this project. Read-only, for the same reason as the custom hostname.

List the regions a project or branch can be created in. The read that makes supabase_create_branch's `region` argument obtainable rather than guessed.

List the action runs — clone, migrate, seed, deploy — that Supabase executed for this project's branches, newest first. 'Why is my branch stuck in RUNNING_MIGRATIONS' starts here.

List one project's preview branches. A branch is a separate database provisioned alongside the project. Each row carries the branch's own `id` (for the branch tools) and its own project ref (for supabase_apply_migration).

List this project's backups and whether point-in-time recovery is available. READ THIS BEFORE ANY WRITE you cannot undo: it is the only way to know what recovering from a mistake would actually cost. Performing a restore is deliberately not exposed — a restore destroys every write since the restore point.

List one project's edge functions, with each function's slug, status, version and whether it verifies a JWT on invocation. Call this before supabase_deploy_function: deploying to an existing slug REPLACES the running code.

List the people currently holding just-in-time access to this project's database, with each grant's role and expiry. The access review that matters most, because these are direct Postgres credentials rather than dashboard permissions.

List this project's JWT signing keys — id, algorithm, status and PUBLIC key material only. Supabase's API returns no private key on this path, which is what makes it a posture read rather than a credential: 'which key is in use, is an old one still valid'. Creating, rotating and deleting signing keys are permanently excluded — the private key would let the holder forge a token for any end user of the customer's application.

List the log drains configured on this project — where this project's logs are being shipped, and to whom. READ-ONLY BY DESIGN: creating a log drain sends the customer's logs to a URL of the caller's choosing and keeps doing it after the agent stops, so creation is permanently excluded. Listing them is an exfiltration- detection read.

List the migration versions already applied to this project's database, newest last. An agent asked to change data needs to know what schema it is looking at, and this is the honest alternative to letting it introspect by running DDL.

List the IP addresses Supabase has banned from this project for repeated authentication failures. A POST at the provider, but a pure read: it retrieves, it does not ban. The diagnostic for 'our application server suddenly cannot connect'. Lifting a ban is not exposed.

List the IP addresses Supabase has banned from this project, together with which of the project's databases each ban applies to. A POST at the provider, but a pure read: it retrieves, it does not ban. Prefer this over supabase_list_network_bans when the project has read replicas, because a ban that only affects one database looks identical in the plain list. Marked Beta by Supabase. Lifting a ban is not exposed.

List the GitHub repositories connected to this organization's projects. Tells you whether a branch is driven by a git branch, which changes what merging it means.

List the people who can reach this organization's projects, with each member's role. The access-review read: 'who can see this database'. Returns names and email addresses of the customer's own staff.

List the projects belonging to one organization. Narrower than supabase_list_projects, which spans every organization the connection can see.

List the roles this organization defines, so a member's role string from supabase_list_organization_members can be interpreted. Read- only; assigning a role is not exposed.

The delivery history of one organization webhook endpoint.

List the webhook endpoints configured at the ORGANIZATION level — where this organization's events are being sent. Read-only for the same reason as the project ones.

List the Supabase organizations this connection can see, with each organization's id and name. Organizations own projects; use supabase_list_projects to get the project refs every other Supabase tool needs.

The delivery history of one project webhook endpoint — what was sent, when, and whether it succeeded. The diagnostic for 'our integration stopped receiving events'.

List the webhook endpoints configured on this project — where this project's events are being sent. READ-ONLY BY DESIGN: creating one ships the customer's project events to a URL the caller chose and keeps working after the agent stops, so creation is permanently excluded. Listing them is how you DETECT that.

List projects with their id (the 20-character project ref every other Supabase tool needs), organization, name, region and status.

List the named restore points on this project.

List the SQL snippets saved in the Supabase dashboard, with their name, owner and visibility. The queries the customer's own team already trusts — useful as a starting point rather than inventing SQL.

List the SAML SSO providers configured for this project's end users. Read-only: creating or changing one decides who may sign in to the customer's application, which is not an agent's decision to make.

List one project's storage buckets, including whether each is public. Lists the buckets only; does not read, write or delete the files inside them.

List the third-party authentication providers (Firebase, Auth0, Cognito) this project accepts tokens from. Each one is another issuer whose tokens are trusted by the customer's database, so enumerating them is a posture read. Read-only.

DESTRUCTIVE — apply a branch's SCHEMA CHANGES TO THE PRODUCTION database. This is DDL against production, reached through the one door that records it as a named, versioned migration. READ supabase_get_branch_diff FIRST and state what it contains: merging applies exactly that. A separate permission from creating branches, on purpose. Requires branching on the organization's plan.

DESTRUCTIVE — pause a project. Every client of the customer's application loses its database immediately and stays down until someone resumes it. It is REVERSIBLE: supabase_restore_project is the inverse and ships alongside this. Pausing does not delete data. On the free plan a project left paused long enough can have its data removed by Supabase, so check the organization's plan first.

Check whether a project could be transferred to another organization, and what it would cost or break. Returns `valid` plus three lists — errors, warnings and info — naming things like entitlements the receiving organization does not have. A POST, but it changes nothing: this is the read that makes supabase_transfer_project a decision rather than a gamble, and it needs only projects:read. Run it and report what it says before asking anyone to approve a transfer.

DESTRUCTIVE — run the parent project's newer migrations against the branch, bringing the branch forward. Changes the branch's schema, not production's.

DESTRUCTIVE — reset a branch's database back to its migrations, discarding everything in it. The branch's own data is gone; production is untouched. This is the branch workflow's undo, which is why it ships in the same migration as merge and push.

DESTRUCTIVE — restart the project's services. Every open database connection is dropped and the project is briefly unavailable. Nothing is deleted and the project comes back on its own, so the loss is bounded to the outage; it is marked destructive because the customer's live users feel it.

Bring a branch's database back up after it was taken down. Restores the BRANCH, never the parent project, and destroys nothing — the recovery half of the branch lifecycle.

DESTRUCTIVE — roll the production database back to a physical backup. EVERY WRITE MADE AFTER THAT BACKUP IS DESTROYED, including writes made by people and systems that have nothing to do with this agent, and the amount lost is decided entirely by which backup id you pass. Call supabase_list_database_backups first, state the backup's `inserted_at` timestamp and how much time that discards, and only then confirm. The project is unavailable while it restores. There is no inverse: supabase_create_restore_point taken BEFORE the restore is the only thing that makes this reversible.

DESTRUCTIVE — roll the production database back to an arbitrary second. EVERY WRITE MADE AFTER THAT MOMENT IS DESTROYED. This is the sharpest operation in the connector: the loss is bounded only by a timestamp, so an off-by-one in the unit or the timezone is an off-by-hours in data. The value is UNIX SECONDS, not milliseconds. Point-in-time recovery is a paid add-on; supabase_get_organization_entitlements says whether the organization has it, and supabase_list_database_backups returns the earliest and latest instants that are actually recoverable. There is no inverse.

Resume a paused project — the inverse of supabase_pause_project, and the reason pausing is a bounded action rather than a one-way door. Not the same thing as restoring a BACKUP, which Agentic Fabriq does not expose: this brings a paused project back with its data intact and destroys nothing.

DESTRUCTIVE — roll back every migration at or after a version on a preview BRANCH and remove them from its migration history. THE INVERSE OF supabase_apply_migration, and it takes a BRANCH ID for the same reason: Agentic Fabriq resolves that branch's own database ref, so no argument here can name the production project. `gte` is a FLOOR, not a single version — passing the oldest version you meant to undo also undoes every migration applied after it. Call supabase_list_migrations first and say which versions will go. Whether the data those migrations created survives depends on the rollback SQL recorded with each one, which supabase_get_migration shows you.

Run one read-only SQL statement against a project's Postgres database. Sent to Supabase's OWN read-only endpoint, which executes it as the supabase_read_only_user Postgres role — the database itself refuses a write, not just Agentic Fabriq. SELECT and UNION only; there is no read_only argument to turn off. EXPLAIN is allowed (EXPLAIN ANALYZE is not, because it executes the statement). The auth, vault and pgsodium schemas are refused: they hold your end users' credentials and your secrets for other systems. Results are capped — `max_rows` defaults to 1000 and the response says whether the cap was hit. Data changes go through supabase_execute_write; schema changes through supabase_apply_migration against a branch.

Search and page through one organization's projects by name. Prefer this over supabase_list_organization_projects on any organization large enough that the full list is unwieldy: it filters by a case-insensitive substring of the project name, caps the page at a size you choose, and returns a cursor to continue from. Each project comes back with its ref, status, cloud provider and region.

DESTRUCTIVE — hand this project, its database and its billing to a DIFFERENT organization. Agentic Fabriq cannot reverse it and neither can the sender: transferring it back requires someone in the RECEIVING organization to agree, and if this connection loses access to the project at the same moment then nobody reachable from here can even ask. Members of the current organization may lose access instantly. Run supabase_preview_project_transfer first — it is a pure read, it reports the errors and warnings this call would hit, and it needs only projects:read.

DESTRUCTIVE — roll the production database back to a named restore point. EVERY WRITE MADE AFTER THAT POINT IS DESTROYED. This is the narrowest of the three rollbacks and the only one whose target a person deliberately created: supabase_list_restore_points names them and supabase_create_restore_point makes new ones. Taking a fresh restore point immediately BEFORE calling this is what makes the rollback itself reversible; nothing else does.

Rename a branch or change whether it is persistent. Does not touch the branch's data or schema.

Set the reported status of one or more stages of a branch action run — clone, pull, health, configure, migrate, seed, deploy. Use it to clear a run that is stuck reporting RUNNING and blocking its branch. It re-runs nothing, changes no schema and touches no data: it only changes what supabase_get_branch_action reports. NEVER use it to mark a stage that failed as anything other than failed — the run log from supabase_get_branch_action_logs is the record of what happened, and a status that disagrees with it will mislead the next person to look.

DESTRUCTIVE — change a deployed edge function's name, source or JWT verification without a full deploy. Overwrites what is running; read supabase_get_function_body first. Turning `verify_jwt` off publishes an unauthenticated endpoint on the customer's project.

DESTRUCTIVE — amend a migration's recorded SQL on a preview BRANCH. Takes a BRANCH ID and never a project ref, exactly as supabase_apply_migration. Read the current record with supabase_get_migration first; this overwrites it.

DESTRUCTIVE — change the Supavisor connection pooler's mode or size.pool_mode is the consequential one: moving from session to transactionmode breaks every client that relies on a connection keeping state —prepared statements, LISTEN/NOTIFY, session-level SET, advisory locks —and those clients fail at their next query rather than at this call, sothe damage surfaces somewhere else. default_pool_size caps how manydatabase connections the pooler opens, so a value above the database'smax_connections starves everything that connects directly. Readsupabase_get_pooler_config first; writing its values back is the undo.Requires a confirmation phrase.

DESTRUCTIVE — change Postgres server parameters on the project's database:work_mem, statement_timeout, max_connections, the log_* family and therest of what supabase_get_postgres_config reads back. Read that FIRST andrecord the current values — writing them back is the only undo, andAgentic Fabriq keeps no copy. Several parameters take effect only after arestart, and passing restart_database=true restarts the databaseimmediately, dropping every open connection. session_replication_role isrefused by name whatever value is asked for: setting it to replicadisables every trigger and foreign-key check for all future connections,which is a silent data-integrity change no read would reveal. Requires aconfirmation phrase.

DESTRUCTIVE — change which schemas the project's PUBLIC REST API exposes,and how many rows it will return. db_schema is the consequential one: itis the list of Postgres schemas PostgREST serves athttps://<ref>.supabase.co/rest/v1, so removing a schema breaks everydeployed client that reads from it, and ADDING one publishes its tables toanyone holding the project's anon key. The auth, vault and pgsodiumschemas are refused by name in either argument — vault.decrypted_secretsalone would publish the customer's other systems' credentials, alreadydecrypted, on the public internet. Read supabase_get_postgrest_configfirst; writing its values back is the undo. Requires a confirmationphrase.

Rename a project. This is the whole operation — Supabase's update body carries a name and nothing else, so this cannot resize compute, change a plan or spend money. It is reversible: read the current name with supabase_get_project first and you can put it back. The project's 20-character ref never changes, so nothing that references the project breaks.

DESTRUCTIVE — turn the database's TLS requirement on or off. Turning it ONimmediately rejects every client connecting without TLS, which is ahardening change that can still take an application down. Turning it OFFpermits unencrypted connections to the customer's production database fromthat moment on and is almost never the right answer; if an applicationcannot connect, the fix is its client configuration, not this.supabase_get_ssl_enforcement reads the current setting and is the undo.Requires a confirmation phrase.

DESTRUCTIVE — upgrade the project's Postgres MAJOR VERSION. The databaseis unavailable for the duration and Supabase publishes no downgrade: oncethe upgrade completes, the only route back to the old major version isrestoring a backup taken before it, which loses every write made since.Call supabase_get_project_upgrade_eligibility first — it names theversions this project may target and the reasons it may not be eligible —and supabase_create_restore_point before, so there is something to go backto. Progress is readable with supabase_get_project_upgrade_status.Requires a confirmation phrase.

DESTRUCTIVE — write an entry into a preview BRANCH's migration history without executing its SQL. This is a history repair tool, not a way to change a schema: use supabase_apply_migration for that. It is marked destructive because recording a migration Supabase never ran makes the history disagree with the database, and the next real migration will then skip work it needed to do — a failure that shows up later, somewhere else, as missing columns rather than as an error here. Takes a BRANCH ID and never a project ref, exactly as supabase_apply_migration. Read supabase_list_migrations first.

Re-check the DNS records for a custom hostname that is ALREADY configuredon this project, and report what Supabase's certificate authoritycurrently sees. This changes nothing: it publishes no hostname, activatesnothing, and takes no arguments beyond the project — the hostname itchecks is whichever one a person already set in the Supabase dashboard. Itis the diagnostic for the common failure, which is a CNAME or TXT recordthat was never added or was added to the wrong zone, and it answers withthe same status field supabase_get_custom_hostname_config reads.