Repository navigation
Add opt-in validation of required tool result content - #1149
kele5555 wants to merge 1 commit into
Conversation
Sorry, something went wrong.
|
One abstraction/coverage concern with the strict path: it now depends on the concrete shape returned by transport.unmarshalFrom(..., TypeRef<Object>). decodeToolResultWithContentValidation accepts only:
That is true for the Jackson configurations covered here, but McpClientTransport is mapper/transport-neutral and owns unmarshalFrom. A custom mapper/transport can legally materialize a different JSON-object/array representation for Object, which would make a valid CallToolResult fail strict validation before the normal typed conversion. Could we pin the intended contract with a mapper-neutral/custom-transport regression (and ideally normalize through an SDK JSON-object abstraction rather than concrete Java container classes)? At minimum, documenting that strict content validation requires TypeRef<Object> to materialize JSON objects as Map and arrays as List/Object[] would avoid a hidden transport requirement. This is opt-in, so it is not a default-path regression, but it is a new requirement on an otherwise transport-neutral client feature. AI-assisted review; checked the current head and McpClientTransport/McpClientSession path before posting. |
Sorry, something went wrong.
CallToolResult.fromJson replaces missing or null content with an empty list. Applications then cannot distinguish these responses from a valid content: [] result.
This adds validateCallToolResultContent(true) to the synchronous and asynchronous client builders. When enabled, callTool checks the raw result before converting it to CallToolResult, rejecting missing, null, or non-array content with IllegalArgumentException. An explicit empty array remains valid.
The option follows the existing McpClientFeatures.Sync/Async wiring. Validation accepts both List and Object[] representations of JSON arrays, including Jackson's USE_JAVA_ARRAY_FOR_JSON_ARRAY setting.
The option defaults to false, preserving the compatibility behavior introduced in #928. It is independent of tool output-schema validation and does not enable strict validation of other MCP messages. Validation failures do not retry the tool call or undo server-side effects.
Validation on Java 17, with both Jackson 2 and Jackson 3:
This is a proposed public API. Please confirm the scope and naming in the related enhancement issue before requesting review.
AI-assisted implementation, submitted for human review.
Fixes #1148