-
Notifications
You must be signed in to change notification settings - Fork 1.8k
fix(server): handle ZodEffects in normalizeObjectSchema and getObjectShape #1865
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
pch007
wants to merge
1
commit into
modelcontextprotocol:v1.x
Choose a base branch
from
pch007:fix/zod-effects-normalize-object-schema
base: v1.x
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+246
−0
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| --- | ||
| '@modelcontextprotocol/sdk': patch | ||
| --- | ||
|
|
||
| Handle ZodEffects wrappers (`.superRefine()`, `.refine()`, `.transform()`) in `normalizeObjectSchema()` and `getObjectShape()`. Previously, schemas wrapped with these methods would fall back to `EMPTY_OBJECT_JSON_SCHEMA` in `tools/list` responses because `normalizeObjectSchema()` | ||
| only checked for `.shape` (v3) or `_zod.def.shape` (v4), which ZodEffects/pipe types lack. The fix walks through the wrapper chain to find the inner ZodObject, ensuring correct JSON Schema generation for tool listings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔴 The v4 pipe traversal in both
getObjectShapeandnormalizeObjectSchemaonly walks one level deep, so any Zod v4 schema with two or more chained.transform()calls (e.g.z.object({x: z.string()}).transform(fn1).transform(fn2)) will still fall back toEMPTY_OBJECT_JSON_SCHEMAintools/listafter this PR. This is asymmetric with the v3 path, which usesunwrapZodEffects()to walk up to 10 levels; the fix is to add an analogous loop for v4 that walks_zod.def.inchains.Extended reasoning...
What the bug is and how it manifests
In Zod v4, each call to
.transform()creates aZodPipewhose_zod.def.inpoints to the previous schema. Chaining two transforms therefore produces a nested pipe structure: the outer pipe'sdef.inis another pipe, not aZodObject. BothgetObjectShape(lines 139-143) andnormalizeObjectSchema(lines 221-227) only check one level into that chain, so they silently fail for any schema with two or more chained transforms in Zod v4.The specific code path that triggers it
In
getObjectShape, the fix is:If
def.inis itself a pipe (the double-transform case),inner._zod?.def?.shapeisundefinedbecause pipes have no.shape, sorawShapestaysundefinedand the function returnsundefined.In
normalizeObjectSchema:For a double-transform schema,
innerDef.type === 'pipe'(not'object'), so the guard fails andnormalizeObjectSchemareturnsundefined, causingtools/listto emitEMPTY_OBJECT_JSON_SCHEMA.Why existing code doesn't prevent it
The PR adds a test titled 'should list correct JSON Schema for nested ZodEffects chains', but that test uses
.superRefine().transform()— not.transform().transform(). In Zod v4,.superRefine()mutates the object schema in place (the type stays'object'), so asuperRefine+transformchain only creates a single-level pipe whosedef.inIS the object. The test passes, but the double-transform gap is never exercised.Impact
Any MCP tool registered with a Zod v4 schema that chains two or more
.transform()calls — a valid and common pattern — will advertise an empty input schema to clients. Clients cannot know what parameters the tool accepts, breaking auto-completion, validation, and documentation generation.Additionally,
getObjectShapeis called directly bypromptArgumentsFromSchema(and the completions handler) without going throughnormalizeObjectSchemafirst, so prompt argument listings are also broken for such schemas.Step-by-step proof
const s = z.object({ x: z.string() }).transform(v => v).transform(v => v)s._zod.def = { type: 'pipe', in: { _zod: { def: { type: 'pipe', in: <ZodObject>, ... } } }, ... }normalizeObjectSchema(s): enters the v4 branch,def.type === 'pipe'→ true,def.in→ inner pipe.innerDef.type === 'pipe'→ the guardinnerDef.type === 'object'is false,innerDef.shapeisundefined→ returnsundefined.getObjectShape(s):rawShape = v4Schema._zod?.def?.shape→undefined(pipe has no shape). Theninner = def.in= inner pipe;inner._zod?.def?.shape→undefined→ returnsundefined.tools/listemitsEMPTY_OBJECT_JSON_SCHEMAfor the tool.How to fix it
Add a loop analogous to
unwrapZodEffectsthat walks_zod.def.inchains for v4 pipes (up to a depth bound of 10), and use it in bothgetObjectShapeandnormalizeObjectSchema:Then replace the single-level checks with a call to this helper.