PostgREST MCP Server

What it does

Supabase's PostgREST server gives an assistant a single route into a database that sits behind a PostgREST API: a Supabase project's /rest/v1 endpoint, or a standalone PostgREST install. Rather than holding a database connection, it sends ordinary HTTP requests to that API, so what it can see and change is whatever the API key you give it is allowed to do under the database's row-level security.

It has two tools. One sends a request (GET, POST, PUT, PATCH or DELETE) to a path on the configured API and hands back the JSON reply, including the changed rows for writes. The other turns a SQL query into the matching PostgREST method and path, using Supabase's sql-to-rest library, so the assistant can write SQL and then run it as a REST call.

Beyond the README: the code also exposes the API's OpenAPI description as a resource (postgrest:///spec), which lets a client learn the tables and columns, and the request tool accepts PUT, which the README's method list leaves out. Every request carries the header Prefer: return=representation, so writes return the affected rows (src/server.ts). The --schema flag is required as well as --apiUrl: the program exits at start without either (src/stdio.ts).

This is a separate, smaller server from Supabase's main MCP server, which manages Supabase projects and runs SQL; this one only speaks to an app's public REST API.

What it needs

Node.js with npx. A reachable PostgREST endpoint: a Supabase project's REST URL (https://<project-ref>.supabase.co/rest/v1, or http://127.0.0.1:54321/rest/v1 for local Supabase) or a self-hosted PostgREST server. Usually an API key for it (Supabase anon key, service role key or a user JWT). The schema you name must be exposed by PostgREST.

Limits

Reaches only what PostgREST exposes: tables, views and functions in exposed schemas, filtered by row-level security for the key used. Non-public schemas must be exposed in PostgREST by hand first. sqlToRest handles only the subset of SQL that PostgREST can express; joins, DDL and many other statements will not convert. Works over stdio only from the command line; no hosted endpoint. One schema per server instance, set at launch.

Who it suits

Suits developers who want an assistant to read and edit their app's data through the same REST API and row-level security their users go through, for example with the anon key or a user's JWT, and who also run plain PostgREST outside Supabase. Pick Supabase's main MCP server instead when you need to manage projects, run arbitrary SQL, apply migrations or read logs; that one works through the Supabase management account, this one only needs an API URL and key.