---
schema_version: 1
slug: deploy-debug-mcp
status: source-reviewed
walkthrough_verified: false
content_hash: 1dba841691d3dc535cf412e32b54f12418d775ddeaafe4886bb20eae393263ed
---

# Test, deploy and debug a Chumbo MCP on Supabase Edge Functions

Move from local checks to an actual MCP call, diagnose the failing boundary and verify the deployed endpoint your users will connect to.

Move from local checks to an actual MCP call, diagnose the failing boundary and verify the deployed endpoint your users will connect to.

Reviewed against the shipped OSS source. The acceptance checks are yours to run in your application.

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.

[Structured recipe](./recipe.json) · [Human-readable page](./)

## Sources

- [Canonical pattern](https://github.com/elsheppo/chumbo/blob/main/skills/chumbo/references/run-deploy-verify.md)
- [Reference implementation](https://github.com/elsheppo/chumbo/blob/main/src/doctor.ts)

## 01. 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.

### Where does the request stop?

Use an observed symptom to choose the next check.

#### Before Chumbo: The gateway rejects the request

Starting point:

```text
The MCP discovery request never reaches the runtime.
```

- Check the deployed function configuration.
- OAuth discovery needs the Chumbo runtime to receive the request.

What to do:

```text
Inspect verify_jwt and run doctor against the actual endpoint.
```

Generated deployments use --no-verify-jwt; Chumbo then handles the selected auth mode.

#### At identity: The endpoint requires a credential

Starting point:

```text
The runtime is reachable but an authenticated call is rejected.
```

- Check token type and expiry.
- Check that credential and endpoint belong to the same project.

What to do:

```text
Retry with a valid test identity for the selected mode.
```

Do not switch to public mode to make an authenticated smoke pass.

#### Inside the tool: The call returns unexpected data

Starting point:

```text
Discovery succeeds but the application result is wrong.
```

- Inspect the query and fixture.
- Check grants, RLS and application authorization.

What to do:

```text
Compare a known allowed fixture and a known denied fixture.
```

HTTP success does not establish the application outcome.

## 02. 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.

### Check and test the current function

```sh
deno task --config supabase/functions/mcp/deno.json check
deno task --config supabase/functions/mcp/deno.json test
```

### Start the local runtime

```sh
supabase start
npx chumbo dev --function mcp
```

Use 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.

## 03. Discover and call one explicitly safe tool.

### Open MCP Inspector

```sh
npx @modelcontextprotocol/inspector
```

Choose 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.

## 04. 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.

### Deploy the selected function

```sh
supabase functions deploy mcp --project-ref "$PROJECT_REF" --no-verify-jwt
```

### Probe the deployed URL

```sh
npx 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.

## 05. Finish with the application outcome.

### The intended endpoint works for the intended caller.

- 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.

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](https://github.com/elsheppo/chumbo/blob/main/skills/chumbo/references/troubleshoot-and-upgrade.md)

### Keep building

- [Keep the contract in your tests](/recipes/test-mcp-capabilities/): Catch protocol and result regressions before deployment.
- [Give users a product URL](/recipes/clean-mcp-url/): Verify the proxy and discovery routes together.

## Instructions for your coding agent

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.

### Required environment inputs

| Variable | Sensitive | Meaning |
| --- | --- | --- |
| `PROJECT_REF` | No | The explicitly authorized hosted project reference. |
| `HOSTED_MCP_URL` | No | The deployed function URL in that same project. |
| `LOCAL_MCP_URL` | No | Exact local endpoint printed by chumbo dev. |
| `MCP_TOKEN` | Yes, never include its value in source or reports | Test credential from the same project as the target endpoint. |

### Handoff report

- Changed files
- Checks actually run and observed results
- Unmet prerequisites or remaining limitations