Skip to content

Supabase

Configure Supabase with xmcp middleware and runnable examples.

For the complete documentation index, see llms.txt. Markdown variants of every page are available by appending .md to the URL.

Use existing Supabase Auth access tokens and query your database as the authenticated user. @xmcp-dev/supabase verifies every HTTP request and provides an isolated Supabase client for row-level security (RLS).

src/middleware.ts

Use a publishable key or a legacy anon key. Secret and service_role keys are rejected. Send Authorization: Bearer <supabase-access-token> on every request, including initialize and discovery. The plugin checks the token with the configured project's Auth server using getUser(token); it never trusts a decoded session alone. Missing or invalid tokens receive HTTP 401 and a Bearer challenge. Authentication failures cannot fall back to anonymous access.

src/tools/my-notes.ts

The request client sends the verified user's token for database queries. It disables persistent sessions and token refresh. getSupabaseUser() returns the verified user; both helpers throw outside the active request. User data is never recovered from an earlier stateless HTTP request.

Enable RLS and write policies such as auth.uid() = user_id. The plugin preserves the user token; it does not create policies or grant table access for you. See Supabase RLS guidance.

This integration targets the standalone HTTP transport and Express middleware adapters. It does not implement an OAuth authorization server, refresh clients' tokens, or supply HTTP authentication for STDIO or Fetch-only adapters. Configure clients that already have a Supabase access token; use your existing sign-in flow to obtain and renew it.

The runnable example includes a notes table, RLS policy, and instructions for testing two users.

One framework to rule them all