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.
Make the account behind the agent clear.
A user connecting your project tracker should recognize the same app and account they already use. They begin in an MCP client, sign in to your app and approve the connection. Later tool calls carry a Supabase access token for that user, so caller-scoped database queries can use the existing grants and RLS.
Chumbo handles the MCP-facing authentication boundary and discovery. Supabase Auth issues the credentials. Your application owns the sign-in and consent experience, including the explanation of what a user is approving.
Configure the complete connection path.
Before you start
- A Chumbo function configured for OAuth and a Supabase application with working sign-in.
- An application-owned authorization/consent page and access to the intended project’s OAuth Server settings.
- An OAuth-capable MCP client and two test users with distinguishable application data.
Use the canonical OAuth reference and the current settings of your own Supabase project. A local bearer-token test does not verify hosted OAuth.
In the intended Supabase project, enable OAuth Server and configure its authorization UI URL. Use the linked consent example to understand the required application behavior, then adapt it to your existing sign-in and product language. Inspect the requested authorization details and let the user approve or deny the request.
If your target client uses dynamic client registration, enable and verify that path in Supabase Auth. Registration lets the client obtain its own OAuth client identity. It does not add an “AI connections” settings page to your frontend or write the application’s consent copy.
Connect to the actual function URL.
The endpoint is the Streamable HTTP function URL. Do not add /sse. Verify that URL before trying to diagnose a client’s browser flow. If you use a custom application URL, its metadata suffix paths must reach the same runtime.
npx chumbo doctor --url "$MCP_URL"In an OAuth-capable client, add that endpoint and complete its sign-in flow. For Claude Code, the canonical connection command is below; open /mcp in Claude Code to complete authorization when needed. Check current client support rather than assuming every host handles every auth mode.
claude mcp add --transport http my-app "$MCP_URL"Check consent and the resulting data access.
The connected account is the acting account.
- 01A new connection reaches your intended sign-in and consent UI, and denying consent does not grant access.
- 02Approving as the first user permits discovery and a safe tool call with that user’s expected rows.
- 03A separately connected second user receives only their own expected rows.
- 04Invalid or missing credentials fail at the authenticated MCP boundary.
- 05Your chosen client completes its own connection and reconnect behavior; a raw token call alone is insufficient evidence.
Run these in your application before you call it done.
If the result differs
Sign-in works but the client cannot finish connecting
Inspect protected-resource metadata, OAuth Server configuration, the authorization UI URL and the client’s registration requirements. Run doctor against the exact public URL. If that URL is proxied, verify its suffix routes as well as the base endpoint. Read the reference ↗
Give the connection a useful first task.
After sign-in, let the user try a safe request with a recognizable answer, such as listing their projects. That confirms both the connection and its purpose. Add a frontend connection-management experience only when your product needs one; the OSS runtime does not ship a ready-made settings page.
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: Give users a sign-in and consent path to your Supabase MCP, then verify the account and permissions behind a real tool call. Read the complete guide at https://chumbo.dev/recipes/oauth-user-connections/recipe.md and the canonical reference at https://github.com/elsheppo/chumbo/blob/main/docs/reference/connect-clients/README.md. Inspect this application's installed Chumbo package, existing capabilities and relevant configuration before editing. Inspect OAuth runtime configuration, Supabase OAuth Server settings and application-owned consent handling. DCR belongs to the authorization server/client integration. Verify the actual chosen client with approve/deny and two accounts. Do not present a bearer smoke as proof of OAuth or claim a generated frontend connections page. Prerequisites: - A Chumbo function configured for OAuth and a Supabase application with working sign-in. - An application-owned authorization/consent page and access to the intended project’s OAuth Server settings. - An OAuth-capable MCP client and two test users with distinguishable application data. Acceptance: - A new connection reaches your intended sign-in and consent UI, and denying consent does not grant access. - Approving as the first user permits discovery and a safe tool call with that user’s expected rows. - A separately connected second user receives only their own expected rows. - Invalid or missing credentials fail at the authenticated MCP boundary. - Your chosen client completes its own connection and reconnect behavior; a raw token call alone is insufficient evidence. 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.