RegisteredTool.update() crashes with ZodObject inputSchema (passthrough schemas)

[andypalmi]

Description

RegisteredTool.update() crashes when paramsSchema is a ZodObject instance (e.g. z.object({...}).passthrough()) instead of a raw shape (Record<string, ZodType>).

The error:

TypeError: Cannot read properties of null (reading '_zod')

Root cause

The create path in _createRegisteredTool uses getZodSchemaObject(inputSchema) which correctly handles both raw shapes and ZodObject instances:

function getZodSchemaObject(schema) {
    if (!schema) return undefined;
    if (isZodRawShapeCompat(schema)) return objectFromShape(schema); // raw shape
    return schema; // ZodObject — pass through
}

But the update path calls objectFromShape() directly:

update: updates => {
    if (typeof updates.paramsSchema !== 'undefined')
        registeredTool.inputSchema = objectFromShape(updates.paramsSchema);
}

objectFromShape expects a raw shape and calls Object.values(shape). When given a Zod v3 ZodObject, Object.values() iterates all own enumerable properties — including internal ones like _cached which is null. This leads to isZ4Schema(null) which accesses null._zod and throws.

Type inconsistency

The types reflect the same inconsistency:

• registerTool accepts inputSchema?: InputArgs where InputArgs extends undefined | ZodRawShapeCompat | AnySchema — ZodObject is supported
• RegisteredTool.update() types paramsSchema?: InputArgs where InputArgs extends ZodRawShapeCompat — only raw shapes

Reproduction

const { z } = require('zod');

const schema = z.object({
    id: z.string(),
    property: z.string().optional(),
}).passthrough();

// Register works fine (create path handles ZodObject)
const tool = server.registerTool('my_tool', {
    description: 'test',
    inputSchema: schema,
}, async (args) => ({ content: [{ type: 'text', text: 'ok' }] }));

// Update crashes (update path does not handle ZodObject)
tool.update({ paramsSchema: schema });
// TypeError: Cannot read properties of null (reading '_zod')

Suggested fix

The update path should use getZodSchemaObject() (or equivalent) instead of calling objectFromShape() directly, matching the create path behavior.

Environment

• @modelcontextprotocol/sdk: 1.26.0
• zod: 3.25.76
• Node.js: v20.x

[mcp-claude]

reproduced on v1.x @ 69749aa. the update path calls objectFromShape(updates.paramsSchema) directly (src/server/mcp.ts:908) while the create path routes through getZodSchemaObject (src/server/mcp.ts:888). when handed a v3 ZodObject, objectFromShape runs Object.values(shape).every(isZ4Schema) and hits internal enumerable props like _cached=null, so isZ4Schema(null) reads null._zod and throws. same wrong dispatch one line down for outputSchema (src/server/mcp.ts:909). on v4 it doesn't throw but silently discards the schema (methods on the object aren't v4 schemas, so allV3 is true and it hands the whole ZodObject to z3.object() as a shape → empty properties).

not present on main (95d28cb) — the v2 refactor to StandardSchemaWithJSON removed the objectFromShape call from the update path, so the fix only needs to land on v1.x.

workaround: pass the raw shape (.shape) to update({ paramsSchema }) instead of the ZodObject.

repro

import { z } from 'zod';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

const server = new McpServer({ name: 'test', version: '0.0.0' });
const schema = z.object({ id: z.string(), property: z.string().optional() }).passthrough();

const tool = server.registerTool(
    'my_tool',
    { description: 'test', inputSchema: schema },
    async () => ({ content: [{ type: 'text', text: 'ok' }] })
);
tool.update({ paramsSchema: schema as unknown as { [k: string]: z.ZodTypeAny } });

TypeError: Cannot read properties of null (reading '_zod')
    at isZ4Schema (src/server/zod-compat.ts:60:21)
    at Array.every (<anonymous>)
    at objectFromShape (src/server/zod-compat.ts:69:26)
    at update (src/server/mcp.ts:908)

suggested fix

// src/server/mcp.ts
-                if (typeof updates.paramsSchema !== 'undefined') registeredTool.inputSchema = objectFromShape(updates.paramsSchema);
-                if (typeof updates.outputSchema !== 'undefined') registeredTool.outputSchema = objectFromShape(updates.outputSchema);
+                if (typeof updates.paramsSchema !== 'undefined') registeredTool.inputSchema = getZodSchemaObject(updates.paramsSchema);
+                if (typeof updates.outputSchema !== 'undefined') registeredTool.outputSchema = getZodSchemaObject(updates.outputSchema);

test to verify: register a tool, call tool.update({ paramsSchema: z.object({...}), outputSchema: z.object({...}) }) with full ZodObject instances (not raw shapes) — should not throw and the resulting inputSchema/outputSchema in tools/list should reflect the updated properties. exercised for both zod v3 and v4 via the existing zod test matrix.

[allocsys]

Took a look at this against current main — this bug appears to already be resolved by the v2 rewrite and no longer reproduces.

The repro here was against @modelcontextprotocol/sdk@1.26.0 (pre-rewrite single-package v1). On current main, RegisteredTool.update() in packages/server/src/server/mcp.ts no longer calls objectFromShape() at all:

if (updates.paramsSchema !== undefined) {
    registeredTool.inputSchema = updates.paramsSchema;
    delete this._toolInputSchemaJson[name];
    needsExecutorRegen = true;
}

It assigns updates.paramsSchema straight to inputSchema — no raw-shape conversion step, so there's nothing to crash on Object.values() over a ZodObject/.passthrough() instance.

A few other relevant points from reading the current source:

• objectFromShape doesn't exist anywhere in the codebase anymore (searched for it, no hits).
• RegisteredTool.update()'s type signature now types paramsSchema as StandardSchemaWithJSON only — the raw-shape (ZodRawShapeCompat) form isn't accepted by update() at all, so the type-level inconsistency described in the issue (create accepts both, update only accepts raw shape) is also gone; now it's the reverse — both effectively expect a full schema at the update() boundary, with registerTool()'s legacy raw-shape overload doing its own normalizeRawShapeSchema() conversion before ever reaching _createRegisteredTool.

Given the underlying architecture this was filed against (single-package v1) no longer exists, this looks safe to close as fixed-by-rewrite rather than needing a standalone patch. Happy to open a regression test against current main covering update({ paramsSchema: z.object({...}).passthrough() }) if that'd be useful to pin the behavior, just let me know.

[Parithosh-Varma]

Verified on current main (6032170): the exact repro from this issue now passes — registerTool with a passthrough z.object() registers fine and tool.update({ paramsSchema: schema }) completes without throwing. The old crash path (objectFromShape(updates.paramsSchema)) is gone in the StandardSchema refactor; update now assigns the schema object directly. Looks incidentally fixed — closing as completed seems right unless someone can still repro on v1.x.