[Bug - MCP server] @McpTool error messages are emitted twice when the thrown exception has no cause

[ReuDa]

Bug description

The @McpTool method callbacks build their error text by concatenating the exception's message with its root cause's message:

// AbstractSyncMcpToolMethodCallback#createSyncErrorResult
protected CallToolResult createSyncErrorResult(Exception e) {
    Throwable rootCause = findCauseUsingPlainJava(e);
    return CallToolResult.builder()
        .isError(true)
        .addTextContent(e.getMessage() + System.lineSeparator() + rootCause.getMessage())
        .build();
}

findCauseUsingPlainJava starts from the throwable itself and only walks getCause():

Throwable rootCause = throwable;
while (rootCause.getCause() != null && rootCause.getCause() != rootCause) {
    rootCause = rootCause.getCause();
}
return rootCause;

So for an exception with no cause it returns the exception itself, rootCause.getMessage() is the same string as e.getMessage(), and the client receives every such error twice, separated by a line separator.

This affects the most ordinary case there is: a tool that validates its own input and throws a bare IllegalArgumentException carrying an actionable message.

Affected paths:

• SyncMcpToolMethodCallback / SyncStatelessMcpToolMethodCallback → AbstractSyncMcpToolMethodCallback#createSyncErrorResult
• AsyncMcpToolMethodCallback / AsyncStatelessMcpToolMethodCallback → AbstractAsyncMcpToolMethodCallback#createAsyncErrorResult (identical concatenation)

Tool methods that return a reactive type take a different path — AbstractAsyncMcpToolMethodCallback#toErrorResultOrPropagate — which emits the message once, as "Error invoking method: %s". So the same server currently formats tool errors two different ways depending on a tool's return type, and only one of them duplicates.

Environment

Spring AI 2.0.1. Also verified still present on main (AbstractSyncMcpToolMethodCallback.java is unchanged), so this is not fixed by upgrading.

For context: #6456 / #6534 reworked which exceptions reach createSyncErrorResult (McpError and UndeclaredThrowableException now propagate instead of being converted), but left the message construction untouched.

Steps to reproduce

@Service
public class ToolService {

    @McpTool(name = "find_thing", description = "Looks something up")
    public String findThing(String name) {
        throw new IllegalArgumentException("No thing named '" + name + "' found. Use list_things to see valid names.");
    }
}

Call the tool. content[0].text is:

No thing named 'x' found. Use list_things to see valid names.
No thing named 'x' found. Use list_things to see valid names.

Expected behavior

The message once:

No thing named 'x' found. Use list_things to see valid names.

Appending the root cause is genuinely useful when the thrown exception wraps another, so the fix is to append it only when it adds information — e.g.:

protected CallToolResult createSyncErrorResult(Exception e) {
    Throwable rootCause = findCauseUsingPlainJava(e);
    String text = (rootCause == e || Objects.equals(rootCause.getMessage(), e.getMessage()))
            ? e.getMessage()
            : e.getMessage() + System.lineSeparator() + rootCause.getMessage();
    return CallToolResult.builder().isError(true).addTextContent(text).build();
}

and the same in createAsyncErrorResult.

[CryoThrust]

This looks like a focused MCP interoperability fix. The important invariant is that adding a cause must never duplicate the same diagnostic, while wrapped exceptions should retain useful root-cause context. I would cover both sync and async callback paths with a small matrix: (1) exception with no cause, (2) cause with the same message, (3) distinct root-cause message, and (4) null outer/root messages. The assertions should inspect the actual CallToolResult text and also verify the reactive-return path keeps its existing single-message format, so the sync/async callbacks converge without changing error categorization.