chore: prepare update to the stateless protocol

[raulb]

What kind of change does this PR introduce?

Start updating to the stateless Protocol https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

Part of https://linear.app/supabase/issue/AI-894/spike-estimate-work-to-support-the-2026-07-28-mcp-spec

Migrates the three published packages from the v1 monolithic @modelcontextprotocol/sdk to the v2 beta SDK (@modelcontextprotocol/server + @modelcontextprotocol/client, 2.0.0-beta.2), which implements the 2026-07-28 spec:

• @supabase/mcp-utils
• @supabase/mcp-server-supabase
• @supabase/mcp-server-postgrest

What is the current behavior?

Packages depend on @modelcontextprotocol/sdk@^1.25.2 (pre-2026-07-28). mcp-utils registers handlers against Zod schemas via the low-level Server

What is the new behavior?

Packages build and pass on the v2 beta.

Additional context

• Mechanical migration. v2 keeps the low-level Server + Transport API we rely on.
• v1→v2 delta: a stdio server exiting mid-init now throws 'Connection closed' instead of 'MCP error -32000'.
• SDK-package upgrade only . It doesn't yet enable the new protocol at any HTTP host (MRTR / stateless serving come next, in mgmt-api). Versions pinned exactly (beta).

[coveralls]

Coverage Report for CI Build 29822337775

Coverage remained the same at 96.336%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	2888
Covered Lines:	2803
Line Coverage:	97.06%
Relevant Branches:	360
Covered Branches:	326
Branch Coverage:	90.56%
Branches in Coverage %:	Yes
Coverage Strength:	47.18 hits per line

---

💛 - Coveralls

[barryroodt]

Following up on the next steps you left in the catchup notes while you're out, I went ahead with the regression-check half of the ship-strategy question.

Pushed two commits: a merge of latest main plus one small test fix. Plain push, no force, your commits are untouched.

The merge was textually clean, but #334 (hide tools) landed on main with one semantic break against this branch. Its new src/tools/util.test.ts imports from the v1 monolithic SDK (@modelcontextprotocol/sdk/client/index.js, .../types.js), which this branch removes, so typecheck fails right after merging. Looks like a simple timing overlap between the two PRs: the file just needed porting to the @modelcontextprotocol/client package and its typed callTool result, matching the pattern you already used in server.test.ts (+4/-7).

Results on the merged branch:

• Build green across all three packages (ESM/CJS/DTS)
• mcp-utils 12/12, mcp-server-supabase 193/198 locally, including the ported util.test.ts and the 110-test server.test.ts covering the hide-tools behavior on the v2 SDK
• The 5 local failures are the LLM e2e tests missing ANTHROPIC_API_KEY, which CI supplies
• The postgrest suite was not rerun locally because it needs the local Supabase stack at :54321. Worth knowing: CI's test:coverage only runs mcp-server-supabase, so the postgrest tests are not exercised in CI either. You had them green pre-merge and the merge only touched postgrest via lockfile, but a local supabase start run before undrafting would close that gap.

Two more small things I noticed along the way:

• The failing check job is not this branch. The management API spec drifted upstream after main's last sync (some id fields removed from the SAML provider types), so regenerating types produces a diff on any PR right now. I verified by regenerating locally against the live spec. That fix belongs to the type-sync workflow on main, so I left it out of this branch.
• The PR description says 2.0.0-beta.2 but the branch now pins 2.0.0-beta.3 (both client and server in the catalog). Just flagging so the handoff records the right version, might be worth a one-word edit to the description.

None of this blocks anything, it just answers the regression half of your open question. From what I can see the SDK swap behaves identically on top of latest main, so merging this independently looks safe once CI confirms the e2e runs. We still want the merge-vs-rebase call and undrafting to be your deliberate call rather than something decided while you're away, so I'll leave it here. Very open to redoing this as a rebase instead if you prefer that history 🙂