"Model tried to call unavailable tool 'X'. Available tools: ..."

Why it happens

The AI SDK checks every tool call the model returns against the tools you registered for that step. If the name is not there, it raises NoSuchToolError and prints the requested name plus the full list it does have, which is why the message can be very long.

1. The model invented the name. Small and quantized local models emit placeholders such as unknown or invalid, or guess a plausible tool. OpenCode users hit it constantly with Qwen models (issue #21090) and with phantom calls from Qwen via OpenRouter (issue #33618, open).
2. The tool set changed mid-conversation. If you narrow tools with activeTools or rebuild the tools object per request, the model can still call a tool it saw earlier in history or a stale system prompt. Older SDKs also listed, and could run, inactive tools (vercel/ai issue #9141, fixed in ai 5.0.217 and 6.0.231).
3. The call is malformed. Some models paste XML-style syntax into the name field, so the error shows a name like tool1" /> even though tool1 is listed. Left in history, that name can make Bedrock reject the next request (vercel/ai issue #9173).
4. A step with no tools got a tool call. In OpenCode, compaction produced "Available tools: ." and ended the turn (issue #13317, closed without a fix).
5. Context overflow. Past the model's real context window, tool definitions get cut off and the model starts guessing names.

The fix

1. 1 Read the name in the quotes. A real tool you removed points to a stale tool set or prompt; unknown, invalid or an XML fragment points to the model.
2. 2 Upgrade the SDK so activeTools filtering also applies to parsing and execution: npm install ai@latest (at least ai 5.0.217 on v5, ai 6.0.231 on v6).
3. 3 Keep the tool list stable for the whole conversation and remove deleted tools from the system prompt and saved history.
4. 4 Handle the error instead of crashing: add a repair function (experimental_repairToolCall in AI SDK 5 and 6, repairToolCall in v7) and check NoSuchToolError.isInstance(error).
5. 5 For local models, pick one with reliable tool calling, raise the context length and register fewer tools.
6. 6 In OpenCode, deny unneeded tools in the permission block of opencode.json; MCP tools accept wildcards such as "mymcp_*": "deny".

Why small local models trigger it most

Smaller and quantized models are worse at copying an exact name from a long tool list, so they fall back to generic or half-remembered names. Dozens of MCP tools add thousands of tokens of definitions, and a model near its context limit loses track of which names are real.

The error then feeds itself: each failure adds the full tool list to the context again. One OpenCode user with about 130 MCP tools reported thousands of wasted tokens per error (issue #41047, closed as stale). Fewer tools and a model with dependable tool calling break the loop.

Handling it in AI SDK code

generateText throws NoSuchToolError, so wrap it in try/catch; streamText emits it as an error part. A repair function can intercept it first. Returning null declines the repair:

import { generateText, NoSuchToolError } from 'ai';

const result = await generateText({
  model,
  tools,
  // AI SDK 5 and 6: experimental_repairToolCall; v7: repairToolCall
  experimental_repairToolCall: async ({ toolCall, error }) => {
    if (NoSuchToolError.isInstance(error)) {
      console.warn('Unknown tool:', toolCall.toolName);
    }
    return null;
  },
  prompt,
});

Still failing?

• Log toolCall.toolName on every failure: if the same real name keeps appearing, your prompt, history or MCP config still advertises it.
• Check the name for quotes, slashes or dollar signs, which point to a malformed call that can break the next provider request.
• Run the same prompt on a different model; if the error disappears, the model's tool calling is the problem.

Related errors

• OpenClaw "tool read/write/exec does not exist"
• Ollama "model does not support tools"