You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The same "missing arguments rejected when all schema fields are optional" pattern fixed for tools in #1404 still affects prompts, and #1404 itself is not in any 1.x release.
Two distinct gaps:
Prompts handler is unfixed (all versions, including main).prompts/get calls safeParseAsync(argsObj, request.params.arguments) without the ?? {} defensive pattern that fix(server): handle undefined arguments for tools with all optional params #1404 introduced for tools. A prompt registered with argsSchema: { context: z.string().optional() } and called with arguments omitted returns MCP error -32602: Invalid arguments for prompt <name>: [{ "code": "invalid_type", "expected": "object", "received": "undefined" }].
Tools fix (fix(server): handle undefined arguments for tools with all optional params #1404) is not in the 1.x line. The fix landed on main on 2026-01-23 but none of the v1.x backport releases (1.27.0, 1.27.1, 1.28.0, 1.29.0 — all tagged as "[v1.x backport]") include it. Users on @modelcontextprotocol/sdk@^1.27.0 still hit the tools-side bug.
Per the MCP spec, arguments on prompts/get is OPTIONAL at the request level. A registered prompt where every declared argument is optional should accept a request that omits arguments entirely. The same applies to tools/call (addressed upstream by #1404 on main).
Actual behavior
safeParseAsync(argsObj, undefined) fails because argsObj is the non-optional z.object(...) returned by objectFromShape(), which rejects undefined at the top level. The error propagates to the client as JSON-RPC -32602 "Invalid params".
Root cause is _createRegisteredPrompt in src/server/mcp.ts (around line 567):
Transport-layer normalization that sets req.body.params.arguments ??= {} before the request reaches the SDK, for both prompts/get and tools/call. Works across all 1.x versions but is obviously a wart we'd like to drop.
Describe the bug
The same "missing
argumentsrejected when all schema fields are optional" pattern fixed for tools in #1404 still affects prompts, and #1404 itself is not in any 1.x release.Two distinct gaps:
Prompts handler is unfixed (all versions, including main).
prompts/getcallssafeParseAsync(argsObj, request.params.arguments)without the?? {}defensive pattern that fix(server): handle undefined arguments for tools with all optional params #1404 introduced for tools. A prompt registered withargsSchema: { context: z.string().optional() }and called withargumentsomitted returnsMCP error -32602: Invalid arguments for prompt <name>: [{ "code": "invalid_type", "expected": "object", "received": "undefined" }].Tools fix (fix(server): handle undefined arguments for tools with all optional params #1404) is not in the 1.x line. The fix landed on
mainon 2026-01-23 but none of the v1.x backport releases (1.27.0, 1.27.1, 1.28.0, 1.29.0 — all tagged as "[v1.x backport]") include it. Users on@modelcontextprotocol/sdk@^1.27.0still hit the tools-side bug.To Reproduce
Server (using 1.27.0 or any 1.x):
Client — any of these fail in the same way:
Client workaround that succeeds:
Expected behavior
Per the MCP spec,
argumentsonprompts/getis OPTIONAL at the request level. A registered prompt where every declared argument is optional should accept a request that omitsargumentsentirely. The same applies totools/call(addressed upstream by #1404 on main).Actual behavior
safeParseAsync(argsObj, undefined)fails becauseargsObjis the non-optionalz.object(...)returned byobjectFromShape(), which rejectsundefinedat the top level. The error propagates to the client as JSON-RPC -32602 "Invalid params".Root cause is
_createRegisteredPromptinsrc/server/mcp.ts(around line 567):Wrapped once, the top-level object is never optional, and there's no
?? {}coercion at the parse site (unlike tools, where #1404 added it).Proposed fix
Mirror #1404 in the prompts handler:
Plus backport both the tools fix (#1404) and this prompts fix to the
v1.xbranch so users on@modelcontextprotocol/sdk@^1.xget consistent behavior.Affected versions
mainas well (PR fix(server): handle undefined arguments for tools with all optional params #1404 only touched the tools path).mainby fix(server): handle undefined arguments for tools with all optional params #1404 but not yet in any 1.x release.Workaround we're using
Transport-layer normalization that sets
req.body.params.arguments ??= {}before the request reaches the SDK, for bothprompts/getandtools/call. Works across all 1.x versions but is obviously a wart we'd like to drop.Related