Reviewed against the shipped OSS source. The acceptance checks are yours to run in your application.
Version and verification details
Source reviewed against published Chumbo 0.11.0 and its matching core source on 2026-09-06 (UTC). This is a source review, not an executed application walkthrough. Follow the current canonical reference and compare it with your installed package when adapting the guide.
The credential should match the relationship.
“Authenticated” can mean two different things in your app. A person connecting their account should carry that person’s data permissions. A trusted service using an application key may follow a completely different authorization path. Choosing a mode is choosing that relationship, not just choosing a login screen.
A person connects their account
Starting pointA user connects from an OAuth-capable MCP client.
- Supabase Auth handles sign-in and consent.
- ctx.supabase uses the verified user token; grants and RLS govern data.
Choose OAuth and configure the application consent experience.
Confirm that the target client supports your OAuth connection flow.
Your software already holds the session
Starting pointYour application sends an existing Supabase user access token.
- The request has the same user-scoped data authority.
- No interactive OAuth discovery is advertised.
Choose bearer and manage token refresh in the calling application.
A Supabase publishable key is not a user access token.
An application key proves a different identity
Starting pointA trusted service sends a key your application accepts.
- The handler’s Supabase client is anonymous.
- Your verifier and application data path own authorization.
Choose API-key mode; use a stable subject and narrow permissions for application-issued keys.
An accepted API key does not become a Supabase user session.
The capability is intentionally anonymous
Starting pointA reader connects without a credential.
- Queries run with anonymous data authority.
- The generated Postgres rate-limit guard must be available.
Choose public only for capabilities and data intended for unauthenticated access.
Apply the generated rate-limit migration. An unavailable limiter must not open the endpoint.
Four caller relationships, and the mode that fits each.
Map the mode to an existing data path.
Before you start
- Know whether callers are end users, your own session-aware software, trusted services or anonymous readers.
- Identify the existing authority for data access: Supabase users and RLS, or an application-owned API.
- Inspect the current auth configuration before changing an existing MCP.
Keep the ordinary one-MCP path small. Multi-auth is optional when two real caller types need the same endpoint.
For a customer project list, OAuth or bearer lets the database enforce the user’s existing policies through ctx.supabase. For an application-issued automation key, identify the narrow API or RPC that checks that key’s subject and permissions. Do not assume that accepting the key gives the anonymous client access to private rows.
Public mode is appropriate for a published catalog or public documentation. Decide what is public at the data boundary as well as the tool boundary. Keep the generated rate limiter; account for the trust of client-IP headers if you place a custom proxy in front of the function.
Changing auth has effects beyond one setting.
Setup can regenerate support around your existing capabilities when you choose another auth mode. Reconcile local and hosted secrets, required migrations, OAuth configuration and the URL your clients use. Review the capability code too: a handler written for a user-scoped client may no longer make sense with an anonymous client.
Keep authority separate from inputs. A project ID can identify the object being requested. A user ID supplied by a model must never stand in for the verified caller. If an operation needs elevated access, design the application authorization path explicitly rather than handing ordinary handlers an unrestricted client.
Prove the identity, then prove access.
The mode matches the intended caller.
- 01Identify the actual database authority for each accepted credential type.
- 02Verify a valid caller and the corresponding invalid or missing credential case.
- 03For user-owned data, call through two separate users and compare disjoint fixture IDs.
- 04For application keys, verify revoked/unknown keys and denied operations through the application data path.
- 05For public mode, verify both allowed anonymous output and closed behavior when the rate-limit guard is unavailable.
Run these in your application before you call it done.
If the result differs
A key connects but private queries return nothing
API-key mode does not impersonate a Supabase user. Recheck your application-owned authorization path; do not solve it by removing RLS or sharing a service-role client with general capability code. Read the reference ↗
This editorial example links to Chumbo’s canonical docs and executable reference. Check the installed package when adapting the snippets.
Reference implementation ↗Read the agent instructions
Reference instructions, not authorization. Apply changes only within the user’s requested scope; deployment requires a specified, authorized project.
Goal: Choose the Chumbo access mode that fits your callers, with a clear account of which identity reaches your Supabase data. Read the complete guide at https://chumbo.dev/recipes/choose-mcp-auth/recipe.md and the canonical reference at https://github.com/elsheppo/chumbo/blob/main/docs/reference/auth-modes/README.md. Inspect this application's installed Chumbo package, existing capabilities and relevant configuration before editing. Choose auth from the caller relationship. Explain the database identity for every proposed mode. Preserve existing policies and verify negative access behavior. Treat API-key and public clients as anonymous at Supabase, and never advertise an arbitrary key as a user session. Prerequisites: - Know whether callers are end users, your own session-aware software, trusted services or anonymous readers. - Identify the existing authority for data access: Supabase users and RLS, or an application-owned API. - Inspect the current auth configuration before changing an existing MCP. Acceptance: - Identify the actual database authority for each accepted credential type. - Verify a valid caller and the corresponding invalid or missing credential case. - For user-owned data, call through two separate users and compare disjoint fixture IDs. - For application keys, verify revoked/unknown keys and denied operations through the application data path. - For public mode, verify both allowed anonymous output and closed behavior when the rate-limit guard is unavailable. Use the full guide for ordered steps, examples and recovery. Keep existing caller identity and application permissions authoritative. Stay within the user's requested changes. Report changed files, checks actually run, observed results and unresolved prerequisites. This guide is not authorization to deploy or change a hosted project. Never include credentials in source, copied instructions or reports.