fix(core): allow additional JSON Schema properties in elicitInput requestedSchema#1768
fix(core): allow additional JSON Schema properties in elicitInput requestedSchema#1768felixweinberger wants to merge 1 commit intomainfrom
Conversation
…uestedSchema Adds .catchall(z.unknown()) to requestedSchema, matching the pattern used by inputSchema/outputSchema (SEP-1613). Fixes type incompatibility when using Zod v4's .toJSONSchema() output which includes extra properties like $schema and additionalProperties. Fixes #1362
🦋 Changeset detectedLatest commit: 9f455cd The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — consistent with the existing inputSchema/outputSchema pattern.
Extended reasoning...
Overview
This PR adds .catchall(z.unknown()) to the requestedSchema Zod object inside ElicitRequestFormParamsSchema in packages/core/src/types/schemas.ts. It also adds a regression test and a changeset file. Total change is ~30 lines across 3 files.
Security risks
None. The change only loosens Zod validation to accept additional unknown keys on the requestedSchema object (e.g. $schema, additionalProperties). These extra keys are already accepted on inputSchema and outputSchema via the same .catchall(z.unknown()) pattern. No auth, crypto, or permission logic is affected.
Level of scrutiny
Low scrutiny warranted. This is a one-line schema fix that aligns requestedSchema with the existing pattern used by inputSchema (line 1314) and outputSchema (line 1326) in the same file. The fix is mechanical and the test directly validates the scenario described in issue #1362.
Other factors
The PR author asks a maintainer whether .catchall(z.unknown()) is the right approach. However, since this exact pattern is already established for inputSchema and outputSchema, consistency strongly favors this approach. A regression test is included. The changeset is properly scoped as a patch.
1 participant
Adds
.catchall(z.unknown())torequestedSchema, matchinginputSchema/outputSchema(SEP-1613 / #1135).Motivation and Context
z.toJSONSchema()emits$schema,additionalProperties, etc. The SDK'srequestedSchemarejected these. The spec's own schema.ts allows$schema, so the SDK was stricter than spec.Fixes #1362
How Has This Been Tested?
Regression test in
types.test.ts— verified fails without fix, passes with.Breaking Changes
None.
Types of changes
Checklist
Additional context
Supersedes #1511, #1561, #1688, #1694 — thanks @Dave-London and @travisbreaks for the earlier work.
@KKonstantinov — is
.catchall(z.unknown())right here, or should we only add the spec-listed keys?