Skip to content

Conversation

tzolov
Copy link
Collaborator

@tzolov tzolov commented Sep 10, 2025

…ol callbacks

  • Introduce toolCallExceptionClass field to control which exceptions are converted to error results
  • Exceptions not matching the configured class are now propagated instead of being converted
  • O)veride the doGetToolCallException() to change the exceptin type converted into error result
  • Add overloaded constructors to maintain backward compatibility (default: Exception.class)
  • Modify exception handling logic in sync/async callbacks to check exception type before conversion
  • Exceptions not matching the configured class are now propagated instead of being converted
  • Extract common provider logic into new AbstractMcpToolProvider base class
  • Add ProvidrerUtils with predicates for reactive type checking
  • Include test coverage for exception handling scenarios

This change allows fine-grained control over exception handling behavior in MCP tool methods, enabling developers to distinguish (and define) between expected errors (converted to CallToolResult) and unexpected failures (propagated for higher-level handling).

…ol callbacks

- Introduce toolCallExceptionClass field to control which exceptions are converted to error results
- Exceptions not matching the configured class are now propagated instead of being converted
- O)veride the doGetToolCallException() to change the exceptin type converted into error result
- Add overloaded constructors to maintain backward compatibility (default: Exception.class)
- Modify exception handling logic in sync/async callbacks to check exception type before conversion
- Exceptions not matching the configured class are now propagated instead of being converted
- Extract common provider logic into new AbstractMcpToolProvider base class
- Add ProvidrerUtils with predicates for reactive type checking
- Include test coverage for exception handling scenarios

This change allows fine-grained control over exception handling behavior in MCP tool methods,
enabling developers to distinguish (and define) between expected errors (converted to CallToolResult) and
unexpected failures (propagated for higher-level handling).

Signed-off-by: Christian Tzolov <christian.tzolov@broadcom.com>
@tzolov tzolov merged commit 2850207 into spring-ai-community:main Sep 12, 2025
1 check passed
@tzolov tzolov added this to the 0.4.0 milestone Sep 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant