tools/call with null arguments returns -32603 (InternalError) instead of being accepted

When a client sends a tools/call request where arguments is null (rather than omitted or {}), the SDK returns -32603 InternalError with a raw Zod validation message instead of accepting the request.

This affects every server built on the TypeScript SDK. Clients that serialize missing/empty fields as null (common in Go, Java, and C# JSON libraries) cannot call tools without arguments.

Reproduce

Send this over stdio to any server built with @modelcontextprotocol/sdk:

{"jsonrpc":"2.0","method":"initialize","id":1,"params":{"clientInfo":{"name":"test","version":"1.0"},"protocolVersion":"2025-11-25","capabilities":{}}}
{"jsonrpc":"2.0","method":"tools/call","id":2,"params":{"name":"echo","arguments":null}}

Expected

Request accepted (arguments treated as empty/undefined).

Actual

{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32603,
    "message": "[\n  {\n    \"expected\": \"record\",\n    \"code\": \"invalid_type\",\n    \"path\": [\"params\", \"arguments\"],\n    \"message\": \"Invalid input: expected record, received null\"\n  }\n]"
  }
}

Two problems:

1. null rejected for an optional field. CallToolRequestParamsSchema uses .optional() which accepts undefined but not null. The MCP spec says arguments is optional; null should be treated as absent.

2. Wrong error code. The error is -32603 (InternalError) instead of -32602 (InvalidParams). The protocol handler uses schema.parse() which throws a ZodError on failure. ZodError has no numeric code property, so the error handler at protocol.ts:672 falls back to ProtocolErrorCode.InternalError.

Impact

Tested against @modelcontextprotocol/server-everything: all 13 tools fail with this error when called with null arguments. Any Go, Java, or C# client that serializes missing fields as null will hit this on every server built with the TypeScript SDK.

Versions

• @modelcontextprotocol/sdk main branch (also confirmed on published npm package)
• Node.js v25.8.2

Inizia da CallToolRequestParamsSchema e dal gestore del protocollo intorno a protocol.ts:672, quindi riproduci la richiesta tramite stdio usando il JSON mostrato. Il lavoro è completato quando tools/call accetta gli argomenti null come assenti e i dati della richiesta non validi producono l’errore InvalidParams del protocollo invece di InternalError.