fix(server): prioritize zod issues and format them by mozmo15 · Pull Request #1503 · modelcontextprotocol/typescript-sdk

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 · 2026-02-09T12:52:58Z

By default, when a parse fails, the output message now prioritizes zod issues by formatting each issue as a line with its message and associated path. This is in line with zod's prettify and the current approach on main branch

Motivation and Context

Currently, when a parse against an input or output schema fails, the default value error.message that is used is unclear and bloated. In addition, with zod4, we cannot assume that error.message will have all the zod issues aggregated properly under it. Reference this for more details:
#1415

How Has This Been Tested?

I built the package and tested it in my mcp-based project by sending tool call requests that will fail, the output is a set of lines each representing a zod-issue, with custom messages appearing clearly. For example:

Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root

Breaking Changes

There should not be any breaking changes. If some mcp-client implementations are making assumptions about error output for InvalidParams 32602 errors and running special logic based on that, they may run into issues. But I would not think that its the case since the error output format was previously also prone to vary.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

changeset-bot · 2026-02-09T12:53:09Z

🦋 Changeset detected

Latest commit: cb0fa43

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-02-09T12:53:45Z

Open in StackBlitz

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

commit: cb0fa43

mozmo15 · 2026-02-09T13:57:49Z

One thing to clarify in this PR is how strict and detailed do we want to be about path formatting? For issues with array schemas there will be an index (number) in the path array, and zod additionally handles symbols as well as somehow { key: string | number | symbol } types, which would do not seem common to me. But handling numbers is probably worthwhile using something like:

const dotPath = i.path.reduce((acc, seg, index) => {
if (typeof seg === "number") return `${acc}[${seg}]`;
index === 0 ? `${seg}` : `${acc}.${seg}`;
}, '');

felixweinberger · 2026-03-27T12:13:50Z

@claude review

mozmo15 · 2026-03-30T15:35:02Z

@felixweinberger I added a small helper function which uses reduce to address numeric indeces. Now error outputs should follow:
Invalid input: expected string, received undefined at path personalData.dateOfBirth
Invalid country of birth at path personalData.countryOfBirth <--- custom error
Unrecognized key: "termAndConditions" at object root
Invalid input: expected object recieved undefined at expenses[0].personal

@claude review

Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger

Thanks for this!

Ported functional changes from upstream v1.x (17 commits behind, v1.28.0 through v1.29.0+). Only retained-fork-surface changes applied; auth, HTTP, and CI-only commits skipped. Changes ported: - stdio: ReadBuffer maxBufferSize limit (modelcontextprotocol#2239) - stdio: windowsHide always on Win32, removed isElectron() (modelcontextprotocol#1640) - stdio: try/catch error handling on read buffer overflow - types: extensions capability on ClientCapabilities/ServerCapabilities (modelcontextprotocol#1811) - types: size field on ResourceSchema (modelcontextprotocol#1575) - zod-compat: prioritize zod issues with path formatting (modelcontextprotocol#1503) - protocol: conditional abort controller cleanup (modelcontextprotocol#1462) Intentionally kept: - AuthInfo import from ./shared/auth-info.js (not reverted to auth/types.js) - All removed transports, auth, and HTTP modules stay out

mozmo15 requested a review from a team as a code owner February 9, 2026 12:52

mozmo15 mentioned this pull request Feb 9, 2026
getParseErrorMessage prioritizes error.message which bypasses custom Zod errors #1415
Open

mozmo15 force-pushed the fix/custom-error-message branch 2 times, most recently from 3dd2443 to 1ca5e84Compare February 9, 2026 13:00

claudeBot reviewed Mar 27, 2026
View reviewed changes

Comment threadsrc/server/zod-compat.ts Outdated

mozmo15 force-pushed the fix/custom-error-message branch from 1ca5e84 to 3d4d780Compare March 30, 2026 15:21

mozmo15 requested a review from a team as a code owner March 30, 2026 15:21

mozmo15 force-pushed the fix/custom-error-message branch 2 times, most recently from a885f10 to 27e12faCompare March 30, 2026 15:32

felixweinberger mentioned this pull request Mar 30, 2026
fix: getParseErrorMessage now surfaces custom Zod v4 error messages #1663
Closed

fix(server): prioritize custom zod errors and format them
68091ab

mozmo15 force-pushed the fix/custom-error-message branch from 27e12fa to 68091abCompare March 31, 2026 08:40

fix: handle empty path array in getParseErrorMessage
cb0fa43
Zod sets path: [] for root-level errors; ![] is false so the early-return never fired. Match main's standardSchema.ts:167 approach with ?.length. Also add changeset.

felixweinberger force-pushed the fix/custom-error-message branch from 45a00e5 to cb0fa43Compare March 31, 2026 12:17

felixweinberger approved these changes Mar 31, 2026
View reviewed changes

felixweinberger merged commit 9edbab7 into modelcontextprotocol:v1.xMar 31, 2026
8 checks passed

brandhaug mentioned this pull request Aug 13, 2026
chore(deps): bump @modelcontextprotocol/sdk from 1.29.0 to 1.30.0 brandhaug/b2b-saas-starter#22
Merged

claudeBot mentioned this pull request Aug 13, 2026
chore: bump @modelcontextprotocol/sdk from 1.29.0 to 1.30.0 kosli-dev/mcp-server#29
Merged