Skip to content

Allow strict validation of CallToolResult.content during deserialization #1148

Description

@kele5555

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:

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Nice to haves, rare edge casesarea/client

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions