{{ message }}
docs: document v1 z.object() vs raw-shape footgun in troubleshooting + migration guide - #2813
Draft
huzaifafarooqusa-spec wants to merge 2 commits into
Conversation
…ng one chunk streamableHttp.test.ts asserted on multiple SSE events after a single reader.read() call, assuming Node's fetch would coalesce them into one chunk. That assumption doesn't hold on newer Node versions, where closely-timed events can arrive as separate chunks across separate reads, failing the test before the later event is read. Adds a readUntilContains helper that accumulates decoded text across reads until the expected content appears (or times out), and uses it in the two tests that were asserting on multiple SSE events from a single read.
…+ migration guide
On SDK v1, server.tool() expects a raw shape ({ name: z.string() })
rather than a ZodObject, but nothing about the two failure modes
points a reader at the actual mistake:
- v1 <=1.21: tools/list crashes with
"Cannot read properties of null (reading '_def')"
- v1 1.22-1.26: registration succeeds but publishes an empty
{"type":"object"} schema, so every client silently strips the
tool's arguments
v1 >=1.28 already throws a clear error, but the older ranges are
still widely deployed and easy to hit when copying v2-style
examples (which use z.object()) into v1 code. Adds a troubleshooting
entry keyed on both observable symptoms, and a short callout in the
v2 migration guide next to the registerTool example, so both search
paths land on the explanation.
Reported with full repro matrix in modelcontextprotocol#2627.
huzaifafarooqusa-spec
force-pushed
the
docs/v1-zod-object-vs-raw-shape
branch
from
September 14, 2026 01:27
814ceec to
ab9ac4c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
On SDK v1,
server.tool()expects a raw shape ({ name: z.string() }), not aZodObject(z.object({...})) — the opposite of v2. Passing the wrong one produces failure modes that never point at the actual cause:tools/listcrashes withCannot read properties of null (reading '_def'){"type":"object"}schema — clients strip all tool arguments with no error anywhereFull repro matrix and root cause analysis from #2627 (credit to the reporter — this PR just writes it up).
Changes
docs/troubleshooting.md: new entry keyed on both observable symptoms, plus a recap line, following the page's existing convention.docs/migration/upgrade-to-v2.md: short callout next to theregisterToolexample explaining the reverse mistake on v1.Testing
prettier --check docs/troubleshooting.md docs/migration/upgrade-to-v2.md→ cleanpnpm build:all/typecheck:all/lint:allvia pre-push hook → all greenAddresses #2627