tool calling (re)design

Before submitting your bug report

• I've tried finding an answer on the Continue docs site
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

Description

Ok I have been struggling quite some time with tool calling and optimizing my own tools and even creating tool names that should catch hallucinated tool names.

First of I assume this error[1] comes from continue:

fs_delete failed because the arguments were invalid, with the following message: Tool fs_delete not found

Please try something else or request further instructions.

fs_grep failed because the arguments were invalid, with the following message: Tool fs_grep not found

Please try something else or request further instructions.

1. This should not come from continue but from the mcp. How can the mcp ever advise the model to try different command. This is frustrating tool calls because the model can't learn from the results.

2. I think there is something wrong with internal tools. I have the impression that they are still send in the context even if they are disabled. I have strange hallucinations constantly about ls, grep. I do not have these tools (enabled).

3. Even this error message is bad, why even mentioning "the arguments are invalid" it will only stimulate the model in trying with different arguments.

4. I would not be surprised if you have also errors in sending strings instead of numbers in some tool arguments

[1]
https://github.com/search?q=repo%3Acontinuedev%2Fcontinue+%22Please+try+something+else+or+request+further+instructions.%22&type=code
https://github.com/search?q=repo%3Acontinuedev%2Fcontinue+%22because+the+arguments+were+invalid%22&type=code

PS feature request gives 404

https://github.com/continuedev/continue/discussions

To reproduce

No response

Log output

No source files, tests, entry points, or reproduction steps are named. Start by tracing how Continue formats MCP tool errors and sends enabled tools to the model, then investigate the reported fs_delete/fs_grep messages and argument types. Done should include an agreed redesign covering error wording, disabled-tool exposure, and argument serialization.