CallToolResponse isError is optional in spec, but not in SDK

[nictownsend]

https://modelcontextprotocol.io/specification/2025-06-18/schema#calltoolresult

isError?: boolean
Whether the tool call ended in an error.

If not set, this is assumed to be false (the call was successful).

However -

java-sdk/mcp-core/src/main/java/io/modelcontextprotocol/spec/McpSchema.java

Line 3333 in 8ee8ccb

Assert.notNull(isError, "isError must not be null");

invoked by

java-sdk/mcp-core/src/main/java/io/modelcontextprotocol/spec/McpSchema.java

Line 3216 in 8ee8ccb

@JsonProperty("isError") Boolean isError, @JsonProperty("structuredContent") Object structuredContent,

do not treat the JSON property as optional.

I found this when trying to connect to https://docs.confluent.io/cloud/current/ai/ai-tools/managed-mcp-server.html#global-and-regional-mcp-servers - https://api.confluent.cloud/mcp/v1 using

final HttpClientStreamableHttpTransport.Builder transportBuilder =
            HttpClientStreamableHttpTransport.builder(url).endpoint(url)
                        .clientBuilder(httpClientBuilder);

Note .endpoint(url) needed because the confluent servers don't end in /mcp

[Ehtasham-Yasin]

Hi, I’d like to work on this issue. I’ll keep the change focused on treating an omitted isError as false and adding regression coverage.

[ZYZ666-RGB]

Hi maintainers, I'd like to work on this issue.

I verified that McpSchema.CallToolResult currently receives a missing JSON isError property as null, while its construction path rejects that value even though the MCP schema defines the field as optional and defaults it to false.

My plan is to:

• normalize an omitted isError value to false at the schema/deserialization boundary;
• preserve explicit true and false values;
• avoid changing the public JSON shape or unrelated tool-result behavior;
• add focused Jackson tests for omitted, explicit-false, and explicit-true cases;
• run the affected core and client test suites and verify source compatibility.

Please let me know if you prefer keeping the nullable Boolean API with constructor normalization, or changing it to primitive boolean. I favor the smaller normalization change unless there is a broader schema-modeling convention to follow.

[ZYZ666-RGB]

Thanks. I need to step back from this issue for now so it remains available to other contributors.