fix: support Zod 3.25 method literals

[mattzcarey]

Fixes #1380.

Uses the existing Zod compatibility helper for client/server request-handler method extraction so literals stored in _zod.def.values[0] are accepted.

Verification:

• npx vitest run test/issues/test_1380_zod325_literal.test.ts
• npm run typecheck
• npm run lint
• npm run build
• git diff --check

[changeset-bot]

⚠️ No Changeset found

Latest commit: f6f6d6b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@modelcontextprotocol/sdk@2368

commit: f6f6d6b

[claude]

LGTM — small, well-scoped consolidation onto the existing zod-compat helper with a regression test for the Zod 3.25 literal shape.

Extended reasoning...

Overview

This PR replaces duplicated inline method-literal extraction logic in Client.setRequestHandler (src/client/index.ts) and Server.setRequestHandler (src/server/index.ts) with the existing getLiteralValue helper from src/server/zod-compat.ts, and adds a regression test (test/issues/test_1380_zod325_literal.test.ts) covering literals stored in _zod.def.values[0] (the Zod 3.25.x v4 shape from issue #1380).

Correctness

getLiteralValue already exists in zod-compat and is a strict superset of the removed inline logic: it checks _zod.def.value, then _zod.def.values[0], then the v3 _def paths, then a direct .value fallback. All values that the old code resolved still resolve identically; the only behavioral change is that the previously-failing values[0] shape is now accepted, which is the intended fix. The downstream typeof methodValue !== 'string' guard is unchanged.

Security risks

None identified. The change affects only how a handler's method name is read from a Zod schema at registration time; it does not touch auth, transport, validation of incoming payloads, or any data exposure paths.

Level of scrutiny

setRequestHandler is a core entry point, but the diff is a mechanical refactor to a shared, already-present helper plus a new test file — no new logic was authored in this PR. The added tests exercise the helper directly and both the Server and Client registration paths.

Other factors

The bug-hunting system found no issues. The PR includes verification of typecheck, lint, build, and the new test. The changeset-bot notes no changeset was added; maintainers may want one if this should trigger a patch release, but that does not affect code correctness.