Skip to content

fix: handle unknown tool calls gracefully instead of failing#8183

Closed
xr843 wants to merge 1 commit intoblock:mainfrom
xr843:fix/handle-unknown-tool-calls-gracefully
Closed

fix: handle unknown tool calls gracefully instead of failing#8183
xr843 wants to merge 1 commit intoblock:mainfrom
xr843:fix/handle-unknown-tool-calls-gracefully

Conversation

@xr843
Copy link
Copy Markdown

@xr843 xr843 commented Mar 29, 2026

Summary

Fixes #8166

When a model emits a tool call for a non-existent tool (e.g. read_file, view_file, run_command), goose currently returns a generic "Tool 'X' not found" error. While this error is sent back to the model as a tool response, the message lacks context to help the model self-correct, often causing repeated failures and task interruption.

This PR enhances the error handling in resolve_tool to:

  • Include available tool names in the error message so the model can pick a valid tool on retry
  • Add telemetry logging (monotonic_counter.goose.unknown_tool_calls) to track unknown tool call rates by provider/model

Before

Tool 'read_file' not found

After

Tool 'read_file' not found. Available tools: [developer__text_editor, developer__shell, ...]. Please use one of these tools instead.

The existing error flow is preserved — ErrorData with RESOURCE_NOT_FOUND code is returned and serialized as a tool response to the model, allowing it to retry with a valid tool name.

Changed files

  • crates/goose/src/agents/extension_manager.rs — Enhanced resolve_tool() error path with available tool list and telemetry

Test plan

  • Existing test_dispatch_tool_call test continues to pass (error code unchanged)
  • Verify the error message now includes available tool names when a non-existent tool is called
  • Manual test with a model that tends to hallucinate tool names (e.g. local models)

🤖 Generated with Claude Code

When a model emits a tool call for a non-existent tool, the error message
now includes the list of available tools so the model can self-correct
and retry with a valid tool name. Also adds telemetry logging for
unknown tool call rate tracking.

Fixes block#8166

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Signed-off-by: Tim Ren <[email protected]>
@xr843 xr843 force-pushed the fix/handle-unknown-tool-calls-gracefully branch from a64ed0e to e8e4cec Compare March 29, 2026 15:13
@DOsinga
Copy link
Copy Markdown
Collaborator

DOsinga commented Mar 30, 2026

Hi @xr843, thanks for the contribution! Unfortunately I'm going to close this one for now.

The main procedural issue is that as a first-time contributor, you've opened three PRs (#8181, #8182, #8183) in quick succession without waiting for any of them to land first. Our contributing guidelines ask that new contributors start with one PR and wait for it to go through review before opening more — see Pull Requests.

Beyond that, there are a few code-level concerns with this specific change:

  • Dumping the full list of available tool names into the error message could make it very long (there can be dozens of tools), which bloats the context the model sees on retry and is likely counterproductive.
  • The comment // Build a list of available tool names to help the model self-correct just restates what the code does.
  • The if !available_tool_names.is_empty() guard is unnecessary — if there are no tools at all, we wouldn't reach this code path.

We'd love to have you contribute! Please pick one of your open PRs to focus on, and feel free to open a discussion or issue first if you'd like feedback on the approach before writing code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unknown tool call is not guarded early (model calls non-existent tool despite provided tools)

2 participants