Skip to content

feat!: guard required MCP spec fields against null#928

Draft
chemicL wants to merge 3 commits intojson-compatibilityfrom
json-schema-required-fields
Draft

feat!: guard required MCP spec fields against null#928
chemicL wants to merge 3 commits intojson-compatibilityfrom
json-schema-required-fields

Conversation

@chemicL
Copy link
Copy Markdown
Member

@chemicL chemicL commented Apr 20, 2026

Compact canonical constructors with Assert.notNull are added to seven records:

  • JSONRPCError (code, message),
  • ProgressNotification (progressToken, progress),
  • LoggingMessageNotification (level, data),
  • CreateMessageRequest (messages, maxTokens),
  • CallToolResult (content),
  • SamplingMessage (role, content),
  • ElicitRequest (message, requestedSchema).

This PR is stacked on top of #927

Motivation and Context

Records in McpSchema whose fields the MCP spec marks as required were storing them as nullable Java types with no validation. A caller constructing one of these records with null for a required field would silently produce invalid wire JSON because @JsonInclude(NON_ABSENT) omits null values without complaint.

How Has This Been Tested?

Test code that constructed these records without required fields was updated to supply valid values; those tests were testing capability-check or error-path logic that fires after construction, so the missing fields were incidental rather than intentional.

Breaking Changes

Behavioural - validation failures for required fields that turn out to be null or missing.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Records in McpSchema whose fields the MCP spec marks as required were
storing them as nullable Java types with no validation. A caller
constructing one of these records with null for a required field would
silently produce invalid wire JSON because @JsonInclude(NON_ABSENT) omits
null values without complaint.

Compact canonical constructors with Assert.notNull are added to seven
records:
- JSONRPCError (code, message),
- ProgressNotification (progressToken, progress),
- LoggingMessageNotification (level, data),
- CreateMessageRequest (messages, maxTokens),
- CallToolResult (content),
- SamplingMessage (role, content),
- ElicitRequest (message, requestedSchema).

Test code that constructed these records without required fields was
updated to supply valid values; those tests were testing capability-check
or error-path logic that fires after construction, so the missing fields
were incidental rather than intentional.

Signed-off-by: Dariusz Jędrzejczyk <2554306+chemicL@users.noreply.github.com>
Signed-off-by: Dariusz Jędrzejczyk <2554306+chemicL@users.noreply.github.com>
@chemicL chemicL marked this pull request as draft April 20, 2026 17:32
Deprecate no-arg builder() factories and Builder() constructors on
CreateMessageRequest, ElicitRequest, and LoggingMessageNotification.
Add new builder(required...) factories that validate required fields
upfront. Add new builders for ProgressNotification and JSONRPCError.
Null checks in private constructors and required-field setters ensure
invalid state cannot be introduced at any point in the builder chain.

Signed-off-by: Dariusz Jędrzejczyk <2554306+chemicL@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant