Expose original tool name and client identifier in SyncMcpToolCallback’s & AsyncMcpToolCallback's ToolDefinition

[DannySortino]

Expected Behaviour

When calling toolCallbackProvider.getToolCallbacks(), each returned ToolCallback wraps a ToolDefinition that carries not only the prefixed MCP identifier but also retains:

• toolName — the unmodified name assigned via @tool(name=…) or ToolDefinition.builder().name(…).

• clientName — the raw MCP client name from ClientInfo.getName().

For Example:

ToolDefinition def = callback.getToolDefinition();
assertThat(def.getName()).isEqualTo("spring_ai_mcp_client_mcp_sum");
assertThat((ExtendedToolDefinition) def.getToolName()).isEqualTo("sum");
assertThat((ExtendedToolDefinition) def.getClientName()).isEqualTo("spring_ai_mcp_client");

This allows users to cast the standard ToolDefinition to an extended subtype (McpToolDefintiion):

McpToolDefinition ext = (McpToolDefinition) callback.getToolDefinition();

String toolName = ext.getToolName();
String clientName  = ext.getClientName();

Existing code that only calls getName(), getDescription(), etc., continues to work unchanged.

Current Behaviour

Currently, SyncMcpToolCallback.getToolDefinition() and AsyncMcpToolCallback.getToolDefinition() always builds a DefaultToolDefinition whose .name() is computed via:

McpToolUtils.prefixedToolName(clientInfo.getName(), tool.name())

All other fields (description, inputSchema) mirror the annotation or builder settings. There is no way to recover the raw, un‑prefixed tool.name() or the original clientInfo.getName() once they’ve been combined and potentially truncated to fit the 64‑character limit. As a result, users who need to look up callbacks by logical name or inspect client metadata must re‑derive or guess them from the mangled name() value.

Context

Use case: In our integration we dynamically look up and invoke tools via ToolCallbackProvider by matching against the original tool name (e.g. "sum"). Because the MCP identifier is auto‑prefixed and truncated unpredictably at 64 characters, our lookup logic becomes brittle and requires string gymnastics.

Impact: Adding explicit fields for original ToolName and clientName in the ToolDefinition would eliminate the need for regex parsing or manual name reconstruction, making code tool lookup robust and future‑proof.