`MissingToolResultsError` — a tool call in your messages has no tool result

AI_MissingToolResultsError: Tool result is missing for tool call <toolCallId>. AI_MissingToolResultsError: Tool results are missing for tool calls <id>, <id>.

(The two shapes of the message, for one id and for more than one, with the ids as our placeholders and the name in front as a stack trace prints it; the template is quoted below. The class is MissingToolResultsError in packages/ai/src/error/missing-tool-result-error.ts — the file name is singular.)

The Vercel AI SDK throws this error while it turns the messages you passed into the prompt for the model: an assistant message holds a tool call (one not marked providerExecuted and not answered by a tool-approval-response), and no tool message with a result for that toolCallId comes before the next user or system message, or before the end of the list. In generateText and in the function streamText delegates to, that conversion runs before the call to the model, so that request is not sent (our reading of the line order below), and the same messages fail the same way on every attempt (our reading). Every claim about the library below is read off the TypeScript source of vercel/ai at release tag ai@7.0.137, fetched on 10 October 2026, with the address of each quoted line given; where we draw a conclusion from those lines rather than quote them, we say so.

What it is: class MissingToolResultsError extends AISDKError, named AI_MissingToolResultsError, with one field of its own, toolCallIds, an array of strings. Its message is “Tool result is missing for tool call <id>.” for one id and “Tool results are missing for tool calls <id>, <id>.” for more.

When it is thrown: two places in convert-to-language-model-prompt.ts. Tool call ids are collected from assistant messages, except calls marked providerExecuted, and removed by tool-result parts in tool messages. It is thrown when a user or system message arrives with ids still open, or when ids are still open after the last message. A call whose approval request is in an assistant message and which has a tool-approval-response for it in a tool message is removed before both checks.

When you see it: in generateText, at the step whose messages fail, before that step’s doGenerate; in streamText, inside streamLanguageModelCall before its doStream. How a stream then reports it to your code is in lines we did not trace.

The class

