It is primarily a tool design problem, and the reason is worth internalising: a model does not experience an error, it reads one.
When your tool returns an error object, that is just more text arriving in the context. There is no exception, no stack unwinding, nothing that stops execution. The model reads it, weighs it against everything else it has, and decides what to do next - and a model that has been asked to produce an answer is heavily inclined to produce one.
So the error has to be unambiguous enough that continuing is clearly wrong, which means:
Make failures loud in the text itself. Not a status field buried in a JSON blob. Something that reads as a failure: the word failed, what failed, and explicitly that the result is not available.
Say what to do. Errors that state the next action get acted on. Something like: this call failed, do not use a value for this field, tell the user the data could not be retrieved.
Never return a shape that looks like success. An error object with the same fields as a success response, with nulls or zeros in them, is an invitation to use them. This is the single most common cause of what you saw.
Distinguish empty from failed. No results found and could not check are completely different, and tools routinely return the same thing for both.