Skip to content

feat(mcp): migrate to TypeScript SDK v2#1356

Open
mattzcarey wants to merge 1 commit into
supermemoryai:mainfrom
mattzcarey:chore/mcp-sdk-v2
Open

feat(mcp): migrate to TypeScript SDK v2#1356
mattzcarey wants to merge 1 commit into
supermemoryai:mainfrom
mattzcarey:chore/mcp-sdk-v2

Conversation

@mattzcarey

@mattzcarey mattzcarey commented Jul 24, 2026

Copy link
Copy Markdown

Summary

Migrate the Supermemory MCP Worker from the v1 @modelcontextprotocol/sdk +
agents/mcp Durable Object runtime to the split MCP TypeScript SDK v2 packages,
currently 2.0.0-beta.5.

The HTTP design follows the request-local, stateless handler used by
cloudflare/mcp:

  • serve modern MCP 2026-07-28 with createMcpHandler();
  • retain the SDK's stateless 2025 compatibility path for published clients;
  • construct a fresh authenticated McpServer per HTTP request;
  • remove protocol session state, the Agents runtime, and the MCP Durable Object;
  • preserve API-key/OAuth auth, x-sm-project scoping, tools, resources, prompts,
    PostHog attribution, and the Memory Graph MCP App.

Runtime changes

  • Replace McpAgent/SupermemoryMCP.serve() with an SDK v2 server factory.
  • Keep /mcp exact-routed and authenticated before MCP dispatch.
  • Echo browser preflight request headers so Mcp-Method, Mcp-Name, and dynamic
    Mcp-Param-* headers work without maintaining a fixed CORS list.
  • Return sessionId: null from whoAmI because the v2 HTTP transport is
    intentionally stateless.
  • Fetch project lists on demand rather than retaining request-crossing cache state.
  • Delete the obsolete SupermemoryMCP Durable Object class through a Wrangler v2
    migration. Its stored data was limited to client identity and a project-list cache;
    memories remain in the Supermemory API.

Important

Deploying the deleted_classes migration is one-way: Wrangler cannot roll back across
that migration boundary. An emergency revert requires a new forward migration, and the
disposable client-identity/project-cache DO data will remain deleted.

Zod v4 migration

SDK v2 requires Zod v4. To avoid mixed schema identities, this PR upgrades every
workspace declaration to ^4.4.3 and adds a root ^4.4.3 override. All JavaScript
lockfiles now resolve exactly one Zod version: 4.4.3.

Related migrations:

  • zod-openapi 4 → 6 and .openapi() → native Zod v4 .meta();
  • one-argument z.record(value)z.record(z.string(), value);
  • transformed/default schema values updated for v4 output semantics;
  • Zod adapters (@hono/zod-validator, drizzle-zod, hono-openapi) and the
    atmn CLI moved to current v4-compatible releases;
  • CI now fails if the dependency graph or any JavaScript lockfile reintroduces a
    second Zod version.

MCP Apps note

@modelcontextprotocol/ext-apps@1.7.5 has not published its SDK-v2 migration yet
(upstream work). It remains
a browser-build-only dev dependency with its v1 peer. The server-side App tool/resource
metadata is registered directly on the v2 McpServer, and a Wrangler metafile check
confirms neither @modelcontextprotocol/sdk nor agents/mcp enters the Worker runtime.

Validation

  • bun install --frozen-lockfile
  • bun run check:zodSingle Zod resolution: 4.4.3
  • bun test packages/validation/api.test.ts → 11 passed
  • bunx vitest run packages/tools/src/tools-shared.test.ts packages/tools/src/tool-operations.test.ts → 21 passed
  • bunx turbo run check-types --filter='@supermemory/ai-sdk' --filter='@supermemory/memory-graph' → passed
  • cd apps/mcp && bun run check → typecheck, UI build, 16 protocol/unit tests passed
  • cd apps/mcp && bunx vitest run e2e/auth.test.ts → 4 public deployed-server auth tests passed
  • cd packages/memory-graph && bunx vitest run → 195 passed
  • cd apps/mcp && bunx wrangler deploy --dry-run --minify → successful,
    1536.19 KiB raw / 401.18 KiB gzip
  • Wrangler metafile audit → v2 server/core + Zod v4 only; no v1 SDK or Agents runtime

Authenticated memory e2e suites remain opt-in and skip without
SUPERMEMORY_API_KEY, as before.

apps/web is not typecheck-clean on current main (125 existing diagnostics), so it
cannot be added to the CI typecheck filter in this PR. A manual compile showed no
Zod-specific diagnostics after the migration; shared API/validation modules compile
standalone, and their v4 default/record/OpenAPI behavior is covered by the new tests.

Automated review

Reviewed read-only with claude-fable-5 at low effort after opening the draft:
no P0-P2 findings; ready for human review. Its remaining P3 notes were the
one-way Durable Object migration warning documented above, the pre-existing web
verification boundary, and optional future subscription support for this intentionally
stateless authenticated handler.

@socket-security

Copy link
Copy Markdown

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action Severity Alert  (click "▶" to expand/collapse)
Warn High
Obfuscated code: npm powershell-utils is 90.0% likely obfuscated

Confidence: 0.90

Location: Package overview

From: ?npm/atmn@1.1.15npm/powershell-utils@0.2.0

ℹ Read more on: This package | This alert | What is obfuscated code?

Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev.

Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code.

Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/powershell-utils@0.2.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

@mattzcarey
mattzcarey marked this pull request as ready for review July 24, 2026 15:02
@mattzcarey

Copy link
Copy Markdown
Author

Note this isn't using the agents sdk. We can get rid of a bunch of code if we do but it's not released yet. Will be Monday so feel free to wait or merge as you feel like it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant