---
schema_version: 1
slug: first-supabase-mcp
status: source-reviewed
walkthrough_verified: false
content_hash: b508db5f4bdff38c4bd7a7f6f4f8d459e31c6dc0e3382caa0a781f2147c69874
---

# Add an MCP server to an existing Supabase app with Chumbo

Take an existing Supabase application from a generated MCP function to one useful capability you can discover and call.

Take an existing Supabase application from a generated MCP function to one useful capability you can discover and call.

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/docs/reference/getting-started/README.md)
- [Reference implementation](https://github.com/elsheppo/chumbo/blob/main/templates/function/capabilities.ts.tpl)

## 01. Pick a task your app already understands.

A project tracker already knows which projects a person can see. Its first MCP tool can answer “What am I working on?” using that existing behavior. You do not need to expose every table or create a new backend before the connection is useful.

Choose one small read operation first. Write down the intended caller, the fields they need, and one expected result. Chumbo supplies the MCP runtime and generated Edge Function; you supply the application meaning in capabilities.ts.

**The first working path:** Existing Supabase app → Chumbo MCP → A useful tool call

## 02. Inspect the repository, then generate the boundary.

### Before you start

- An existing repository with supabase/config.toml and an application operation you can already describe.
- Node 22 or newer and the Supabase CLI; Deno for generated checks.
- A deliberate access-mode choice and a disposable local fixture for your first capability.

The examples use the function name mcp. Substitute your actual name in paths and commands.

### Inspect without applying setup

```sh
npx chumbo status --json
npx chumbo setup --plan --json
```

Read the plan for the intended function and access mode. If an MCP already exists, inspect its capabilities and configuration before resuming. If this is a new function, run the guided setup and choose who may connect.

### Run guided setup

```sh
npx chumbo setup
```

Setup creates the entrypoint, capability file, Deno configuration and starter tests. The generated whoami tool is a diagnostic starting point. It is not the application feature you are shipping. Keep the generated support files and replace the starter with the small operation you chose.

## 03. Replace the starter with application behavior.

For the project tracker, implement list_projects through the request’s ctx.supabase client and return recognizable names and durable IDs. Use the RLS recipe below for a checked example. Update index_test.ts when replacing the starter so it expects your capability rather than whoami.

### Give your coding agent the package guidance

```sh
npx chumbo skill install
```

Keep setup separate from schema design. A generated function cannot decide whether a project belongs to a user, a team or an organization. Reuse the grants, policies and application APIs that already express that decision.

## 04. Make one real call before adding more tools.

### Check the generated function

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

### Start your local development loop

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

Use the exact Local MCP URL printed by dev. Connect MCP Inspector with an identity from that local project, discover the tool and invoke it. A passing starter test has different meaning by auth mode; it does not prove your new tool or database policies.

### Your first useful MCP is ready for its next tool.

- The intended function initializes and lists your application capability.
- A safe call returns the expected local fixture and only the fields needed for the task.
- Missing or invalid credentials are rejected in authenticated modes; two users cannot borrow each other’s rows.
- Your updated test checks the new capability, and your application code survives a setup resume.

Run these in your application before you call it done.

### If the result differs

#### Setup is incomplete or support files have drifted

Inspect status and use setup --resume --json. Preserve the application-authored capabilities file; deleting it to restore the starter loses the behavior you just built.

[Read the reference](https://github.com/elsheppo/chumbo/blob/main/skills/chumbo/references/start.md)

## 05. Build the next part of the user journey.

Once an agent can reliably find the right project, add the smallest follow-up the task needs. That might be reading a project brief or submitting a draft for review. Choose it from the user’s workflow, then verify the new boundary.

### Keep building

- [Keep your existing permissions](/recipes/supabase-rls-mcp/): Implement a caller-scoped project listing.
- [Choose who can connect](/recipes/choose-mcp-auth/): Match access mode to the caller relationship.

## 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: Take an existing Supabase application from a generated MCP function to one useful capability you can discover and call.

Read the complete guide at https://chumbo.dev/recipes/first-supabase-mcp/recipe.md and the canonical reference at https://github.com/elsheppo/chumbo/blob/main/docs/reference/getting-started/README.md. Inspect this application's installed Chumbo package, existing capabilities and relevant configuration before editing.

Inspect existing Supabase configuration and capability ownership. Preview setup before applying it. Implement one safe application read using established permissions, update the generated tests, and prove discovery plus invocation. Do not treat whoami or HTTP health as the completed application feature.

Prerequisites:
- An existing repository with supabase/config.toml and an application operation you can already describe.
- Node 22 or newer and the Supabase CLI; Deno for generated checks.
- A deliberate access-mode choice and a disposable local fixture for your first capability.

Acceptance:
- The intended function initializes and lists your application capability.
- A safe call returns the expected local fixture and only the fields needed for the task.
- Missing or invalid credentials are rejected in authenticated modes; two users cannot borrow each other’s rows.
- Your updated test checks the new capability, and your application code survives a setup resume.

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


### Handoff report

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