parseToolCall validates provider-executed tools causing invalid tool errors

[pablof7z]

Bug Report: parseToolCall validates provider-executed tools causing invalid tool errors

Description

The AI SDK's parseToolCall function incorrectly validates provider-executed tool calls (tools with providerExecuted: true), causing them to be marked as invalid: true even though they execute successfully. This results in error messages being sent back to the model, confusing it into apologizing for tools it just successfully used.

Reproduction

Environment

• AI SDK version: 5.0.106
• Provider: ai-sdk-provider-claude-code v2.2.3
• Runtime: Bun

Minimal Reproduction

import { stepCountIs, streamText } from 'ai';
import { createClaudeCode } from 'ai-sdk-provider-claude-code';

const bashOnlyClaude = createClaudeCode({
  defaultSettings: {
    allowedTools: ["Bash(echo:*)", "Bash(date)", "Bash(pwd)"],
  },
});

const result = streamText({
  stopWhen: stepCountIs(10),
  model: bashOnlyClaude("haiku"),
  prompt: "Can you show me the current date? Use the date command.",
});

let response = "";
for await (const chunk of result.textStream) {
  response += chunk;
}
console.log(response);

Expected Behavior

The model should:

1. Execute the Bash tool successfully
2. Display the date
3. Continue without errors

Actual Behavior

The model:

1. Executes the Bash tool successfully (gets the date)
2. Receives an error message: "Model tried to call unavailable tool 'Bash'. No tools are available."
3. Apologizes for not being able to use the tool it just successfully used

Output:

I'll run the date command for you.
The current date is Thursday, December 4, 2025 at 12:47:33 PST.

I apologize for the confusion. It appears that the Bash tool is not currently available in this context...

Debug Output

Tool call events show the problem:

{
  "type": "tool-call",
  "toolCallId": "toolu_01J6t3ADEiYLe1Bct6TdmoLq",
  "toolName": "Bash",
  "dynamic": true,
  "invalid": true,  // ← Incorrectly marked as invalid
  "error": {
    "name": "AI_NoSuchToolError",
    "toolName": "Bash"
  }
}

{
  "type": "tool-result",
  "toolCallId": "toolu_01J6t3ADEiYLe1Bct6TdmoLq",
  "toolName": "Bash",
  "output": "Thu Dec  4 12:47:33 PST 2025",  // ← Tool executed successfully!
  "providerExecuted": true
}

Error message sent to model:

{
  "role": "tool",
  "content": [{
    "type": "tool-result",
    "toolCallId": "toolu_01J6t3ADEiYLe1Bct6TdmoLq",
    "toolName": "Bash",
    "output": {
      "type": "error-text",
      "value": "Model tried to call unavailable tool 'Bash'. No tools are available."
    }
  }]
}

Root Cause Analysis

The issue is in parseToolCall function (src/generate-text/parse-tool-call.ts, built to dist/index.mjs:1841-1896).

Current Code Flow

async function parseToolCall({ toolCall, tools, ... }) {
  try {
    if (tools == null) {
      throw new NoSuchToolError({ toolName: toolCall.toolName });
    }
    // Tries to validate ALL tool calls, including provider-executed ones
    return await doParseToolCall({ toolCall, tools });
  } catch (error) {
    // When validation fails, marks tool as invalid
    return {
      type: "tool-call",
      toolCallId: toolCall.toolCallId,
      toolName: toolCall.toolName,
      input,
      dynamic: true,
      invalid: true,  // ← Problem: marked invalid even though providerExecuted
      error,
      ...
    };
  }
}

The Problem

1. Provider emits tool call with providerExecuted: true and dynamic: true
2. AI SDK passes it to parseToolCall() without checking these flags
3. parseToolCall() tries to validate against user's tools map
4. Validation fails because provider-executed tools aren't in user's tools map
5. Tool marked as invalid: true
6. Later code (lines 2367-2379) filters for invalid && dynamic tools and creates error outputs
7. Error sent back to model, causing confusion

Proposed Fix

Skip validation for provider-executed tools:

