fix(server): preserve inputSchema for z.discriminatedUnion / z.union by ankitvirdi4 · Pull Request #2017 · modelcontextprotocol/typescript-sdk

ankitvirdi4 · 2026-05-05T01:18:29Z

Summary

Fixes #1643. registerTool / registerPrompt silently advertised an empty schema in tools/list when given a z.discriminatedUnion(...) or a z.union([z.object(...), ...]). Tool calls still validated correctly via the fallback in validateToolInput, which masked the bug from end-to-end tests.

Repro on `v1.x` HEAD

import * as z from 'zod/v4';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

const server = new McpServer({ name: 't', version: '1' });
server.registerTool('mutate', {
  inputSchema: z.discriminatedUnion('action', [
    z.object({ action: z.literal('create'), name: z.string() }),
    z.object({ action: z.literal('delete'), id: z.string() }),
  ]),
}, async args => ({ content: [{ type: 'text', text: JSON.stringify(args) }] }));

// tools/list returns: inputSchema: { type: 'object', properties: {} }
// branches dropped on the wire.

Root cause

normalizeObjectSchema() (in src/server/zod-compat.ts) returned undefined for any schema whose root was not z.object(...). The tools/list handler then substituted EMPTY_OBJECT_JSON_SCHEMA. The downstream toJsonSchemaCompat already handles unions correctly (zod-to-json-schema for v3, Mini's z.toJSONSchema for v4) but never got called.

Fix

Two surgical changes:

src/server/zod-compat.ts — normalizeObjectSchema() now also passes through:
- v4 schemas with _zod.def.type === 'union' (covers both z.union and z.discriminatedUnion)
- v3 schemas with _def.typeName of ZodDiscriminatedUnion or ZodUnion
Schemas whose root is genuinely non-object (z.string(), z.array(...)) still return undefined, matching prior behavior.
src/server/mcp.ts — wraps the conversion result with a small ensureObjectRoot() helper that defaults type: "object" when the converter omits it. Discriminated unions and unions emit oneOf / anyOf without a root type, but the MCP spec requires tool input/output schemas to describe objects, so we default it on the way out. Plain z.object(...) already sets type: "object", so this is a no-op for the common case. Schemas with an explicit non-object root type are left alone (they fall out as user errors downstream, which is the right signal).

Tests

Three regression tests under "Tools with union and intersection schemas". The file uses describe.each(zodTestMatrix) so each runs once for v3 and once for v4 — six actual cases:

discriminated-union inputSchema is exposed in tools/list with type: "object" + oneOf / anyOf
regular union of objects, same
discriminated-union outputSchema, same, plus end-to-end callTool round trip

Includes a changeset entry.

Test plan

npx vitest run test/server/mcp.test.ts — 238 / 238 passing
npx vitest run (full suite) — 1585 / 1585 passing
npm run typecheck clean
npm run lint clean
Manual end-to-end with the SDK's in-memory transport: tools/list returns the proper schema with branches; valid input round-trips; malformed input returns proper validation error

changeset-bot · 2026-05-05T01:18:36Z

🦋 Changeset detected

Latest commit: 7b808a9

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

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

pkg-pr-new · 2026-05-05T01:19:15Z

Open in StackBlitz

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

commit: 7b808a9

ankitvirdi4 · 2026-05-16T16:13:10Z

gentle bump on this one. happy to rebase against v1.x if its drifted, or rescope to drop the ensureObjectRoot helper if youd prefer the narrower change (just the normalizeObjectSchema pass-through). let me know if anything needs revising and ill turn it around quickly.

joselvelez · 2026-10-01T17:19:36Z

any update on when/if this will get merged?

…odelcontextprotocol#1643) normalizeObjectSchema returned undefined for any schema whose root was not z.object(...), so registerTool silently advertised an empty schema in tools/list when given z.discriminatedUnion(...). Tool calls still validated correctly via the fallback in validateToolInput, which masked the bug from end-to-end tests. Pass discriminated unions and unions through unchanged in normalizeObjectSchema; let toJsonSchemaCompat handle the actual conversion (zod-to-json-schema for v3, Mini's z.toJSONSchema for v4). Both emit oneOf/anyOf branches. Default a top-level type: "object" on the emitted JSON Schema in mcp.ts so the wire payload is spec compliant when the converter does not include one (the discriminated-union and union case). Adds three regression tests under "Tools with union and intersection schemas" exercising tools/list, callTool, and outputSchema for v3 and v4.

ankitvirdi4 · 2026-10-04T11:22:42Z

@felixweinberger quick context since #1643 shows as closed: it was closed by #1796, which fixed this on main (v2, packages/core/src/util/standardSchema.ts). That fix never landed on v1.x. On current v1.x, normalizeObjectSchema still returns undefined for z.discriminatedUnion(...) / z.union(...), so tools/list advertises an empty inputSchema for those tools.

This PR is the v1 backport. It does the same two things #1796 does on main:

lets unions pass through normalizeObjectSchema so the schema actually gets converted
defaults a root type: "object" when missing, so the emitted schema stays spec compliant

re my earlier offer to drop the ensureObjectRoot helper: i'd now recommend keeping it. without it, tools/list throws expected "object" at path tools[0].inputSchema.type because ListToolsResultSchema requires a root object type (details from @mk-imagine on #1643). so the pass-through alone would swap a silent bug for a hard error.

Just rebased onto latest v1.x (single commit, no conflicts). lint, build, and the full suite (1858 tests) pass locally. would appreciate a look when you get a chance.

@joselvelez thanks for the nudge. it's rebased and ready on my side, now waiting on maintainer review. in the meantime you can try it with npm i https://pkg.pr.new/@modelcontextprotocol/sdk@2017.

soorajlegend · 2026-11-06T18:19:20Z

Confirming this in production on 1.29.0: a z.discriminatedUnion inputSchema passed to registerTool was advertised in tools/list as { "type": "object", "properties": {} }, and agents treated the tool as taking no arguments. No error or warning anywhere.

What we do while waiting for this: action is a z.enum, payload is z.record(z.unknown()), the handler validates each action's payload with its own schema, and the per-action fields are listed in the tool description.

One trap for anyone switching to z.union instead: Zod returns the first branch that parses, and object branches strip unknown keys by default. Our move payload also matched the update branch, so status was silently dropped. If this PR makes z.union a supported inputSchema, a docs note that branch order (or .strict() branches) matters might save people some time.

Thanks for working on the v1.x backport.

ankitvirdi4 requested a review from a team as a code owner May 5, 2026 01:18

coderabbitai Bot mentioned this pull request Jul 3, 2026

Stabilize memory context output (roadmap Sprint 1) besfeng23/Memory#123

Merged

ankitvirdi4 force-pushed the fix/1643-discriminated-union-input-schema branch from 0ce5cf5 to 7b808a9 Compare October 4, 2026 11:22

ankitvirdi4 mentioned this pull request Oct 4, 2026

registerTool() silently drops inputSchema for z.discriminatedUnion() — normalizeObjectSchema only passes z.object() #1643

Closed

Navigation Menu

Repository navigation

fix(server): preserve inputSchema for z.discriminatedUnion / z.union - #2017

fix(server): preserve inputSchema for z.discriminatedUnion / z.union#2017
ankitvirdi4 wants to merge 1 commit into
modelcontextprotocol:v1.xfrom
ankitvirdi4:fix/1643-discriminated-union-input-schema

ankitvirdi4 commented May 5, 2026

Uh oh!

changeset-bot Bot commented May 5, 2026 •

edited

Loading

Uh oh!

pkg-pr-new Bot commented May 5, 2026 •

edited

Loading

Uh oh!

ankitvirdi4 commented May 16, 2026

Uh oh!

joselvelez commented Oct 1, 2026

Uh oh!

ankitvirdi4 commented Oct 4, 2026 •

edited

Loading

Uh oh!

soorajlegend commented Nov 6, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

ankitvirdi4 commented May 5, 2026

Summary

Repro on v1.x HEAD

Root cause

Fix

Tests

Test plan

Uh oh!

changeset-bot Bot commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

pkg-pr-new Bot commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ankitvirdi4 commented May 16, 2026

Uh oh!

joselvelez commented Oct 1, 2026

Uh oh!

ankitvirdi4 commented Oct 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

soorajlegend commented Nov 6, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Repro on `v1.x` HEAD

changeset-bot Bot commented May 5, 2026 •

edited

Loading

pkg-pr-new Bot commented May 5, 2026 •

edited

Loading

ankitvirdi4 commented Oct 4, 2026 •

edited

Loading