#3915 This submission may cause a MCP tool execution exception, resulting in the abandonment of all tool results.

[Harder-Better-Faster-Stronger]

Bug description
In Spring AI 1.0.2 (with submission #3915), when the LLM attempts to call multiple tools simultaneously, if any one of the tools throws an exception (such as response too large, timeout, etc.), the entire executeToolCalls method fails to handle the exception on a per-tool basis. As a result, all tool responses — including those from successfully completed tools — are discarded.

Environment
Spring AI version: 1.0.2
Java version: 21
Additional Context

Expected behavior
Each tool call should be executed and handled independently. Even if one or more tool calls fail, the results of successfully completed tool calls should be returned to the LLM for further processing.

Related code

    public ToolExecutionResult executeToolCalls(Prompt prompt, ChatResponse chatResponse) {
        Assert.notNull(prompt, "prompt cannot be null");
        Assert.notNull(chatResponse, "chatResponse cannot be null");
        Optional<Generation> toolCallGeneration = chatResponse.getResults().stream().filter((g) -> !CollectionUtils.isEmpty(g.getOutput().getToolCalls())).findFirst();
        if (toolCallGeneration.isEmpty()) {
            throw new IllegalStateException("No tool call requested by the chat model");
        } else {
            AssistantMessage assistantMessage = ((Generation)toolCallGeneration.get()).getOutput();
            ToolContext toolContext = buildToolContext(prompt, assistantMessage);
            InternalToolExecutionResult internalToolExecutionResult = this.executeToolCall(prompt, assistantMessage, toolContext);
            List<Message> conversationHistory = this.buildConversationHistoryAfterToolExecution(prompt.getInstructions(), assistantMessage, internalToolExecutionResult.toolResponseMessage());
            return ToolExecutionResult.builder().conversationHistory(conversationHistory).returnDirect(internalToolExecutionResult.returnDirect()).build();
        }

[YunKuiLu]

Hi @Harder-Better-Faster-Stronger
I suggest your tool should wrap the checked exceptions thrown by the framework as RuntimeException before rethrowing them.
When wrapping checked exceptions, you can rephrase the exception message to make it easier for LLMs to understand the failure reason and generate helpful responses for users.

eg:

@Tool(description = "query weather")
public String queryWeather(@ToolParam(description = "city") String city) {
	try {
		// call rpc service...
		throw new IOException("RPC service call failed");
	}
	catch (IOException e) {
		throw new RuntimeException("Service unavailable, please ask the user to retry later");
	}
}

At the same time, I admit that currently Spring AI will fail the call when a tool directly throws ToolExecutionException with an Exception case. But since constructing ToolExecutionException requires ToolDefinition, users who use this approach are probably rare. However, I'll look into how to handle it.

@Tool(description = "query weather")
public String queryWeather(@ToolParam(description = "city") String city) {
	try {
		// call rpc service...
		throw new IOException("RPC service call failed");
	}
	catch (IOException e) {
		throw new ToolExecutionException(this.toolDefinition, e);
	}
}

---

If I misunderstood your case, please help me clarify.