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.
A healthy endpoint is the beginning of the check.
A function can boot while your project query is wrong. A valid token can reach a capability whose RLS policy returns no rows. Diagnose the narrowest boundary that fails so you do not “fix” a data problem by changing authentication.
The gateway rejects the request
Starting pointThe MCP discovery request never reaches the runtime.
- Check the deployed function configuration.
- OAuth discovery needs the Chumbo runtime to receive the request.
Inspect verify_jwt and run doctor against the actual endpoint.
Generated deployments use --no-verify-jwt; Chumbo then handles the selected auth mode.
The endpoint requires a credential
Starting pointThe runtime is reachable but an authenticated call is rejected.
- Check token type and expiry.
- Check that credential and endpoint belong to the same project.
Retry with a valid test identity for the selected mode.
Do not switch to public mode to make an authenticated smoke pass.
The call returns unexpected data
Starting pointDiscovery succeeds but the application result is wrong.
- Inspect the query and fixture.
- Check grants, RLS and application authorization.
Compare a known allowed fixture and a known denied fixture.
HTTP success does not establish the application outcome.
Use an observed symptom to choose the next check.
Run the local function and its real capability test.
Before you start
- A generated function with its current capability tests.
- Local Supabase and test credentials from the same local project.
- For the deployment step, an explicitly authorized hosted project and reviewed configuration, secrets and migrations.
Commands use mcp as the function name. Keep the local server running in its own terminal.
deno task --config supabase/functions/mcp/deno.json check
deno task --config supabase/functions/mcp/deno.json testsupabase start
npx chumbo dev --function mcpUse the printed local URL, including this project’s configured API port. For static API-key development, use a gitignored environment file and dev’s --env-file option. Hosted secrets are configured separately. Public mode also needs its generated rate-limit migration applied locally.
Discover and call one explicitly safe tool.
npx @modelcontextprotocol/inspectorChoose Streamable HTTP and connect with the correct test credential. Inspect tools/list, then call a read-only capability with a known expected result. Doctor can also call an explicitly named safe tool using --call-tool; inspect its --help for the argument and token options. Avoid printing live credentials into shared diagnostics.
After replacing the starter whoami tool, update the generated test. OAuth and bearer starter tests establish unauthenticated rejection; the public starter proves the handler boots. None of those alone proves your application’s read or write behavior.
Deploy to the project you have reviewed.
Before this step, confirm the project reference, function name, required secrets and migration state. Apply only the hosted changes you intend. The CLI command below deploys the function; it is not a substitute for applying a required database migration or configuring OAuth.
supabase functions deploy mcp --project-ref "$PROJECT_REF" --no-verify-jwtnpx chumbo doctor --function mcp --url "$HOSTED_MCP_URL"Connect the actual client to the deployed Streamable HTTP URL and repeat the safe application call with hosted test credentials. Keep local and hosted results separate in your report.
Finish with the application outcome.
The intended endpoint works for the intended caller.
- 01Generated checks pass for the current capability implementation.
- 02The actual endpoint initializes, advertises the expected tool and returns the known safe result.
- 03Invalid credentials and relevant cross-user access attempts fail.
- 04Required public/state migrations and auth configuration are present where the deployed function expects them.
- 05The client your users will use completes the connection and safe call.
Run these in your application before you call it done.
If the result differs
The endpoint is reachable but the tool is missing
Check the deployed revision, function URL, current identity and any scope gates. Compare discovery under the intended caller; do not assume a different identity should see the same surface. 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: Move from local checks to an actual MCP call, diagnose the failing boundary and verify the deployed endpoint your users will connect to. Read the complete guide at https://chumbo.dev/recipes/deploy-debug-mcp/recipe.md and the canonical reference at https://github.com/elsheppo/chumbo/blob/main/skills/chumbo/references/run-deploy-verify.md. Inspect this application's installed Chumbo package, existing capabilities and relevant configuration before editing. Treat infrastructure, protocol, credentials, data access and client behavior as distinct checks. Run the current generated tests and a safe capability call. Deploy only to the explicitly authorized project, then verify the hosted endpoint with matching credentials. Never call health or a starter test proof of application behavior. Prerequisites: - A generated function with its current capability tests. - Local Supabase and test credentials from the same local project. - For the deployment step, an explicitly authorized hosted project and reviewed configuration, secrets and migrations. Acceptance: - Generated checks pass for the current capability implementation. - The actual endpoint initializes, advertises the expected tool and returns the known safe result. - Invalid credentials and relevant cross-user access attempts fail. - Required public/state migrations and auth configuration are present where the deployed function expects them. - The client your users will use completes the connection and safe call. 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.