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:
Using
mcp-core:2.0.1on Java 17, we noticed that atools/callresponse withoutcontentis 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.fromJsonlogs a warning and replaces the missingcontentwithList.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 explicitnull, 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: