feat(mcp): add branch cost confirmation elicitation

[barryroodt]

Stacked on #391. Review that first. This is part of AI-1091.

What kind of change does this PR introduce?

Feature: add form-mode cost confirmation to create_branch.

What is the current behavior?

#391 provides the shared confirmation codec/verifier, ServerContext, result passthrough, and project flow. Branch creation still uses the existing hash validation.

What is the new behavior?

Modern form clients can call create_branch without confirm_cost_id. They receive an action-only, property-less prompt for $0.01344/hr (about $9.68 over 30 days).

Acceptance creates the branch from signed arguments. Missing responses and changed costs re-prompt. A wrong-tool state or changed arguments fail. Decline and cancel create no branch.

Capability-free and URL-only clients keep hash validation. A supplied legacy ID cannot bypass the capable-client flow. Project-scoped injection works, and existing output fields such as with_data remain.

How to Review

1. Server and shared state

   • packages/mcp-server-supabase/src/server.ts
   • packages/mcp-server-supabase/src/tools/cost-confirmation.ts

2. Branch handler and pricing

   • packages/mcp-server-supabase/src/tools/branching-tools.ts
   • packages/mcp-server-supabase/src/pricing.ts

3. Behavioral coverage

   • packages/mcp-server-supabase/src/server.test.ts
   • Inspect the capable, legacy, argument-binding, and project-scoped paths.

• Is create_branch enabled only through the intended server path?
• Does the discriminated state bind project ID, branch name, and BranchCost?
• Do capable clients always use elicitation, even with a legacy ID?
• Do accept, decline, cancellation, wrong-tool, and argument-change outcomes look correct?

Verification

• pnpm --filter @supabase/mcp-server-supabase test src/server.test.ts -t "create_(project|branch) cost confirmation via elicitation" (17 passed)
• pnpm --filter @supabase/mcp-server-supabase build (typecheck + build passed)
• pnpm test:packed-platform-consumer (3 assertions passed)
• pnpm exec biome ci . (passed)

Additional context

Commit 24535f1 chore: refresh management API types adds two generated lines to packages/mcp-server-supabase/src/management-api/types.ts because the CI generation gate detected upstream schema drift. Feature behavior and verification remain unchanged.

This does not change create_project, mcp-utils, platform adapters, stdio, pricing values, manifests, or docs.

Known limits: confirmations are not single-use, legacy IDs remain precomputable, and the branch rate remains the existing package constant.

AI-assisted; human review required.

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/@supabase/mcp-server-postgrest@6b363bb

pnpm add https://pkg.pr.new/@supabase/mcp-server-supabase@6b363bb

pnpm add https://pkg.pr.new/@supabase/mcp-utils@6b363bb

commit: 6b363bb

[coveralls]

Coverage Report for CI Build 33730957759

Warning

No base build found for commit f9831db on feat/hosted-project-cost-elicitation.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 96.466%

Details

• Patch coverage: 2 uncovered changes across 1 file (126 of 128 lines covered, 98.44%).

Uncovered Changes

File	Changed	Covered	%
packages/mcp-server-supabase/src/tools/branching-tools.ts	111	109	98.2%
Total (3 files)	128	126	98.44%

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	3375
Covered Lines:	3273
Line Coverage:	96.98%
Relevant Branches:	473
Covered Branches:	439
Branch Coverage:	92.81%
Branches in Coverage %:	Yes
Coverage Strength:	58.11 hits per line

---

💛 - Coveralls

[Rodriguespn]

This does read as #391 with the branch flow swapped in, and I can confirm the fixes from my earlier review all carried over (safe defaults on the elicitation action, drift check below decline/cancel, and the suffix driven off cost.recurrence rather than hardcoded).

Ran the elicitation suite locally (21 passing) plus a few probes of my own for the paths the suite doesn't cover, both cross-tool state and the single-tool enabledTools configs. Both behave correctly; I've left inline comments suggesting tests for them, plus a couple of small type/pricing notes. Nothing blocking.

One thing worth adding to the description: replay is better contained here than for projects. preview_branches has a real UNIQUE (project_id, branch_name) constraint (migration), so a replayed branch confirmation fails at the DB rather than relying on the read-then-check that covers create_project. Same known limit, weaker consequence.

[mattrossman]

Could you explain if there is a path to test this with our stdio server?

I see here we don't populate costConfirmation on the stdio server. I'd think we want elicitations on stdio too, particularly because that's the workflow in local development to test the MCP package standalone w/ a real client. Is that something we can tie in to make verification easier?

+   costConfirmation: {
+      requestStateKey: randomBytes(32),
+      principal: 'local-stdio-user',
+      enabledTools: ['create_project', 'create_branch'],
+    },

I initially expected that old clients would continue to work the same as they have been with the old cost confirmation tools, and that new clients would use elicitations, regardless of transport. But from what I can tell, populating costConfirmation changes the tool schemas without consideration for elicitation support. I suppose for that to work, we'd need the tool signatures to vary based on capabilities, maybe by passing the SDK-provided context through into getTools() so it can see them on ctx.mcpReq.envelope.

[barryroodt]

Could you explain if there is a path to test this with our stdio server?

I see here we don't populate costConfirmation on the stdio server. I'd think we want elicitations on stdio too, particularly because that's the workflow in local development to test the MCP package standalone w/ a real client. Is that something we can tie in to make verification easier?

+   costConfirmation: {
+      requestStateKey: randomBytes(32),
+      principal: 'local-stdio-user',
+      enabledTools: ['create_project', 'create_branch'],
+    },

I initially expected that old clients would continue to work the same as they have been with the old cost confirmation tools, and that new clients would use elicitations, regardless of transport. But from what I can tell, populating costConfirmation changes the tool schemas without consideration for elicitation support. I suppose for that to work, we'd need the tool signatures to vary based on capabilities, maybe by passing the SDK-provided context through into getTools() so it can see them on ctx.mcpReq.envelope.

Apologies for the confusion here - after numerous chats with @gregnr the decision was taken not to add elicitation support to stdio (due to it being deprecated). To do a full e2e test for elicitations you'll need to run the mcp server via the platform setup (PR #37722) - i'll update the linked Linear ticket with a detailed runbook on how to get that setup and running.

Thanks for taking the time to look at this.

[mattrossman]

Tested this by fusing changes from #402 onto the branch locally to connect to Claude Code launched w/ the modern protocol flags:

MCP_SDK_GENERATION=v2 MCP_PROTOCOL_NEGOTIATION=auto claude

This was my first time seeing elicitations working in Claude which was cool :) It was working as expected. Would love to get the HTTP dev server in so future stuff stays low lift to test.

Left a couple minor comments about test coverage opportunities. The Claude Code elicitation UI design is questionable w/ how it truncates info, but that's not something we have a lot control over and who knows how it'll change over time. Leaving it to you how you want to address the remaining feedback.

Noting this PR will partially address #285, in that the unavailable cost confirmation tools aren't needed w/ elicitations 🙌