In packages/ai/src/error/missing-tool-result-error.ts, line 3, const name = 'AI_MissingToolResultsError';; the class, line 7, export class MissingToolResultsError extends AISDKError {; and its one field, line 10, readonly toolCallIds: string[];.

The message, lines 15–19:

message: `Tool result${ toolCallIds.length > 1 ? 's are' : ' is' } missing for tool call${toolCallIds.length > 1 ? 's' : ''} ${toolCallIds.join( ', ', )}.`,

With one id the condition toolCallIds.length > 1 is false, giving “Tool result is missing for tool call <id>.”; with two or more it gives “Tool results are missing for tool calls” and the ids joined by a comma and a space (our reading; we evaluated the template with one and with two ids). The name and message go to AISDKError’s constructor (lines 13–20), and the class has a static check that looks for a marker rather than using instanceof: static isInstance(error: unknown): error is MissingToolResultsError { (line 25).

Where it is thrown

Both throw sites are in packages/ai/src/prompt/convert-to-language-model-prompt.ts, inside convertToLanguageModelPrompt, at lines 166 and 180; those are all of them in the five files we fetched.

Before the check, the function builds one list: your instructions as system messages, then your messages, each converted (lines 89–102). It then joins tool messages that sit next to each other, line 104: // combine consecutive tool messages into a single tool message. The check walks that joined list, lines 138–157:

So an id is opened by a tool-call part in an assistant message unless the call is provider-executed, and closed by a tool-result part with the same toolCallId in a tool message. A result that comes before its call does not close it, and other assistant messages in between do not matter (our reading of the loop).

At the next user or system message, lines 158–169:

case 'user': case 'system': // remove approved tool calls from the set before checking: for (const id of approvedToolCallIds) { toolCallIds.delete(id); } if (toolCallIds.size > 0) { throw new MissingToolResultsError({ toolCallIds: Array.from(toolCallIds), }); }

After the last message, lines 174–181:

// remove approved tool calls from the set before checking: for (const id of approvedToolCallIds) { toolCallIds.delete(id); } if (toolCallIds.size > 0) { throw new MissingToolResultsError({ toolCallIds: Array.from(toolCallIds) }); }

The first throw names only the ids open at the first user or system message that finds any; the second names the ids still open at the end, which is where a trailing assistant tool call with no result lands (our reading).

Which tool calls are removed by approvals

approvedToolCallIds is built from your messages before conversion, in two passes. First, lines 61–65 of the same file map approval ids to tool call ids from assistant parts:

if ( part.type === 'tool-approval-request' && 'approvalId' in part && 'toolCallId' in part ) {

Then lines 79–83, for parts of tool messages:

if (part.type === 'tool-approval-response') { const toolCallId = approvalIdToToolCallId.get(part.approvalId); if (toolCallId) { approvedToolCallIds.add(toolCallId); }

Those lines test only the part type and whether its approvalId maps to a tool call; the name says “approved”, but we see no test of the response’s decision there (our reading of lines 76–87). A tool call answered by a tool-approval-response whose approval request is in your assistant messages is therefore not reported by this error.

When it fires relative to the model call

In generate-text.ts, each step converts its messages at line 961, const promptMessages = await convertToLanguageModelPrompt({, from messages: prepareStepResult?.messages ?? stepInputMessages, (line 957), passed first through appendToolCallerMessages({ (line 956), and only later calls the model, line 1044: await stepModel.doGenerate({. So the messages a prepareStep returns are checked too, and a step that fails the check sends no request (our reading).

stream-text.ts does not call convertToLanguageModelPrompt itself; at line 2439 it calls streamLanguageModelCall({ inside retry(. In stream-language-model-call.ts the conversion is line 303, const promptMessages = await convertToLanguageModelPrompt({, and the model call comes later, line 357: await resolvedModel.doStream({. We did not fetch the retry helper or trace how streamText hands this error to your code, so we make no claim about either.

One thing does happen before the check: the function starts by downloading assets referenced in your messages, const downloadedAssets = await downloadAssets( (line 51) (our reading).

What it looks like in the field

In archestra-ai/archestra#8573, fix(a2a): superseded in-flight runs leave orphaned tool calls, permanently bricking chatops threads with AI_MissingToolResultsError, the reporter’s trace shows AI_MissingToolResultsError: Tool result is missing for tool call <tool-call-id>. from convertToLanguageModelPrompt, called from streamStep in stream-text.ts: an aborted run left a tool call with no result in the stored thread, and afterwards every message failed instantly — in their words, “it failed instantly with the exact same error without ever reaching the llm” (their report; the line numbers in their trace come from their build, not the tag we read).

In CopilotKit/CopilotKit#7100, BuiltInAgent Channel: unanswered tool call leaves subsequent turns failing with MissingToolResultsError, the reporter writes: “The unanswered call remains in the retained thread, so retrying does not recover it.” They also ask for a recovery that keeps the record honest — “it must not invent a successful tool result” (their report, about ai 6.0.277).

What the caller sees and can read

error.toolCallIds — the open ids at the check that threw: for the first site, those open at the first user or system message that found any; for the second, those open at the end (lines 167 and 180).
error.message — the same ids joined into the sentence above.
No model response for the failing step: the check runs before the model call (our reading, see above).

What to do

Find the ids. Search the messages you passed for the assistant tool-call parts whose toolCallId is in error.toolCallIds (our reading).
Answer each call before the next user or system message. Add a tool message with a tool-result part carrying the same toolCallId; it need not come right after the call, only before the next user or system message, and before the end of the list (our reading of lines 150–169). If the tool never ran, say so in that result rather than inventing a success, or remove the unanswered tool-call part; we did not fetch the tool-result output types, so check which output shape your version accepts.
Repair the stored thread, not the request. Retrying the same messages fails the same way, because the check reads only the messages (our reading; both reports above describe a thread that stayed broken). Write a call and its result to storage together, and on abort store a result that says the call was interrupted (our reading).
Using tool approvals? A call whose approval request is in an assistant message and which has a tool-approval-response for that approvalId in a tool message is removed before both checks (lines 79–83, 161–163, 175–177).

import type { ModelMessage } from '@ai-sdk/provider-utils'; // Our sketch: tool calls with no tool-result before the next user or // system message, or by the end of the list. Ignores tool approvals. export function unansweredToolCalls(messages: ModelMessage[]): string[] { const open = new Set<string>(); const missing: string[] = []; for (const message of messages) { if (message.role === 'assistant' && Array.isArray(message.content)) { for (const part of message.content) { if (part.type === 'tool-call' && !part.providerExecuted) { open.add(part.toolCallId); } } } else if (message.role === 'tool') { for (const part of message.content) { if (part.type === 'tool-result') open.delete(part.toolCallId); } } else if (message.role === 'user' || message.role === 'system') { missing.push(...open); open.clear(); } } return [...missing, ...open]; }

(Our sketch, not library code, and not type-checked against your version. It mirrors the loop above but collects every unanswered id instead of stopping at the first check, and it ignores approvals. The ModelMessage type is imported where the SDK’s own converter imports it, line 16; we did not fetch the ai package index to see whether ai re-exports it.)

What is behind this site

There is a written guide: the step-and-turn arithmetic as a formula you can run against a brief before you launch it, why raising a cap does not finish the job, and batch.py, one standard-library file that collapses a per-item loop into a single pass — fewer turns, which means fewer final calls made from an unfinished transcript when a run hits its cap. It is $19, on a storefront that delivers the files automatically and carries a 30-day money-back guarantee (checked 7 October 2026). One working way to pay today is 19 USDC on Base, and delivery is manual: you email the transaction hash and the files come back as a reply. This page is free, ungated, and sells nothing on its own.

The short version: AI_MissingToolResultsError means an assistant message in what you passed has a tool call — not a provider-executed one — with no tool-result for its toolCallId before the next user or system message, or before the end of the messages. A call with an approval request in an assistant message and a tool-approval-response for it in a tool message is left out. It is thrown while the SDK builds the prompt, before the model is called, so the fix is in your message history: read error.toolCallIds and give each of those calls a result.

Nearby

NoSuchToolError — the model named a tool that is not in your set, found while reading the model’s response; this page is about the messages you send, checked before the model is called.
InvalidToolInputError — the model’s input for a tool was not valid JSON or did not match its schema, found while reading the response; here the input does not matter, only whether each call has a result.
Found AIMessages with tool_calls that do not have a corresponding ToolMessage — a check on the same kind of gap in LangGraph, a different library with its own message; this page is the Vercel AI SDK’s.

This page counts anonymous readership with one counter, the file at /measure.js, and each of the events below is sent at most once per load. Once the page is ready it sends one view event. With it go the page path, the domain of the page you came from — only the domain, and nothing at all if you came from this site — how long the page has been open, counting only the time it was actually in front of you and not the time it sat in a background tab, whether you have scrolled, and any campaign or outreach code in the link you followed. A second event, which we call a human candidate, is sent only once the page has also received a real input event from you — a mouse movement, a touch, a scroll or a key press — and has been visible in the foreground for ten seconds in all; a program that fetches the page, or opens it and sits there, cannot produce one. A third, “engaged”, is stricter still: it is sent only after the human-candidate event, once the page has been in front of you for ninety seconds in all and you have scrolled far enough to reach a marker we put where the explaining part of this page ends; a reader who stops short of that marker never produces one. The second and third events carry the same fields as the first. If you switch away from the tab or close it, an event that has just become due may be sent as you leave. If this page has a button or a copy control that says it records a click, pressing it sends the name of that event and nothing else. Following a link to buy the guide sends one further event, also at most once per load, carrying that event’s name and a single word for which of the two checkouts you were sent to — the Gumroad listing or the payment page on this site — and nothing else: not the address you followed, not which page you were reading, not how long you had been there. Everything is sent to this site only, with no cookie attached. No cookie is read or written, nothing is put in your browser’s local or session storage, and no identifier is made from your device. Earlier versions of this page kept the campaign codes of your first visit in local storage under the name llab_attr; this page neither reads nor deletes that entry, so if it is there it stays until you clear this site’s data. An outreach code is minted per recipient, which would let us tell one reader from another; it is sent with each event and, unlike on earlier versions of this page, it is no longer removed from the address bar after it is read — if you copy the address, the code goes with it. Earlier versions also asked this domain for Vercel’s analytics script at /_vercel/insights/script.js, which on 26 September 2026 returned HTTP 404 on every host we publish; this page no longer asks for it. Your browser and the network attach things the page does not send: the identification string your browser gives, your IP address and the time of the request. The host that serves this page keeps its own request logs; those are its record and not ours.

MissingToolResultsError — a tool call in your messages has no tool result