feat: local supabase stack

[gregnr]

WIP.

This allows you to connect MCP to your local Supabase stack. The platform abstraction work simplified what was required to make this possible.

We use the /api/platform API shims in the studio container to implement the majority of this. Some tools will not be possible locally, like account level operations and branching, so we need to add logic to conditionally omit those tools instead of throwing a not implemented exception. this will be possible once #103 is merged.

The biggest unknowns right now are migration and edge function tools, since both of these require access to the supabase CLI to implement correctly. For the initial version we can probably omit edge functions. Migrations we should implement in studio /api/platform though.

Ref: AI-101

[diksipav]

Hello, I'll start working on this tomorrow.

[diksipav]

Hey @gregnr should #103 be merged before this PR gets finalised? I rebased this draft branch locally on upstream/main and I will merge the 103 branch into this draft branch and then will update/continue local-platform and what else is needed.

@gregnr should tool getProject be available for "local platforms"? It is the only part of the Account Tools that is available. I understood we want to either provide the whole set of specific tools or none per platform. So I'm unsure what is the best to do here.

export type AccountOperations = {
  listOrganizations(): Promise<Pick<Organization, 'id' | 'name'>[]>;
  getOrganization(organizationId: string): Promise<Organization>;
  listProjects(): Promise<Project[]>;
  getProject(projectId: string): Promise<Project>;
  createProject(options: CreateProjectOptions): Promise<Project>;
  pauseProject(projectId: string): Promise<void>;
  restoreProject(projectId: string): Promise<void>;
};

When u say: "Migrations we should implement in studio /api/platform though." I believe we need to implement this in another repo(UI/Studio) and request that from supabase-mcp?

EDIT: I used the local DB server run in Docker and the local version of MCP server and I can confirm that it works for the things that are implemented under "local-platform" (migrations and edge-functions not implemented). And I guess storage also doesn't work for local DBs since it is cloud-hosted.

[gregnr]

Hey @diksipav, thanks for diving into this and sorry for the delay. You're right, #103 needs to be merged first - your plan to branch off that for now works great.

should tool getProject be available for "local platforms"?

For now, I don't see this being extremely useful since there will only ever be the one project. There is definitely an argument to pull get_project out of account tools in general, but I think this can happen later and doesn't need to be a blocker for self hosted.

I believe we need to implement this in another repo(UI/Studio) and request that from supabase-mcp?

Yeah that's right. Let me discuss with the team on the best place to put this and I'll follow up.

[JoshuaRileyDev]

I've literally been trying to work out how I can implement this as I use coolify atm to host my supabase instances

[madhavpujara-at]

Team any timelime available for this feature

[nthtrung09it]

waiting ...

[Sp4Rx]

waiting ⏳🫠

[madhavpujara-at]

PR #103 is merged now any updated status for this feature??

[gregnr]

We've decided to embed the MCP server directly into the local/self-hosted studio container via API endpoint (streamable HTTP transport) rather than implementing it here in the stdio transport. This means you will eventually be able to connect to local Supabase MCP using, e.g. http://127.0.0.1:54321/mcp.

Closing this PR in favour of this one on the studio project: supabase/supabase#38797