Allow strict validation of CallToolResult.content during deserialization #1148

Using mcp-core:2.0.1 on Java 17, we noticed that a tools/call response without content is accepted and converted to a result with an empty content list.

Initialization and tool discovery complete normally. The negotiated protocol version is 2025-11-25.

Example

The server returns this response, with an ID matching the tool request:

{
  "jsonrpc": "2.0",
  "id": "request-2",
  "result": {
    "isError": false
  }
}

CallToolResult.fromJson logs a warning and replaces the missing content with List.of().

The application then receives the same result it would get from this valid response:

{
  "jsonrpc": "2.0",
  "id": "request-2",
  "result": {
    "content": [],
    "isError": false
  }
}

In our integration, the first response was recorded as a successful tool call with empty output and passed to the model. The application could no longer tell that a required field had been missing.

Request

I understand that this is intentional for compatibility, as described in the migration guide. Could the SDK provide an opt-in strict mode that validates required fields before substituting defaults?

For CallToolResult.content, that mode would reject a missing field or explicit null, while still accepting an explicit empty array. Valid text and structured results would continue to work.

Rejecting empty lists in the application isn't a solution, because content: [] is valid. We need to distinguish it from a missing field before that information is lost.

Is there already a supported way to enforce this validation? If not, a strict-mode option or a validation hook would help.

References:

• CallToolResult deserialization
• MCP 2025-11-25 CallToolResult schema
• 2.0 migration guide