async function parseToolCall({ toolCall, tools, ... }) {
  // Skip validation for provider-executed tools
  if (toolCall.providerExecuted === true) {
    const parsedInput = await safeParseJSON({ text: toolCall.input });
    return {
      type: "tool-call",
      toolCallId: toolCall.toolCallId,
      toolName: toolCall.toolName,
      input: parsedInput.success ? parsedInput.value : toolCall.input,
      dynamic: toolCall.dynamic,
      providerExecuted: true,
      providerMetadata: toolCall.providerMetadata
    };
  }

  // Existing validation logic for user-defined tools
  try {
    if (tools == null) {
      throw new NoSuchToolError({ toolName: toolCall.toolName });
    }
    return await doParseToolCall({ toolCall, tools });
  } catch (error) {
    ...
  }
}

Impact

• Affects all providers that use providerExecuted: true for built-in tools
• Only manifests when using step-based features (stepCountIs(), etc.) that trigger tool validation
• Does not affect simple streaming without step management
• Causes confusing UX where models apologize for successfully used tools

Related Issues

• Similar to Error when streaming response that call OAI-provided search tool #10472 (OpenAI web search tool validation)
• Related to ModelMessage triggers UIMessage error if tool call parts include providerExecuted: null #8061 (providerExecuted field handling)
• Related to Incorrect validation workflow for tool_use parameters in generateText #5104 (tool validation workflow)
• Related to ai-sdk-provider-claude-code issue LangChainStream shouldn't close on LLMEnd #63

Additional Context

The provider correctly sets both providerExecuted: true and dynamic: true as specified in the AI SDK v3 protocol. The issue is purely in the SDK's validation logic not respecting these flags before attempting validation.

Sources:

• Error when streaming response that call OAI-provided search tool · Issue #10472
• ModelMessage triggers UIMessage error if tool call parts include providerExecuted: null · Issue #8061
• Incorrect validation workflow for tool_use parameters in generateText · Issue #5104

[pablof7z]

Update: Fix Already Exists in v6, Needs Backport to v5

After investigating this issue, I discovered that the fix already exists in the main branch (v6-beta) as of commit b67d224 (PR #10734, merged Dec 1st).

The Fix

The source code in main already includes logic to handle provider-executed dynamic tools:

• Lines 31-33 in parse-tool-call.ts: Check when tools == null
• Lines 137-139: Check when tool not found in tools map
• Helper function parseProviderExecutedDynamicToolCall handles these tools

The Problem

This fix is only available in v6.0.0-beta releases, not in the stable v5.0.106 that users are currently using.

The Solution

I've created PR #10890 to backport this fix to the release-v5.0 branch. Once merged and released, users on v5.x will get the fix without needing to upgrade to v6-beta.

Workaround

Until the fix is released in v5, users can apply this local patch:

• Patch file: https://github.com/pablof7z/123/blob/main/patches/ai%2B5.0.106.patch
• Instructions: https://github.com/pablof7z/123/blob/main/patches/README.md

References

• Original fix in v6: fix(ai): provider metadata propagation for provider-executed tool results #10734 (b67d224)
• Backport PR for v5: fix(ai): skip validation for provider-executed dynamic tools in v5 #10890
• Working patch example: https://github.com/pablof7z/123

[ben-vargas]

Thanks for reporting @pablof7z - I ran into this issue myself and decided to search before reporting.

Vercel team - if there's any component of the fix that should be implemented on the ai-sdk-provider-claude-code I'm happy to incorporate that as maintainer of that community provider. Otherwise, it would be super nice if this v6 feature was back-ported to ai sdk v5 as in my case I'm using vercel/workflow which doesn't have ai sdk v6 beta support yet.

[lgrammel]

Identify issue type

{
  "evidence": [
    "Reporter describes AI SDK v5.0.106 `parseToolCall` marking provider-executed tools as `invalid: true` even though the tool executes successfully.",
    "Actual behavior includes an erroneous \"Model tried to call unavailable tool 'Bash'\" message sent back to the model after a successful Bash tool result.",
    "The issue identifies current validation logic not respecting `providerExecuted: true` and proposes skipping validation for those tool calls.",
    "A follow-up comment says the fix already exists in v6 beta and needs backporting to v5; another user confirms encountering the same issue."
  ],
  "rationale": "The issue reports a concrete incorrect behavior in the existing SDK: provider-executed tool calls are validated as unavailable and produce invalid tool errors despite succeeding. This is a current behavior failure, not merely a request for new functionality.",
  "type": "bug",
  "confidence": "high"
}