fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

fix: getParseErrorMessage now surfaces custom Zod v4 error messages - #1663

Closed
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors
Closed

fix: getParseErrorMessage now surfaces custom Zod v4 error messages#1663
Vadaski wants to merge 2 commits into
modelcontextprotocol:mainfrom
Vadaski:fix/1415-getparseerrormessage-zod-v4-custom-errors

Conversation

@Vadaski

Copy link
Copy Markdown

Problem

In Zod v4, error.message is a JSON serialization of the issues array rather than a user-facing string. The previous implementation of getParseErrorMessage prioritized error.message, which caused custom error messages defined via .min(1, 'My custom error') or custom error maps to be completely swallowed. Instead of seeing "My custom error", callers received a raw JSON blob like:

[{"origin":"string","code":"too_small","minimum":1,"inclusive":true,"path":[],"message":"My custom error"}]

This affected tool input validation errors, output schema validation, prompt argument errors, and listChanged options validation — anywhere the SDK surfaces a Zod parse failure to the developer.

Closes#1415

Fix

Extract messages from error.issues first; fall back to error.message only when no issue messages are available.

Also updated call sites in client.ts and mcp.ts that were hand-rolling issues.map(i => i.message).join(', ') to use getParseErrorMessage for consistency.

Changes

  • packages/core/src/util/schema.ts — fix getParseErrorMessage to prefer issue.message over the JSON-serialized error.message
  • packages/core/test/util/schema.test.ts — new test file with regression tests for custom Zod v4 messages and fallback behaviour
  • packages/client/src/client/client.ts — use getParseErrorMessage instead of raw error.message
  • packages/server/src/server/mcp.ts — use getParseErrorMessage consistently (3 call sites)

Testing

All existing tests pass (pnpm build:all && pnpm test:all).

In Zod v4, `error.message` is a JSON serialization of the issues array
rather than a user-facing string. The previous implementation prioritized
`error.message`, which caused custom error messages defined via
`.min(1, 'My custom error')` or custom error maps to be swallowed —
callers saw a raw JSON blob instead of the human-readable message.
Fix by extracting messages from `error.issues` first, falling back to
`error.message` only when no issue messages are available.
Also update call sites in `client.ts` and `mcp.ts` that were
hand-rolling `issues.map(i => i.message).join(', ')` to use
`getParseErrorMessage` consistently.
Closesmodelcontextprotocol#1415
@Vadaski
Vadaski requested a review from a team as a code ownerMarch 12, 2026 03:35
@changeset-bot

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 1534a33

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

pkg-pr-newBot commented Mar 12, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1663

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1663

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1663

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1663

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1663

commit: 92df769

@felixweinberger

Copy link
Copy Markdown
Contributor

Thanks for this, consolidating work in this area on #1503 please comment there if you have any additional requirements here.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

getParseErrorMessage prioritizes error.message which bypasses custom Zod errors

2 participants

@Vadaski@felixweinberger