docs: fix outdated APIs and broken MCP example in cookbook#14772
Open
omarrns wants to merge 1 commit intovercel:mainfrom
Open
docs: fix outdated APIs and broken MCP example in cookbook#14772omarrns wants to merge 1 commit intovercel:mainfrom
omarrns wants to merge 1 commit intovercel:mainfrom
Conversation
Three small but real bugs in the docs/cookbook content: 1. content/cookbook/01-next/73-mcp-tools.mdx `streamText().toDataStreamResponse()` was renamed to `toUIMessageStreamResponse()` in v5 and the old method no longer exists on `StreamTextResult`. Following the cookbook copy-paste produces a TypeError at runtime. 2. content/cookbook/05-node/54-mcp-tools.mdx The example declares `let clientOne / clientTwo / clientThree` outside the `try`, then re-declares them as `const` inside the `try`. The inner `const` shadows the outer `let`, so the outer bindings stay `undefined`. The `finally` block then calls `clientOne.close()` on `undefined` and the process always crashes - even on the happy path, and even before any cleanup runs. Removed the inner `const` keywords so the outer bindings get assigned, typed them as `MCPClient | undefined`, and used optional chaining in `finally` so a partially-initialized run still cleans up the clients that did connect. 3. content/docs/09-troubleshooting/12-use-chat-an-error-occurred.mdx References to `toDataStreamResponse`, `getErrorMessage`, and `createDataStreamResponse` are all pre-v5 names. Per the v5 migration guide they're now `toUIMessageStreamResponse`, `onError`, and `createUIMessageStream` + `createUIMessageStreamResponse`. Note: the doc was already internally inconsistent — line 44 used the new `toUIMessageStreamResponse` but still passed the old `getErrorMessage:` option to it. Updated the prose and both snippets to the current API.
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
1 participant
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
Three small but real bugs in
content/, all confirmed against currentmain:content/cookbook/01-next/73-mcp-tools.mdx— callsresponse.toDataStreamResponse(), which was renamed totoUIMessageStreamResponse()in v5 and no longer exists onStreamTextResult(packages/ai/src/generate-text/stream-text-result.ts:359). Copy-pasting the cookbook into a Next route handler produces aTypeErrorat runtime.content/cookbook/05-node/54-mcp-tools.mdx— variable shadowing bug. The example declareslet clientOne / clientTwo / clientThreeoutside thetry, then re-declares each asconstinside. The innerconstshadows the outerlet, so the outer bindings stayundefined. Thefinallyblock then callsclientOne.close()onundefinedand the process always crashes — even on the happy path, and before any actual cleanup runs.Fix: drop the inner
constkeywords so the outer bindings get assigned, type them asMCPClient | undefined(MCPClientis a stable export from@ai-sdk/mcp), and use optional chaining infinallyso partial-init failures still clean up clients that did connect.content/docs/09-troubleshooting/12-use-chat-an-error-occurred.mdx— three pre-v5 API names:toDataStreamResponse,getErrorMessage:, andcreateDataStreamResponse. Per the v5 migration guide (content/docs/08-migration-guides/26-migration-guide-5-0.mdx, §"Error Handling: getErrorMessage → onError"), these are nowtoUIMessageStreamResponse,onError:, and the splitcreateUIMessageStream+createUIMessageStreamResponsepair. The doc was already internally inconsistent — line 44 used the newtoUIMessageStreamResponsebut still passed the oldgetErrorMessage:option to it.Docs-only, no package changes, no changeset (matches the precedent of #12097 "docs: fix incorrect and outdated cookbooks").
Test plan
MCPClientis the right stable type to expose in the cookbook (vs. inferring viaAwaited<ReturnType<typeof createMCPClient>>)