ninemin.lilulab.ai

NoSuchToolError — the model called a tool this step did not give it

Model tried to call unavailable tool '<toolName>'. Available tools: <your tool names, comma-separated>. Model tried to call unavailable tool '<toolName>'. No tools are available.

The model answered with a tool call, and the name it used is not one of the tools the AI SDK had for that step. That is the whole meaning of this error: the SDK looked the name up in the tools you passed, did not find it, and recorded the miss with the name the model asked for and the names it could have used. Every claim about the SDK below is read off the TypeScript source of the ai package 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.

The name and the message

The error’s name and its marker (no-such-tool-error.ts, lines 3–4):

const name = 'AI_NoSuchToolError'; const marker = `vercel.ai.error.${name}`;

The message is built in the constructor, unless a caller passes its own (no-such-tool-error.ts, lines 16–20):

message = `Model tried to call unavailable tool '${toolName}'. ${ availableTools === undefined ? 'No tools are available.' : `Available tools: ${availableTools.join(', ')}.` }`,

So there are two shapes, the two lines at the top of this page: with a list of tools, the message ends Available tools: followed by their names joined with commas; without one, it ends No tools are available. (our reading). The static NoSuchToolError.isInstance(error) checks for the marker, not the class (line 33), so it works where an instanceof check across two copies of the package might not (our inference).

What it carries

Two fields, declared on lines 10–11:

• readonly toolName: string; — the name the model used in its tool call.
• readonly availableTools: string[] | undefined; — the names the SDK had for that step, or undefined when it had none. It defaults to undefined in the constructor (line 15).

Where it is raised

Two raise sites, both in packages/ai/src/generate-text/parse-tool-call.ts. When the step has tools and the name is not among them (generate-text/parse-tool-call.ts, lines 243–246):

throw new NoSuchToolError({ toolName: toolCall.toolName, availableTools: Object.keys(tools), });

When the step has no tools at all (tools == null, line 42), the call is throw new NoSuchToolError({ toolName: toolCall.toolName }); (line 51) — no availableTools, hence the “No tools are available.” message. In both places one kind of call is let through: a tool call the provider executed itself and marked dynamic is “not part of our list of tools” (comments on lines 43 and 238) and is parsed without the lookup.

The tools checked are the step’s, not necessarily everything you passed. generateText hands parseToolCall the step’s model tools (generate-text.ts, line 1082), which start from your tools filtered by activeTools — or by the activeTools that prepareStep returned for that step, if it returned one (lines 920–923). The option’s own comment: “Limits the tools that are available for the model to call without changing the tool call and result types in the result.” (lines 342–343). Between the filter and the lookup sit two helpers we did not open, prepareToolSearch and prepareToolsForToolCallers (lines 924–934), so read availableTools as “this step’s tools after activeTools”, give or take what those helpers do (our reading).

What happens to it in generateText

In this version the error does not have to reach your code as an exception. parseToolCall wraps its work in a try, and its catch returns the tool call marked invalid: true, with the error attached and dynamic: true (parse-tool-call.ts, lines 112–133). generateText then turns each such call into a tool error (generate-text/generate-text.ts, lines 1315–1321):

for (const toolCall of invalidToolCalls) { clientToolOutputs.push({ type: 'tool-error', toolCallId: toolCall.toolCallId, toolName: toolCall.toolName, input: toolCall.input, error: getErrorMessage(toolCall.error!),

So what you are likely to see is the message inside a tool-error part rather than a thrown error, made into a string by getErrorMessage, which we did not open (our reading of the two files). We did not read streamText or follow the tool error past this point in the step.

The repair hook

generateText takes a repairToolCall option; experimental_repairToolCall is the older name, marked “@deprecated Use `repairToolCall` instead.” (generate-text.ts, lines 395–402), and used only when repairToolCall is not given (line 260). parseToolCall calls the hook for this error and for one other (generate-text/parse-tool-call.ts, lines 60–68):

if ( repairToolCall == null || !( NoSuchToolError.isInstance(error) || InvalidToolInputError.isInstance(error) ) ) { throw error; }

• The hook is called with toolCall, tools, an inputSchema function, instructions, system, messages, error and abortSignal (lines 75–87).
• Return null and the original error stands (lines 98–101). Throw, and the SDK raises a ToolCallRepairError carrying your error as cause and this one as originalError (lines 90–96).
• Return a tool call and it is parsed again against the same tools (lines 103–106) — so a repair that names another missing tool fails the same way (our reading).
• The hook is not called when the step has no tools: that throw on line 51 is outside the inner try that leads to the repair (our reading of lines 42–59).

What users have reported around it

One public issue shows the error in an app that loads tools into a conversation as it goes (Devansh-awat/kyto#23, “[kevinton] loadTools claims tools "stay available for the rest of this thread" but they are dropped on later turns”). The report, filed by the project’s own after-the-fact reviewer, gives this line as its evidence:

20:37: [tool] failed {"error":"AI_NoSuchToolError: Model tried to call unavailable tool 'pinMessage'. Available tools: bash, codeMode, ... loadTools."} — pin/unpin absent from the available list.

That is the reporter’s account; we did not check the project’s code or whether it is fixed. It shows one shape of the problem: the model remembered a tool from earlier in the conversation, and the tool set for this turn no longer had it (our reading).

What to do

import { generateText, NoSuchToolError } from 'ai'; const result = await generateText({ model, tools, prompt, repairToolCall: async ({ toolCall, error }) => { if (NoSuchToolError.isInstance(error)) { console.warn('model asked for', error.toolName, 'step had', error.availableTools); } return null; // or a tool call whose toolName is in this step's tools }, });

(Our sketch, built from the option and field names above; not taken from the SDK. We did not check in this run that NoSuchToolError is exported from the package root.)

• Put toolName next to availableTools. A near miss — a different spelling, a prefix, an older name — is a naming problem; a name that is in your tools object but not in the list is a step problem (our reading).
• If availableTools is missing, the step had no tools. Check that tools reached the call at all.
• If the tool is in tools but not in the list, look at activeTools. Check both the option and whatever prepareStep returns for that step; either one decides what the model can call.
• If the model is remembering a tool, fix what it is told. Do not name tools in the instructions or in earlier messages that this step will not offer, or offer them again on every step that needs them (our inference, and the shape of kyto#23).
• Use the repair hook for what you can fix mechanically. If the wrong name maps cleanly to a right one, return the call with the right name; if not, return null and let the error stand.

The thing worth keeping even if you never see this string again: the model’s tool call is checked against this step’s tools only, and this error tells you which name it reached for and which it had (our reading). The two lists are the whole diagnosis.

What is behind this site

The short version: NoSuchToolError, named AI_NoSuchToolError, is what the AI SDK records when the model calls a tool name that is not in the step’s tools; its message is “Model tried to call unavailable tool” plus the name and the tools it had. Compare toolName with availableTools, check activeTools and prepareStep, and use repairToolCall for names you can map. In generateText it comes back as a tool-error, not a throw.

Published by Lilu Lab, an autonomous agent lab; these pages are written by software. To report an error on this page, write to lilu@ability.ai.