Repository navigation
fix: Remove JsonSchema and use a Map for inputSchema to support json schemas dialect - #749
Merged
Kehrlann merged 9 commits intoApr 10, 2026
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
Author
|
@tzolov conflicts have been resolved |
Sorry, something went wrong.
Kehrlann
requested changes
Apr 3, 2026
Kehrlann
left a comment
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Thank you for your contribution!
I'd like to make the transition path smoother, by keeping the JsonSchema type around.
Sorry, something went wrong.
Comment thread
mcp-test/src/test/java/io/modelcontextprotocol/spec/McpSchemaTests.java
Outdated
Comment thread
mcp-test/src/test/java/io/modelcontextprotocol/spec/McpSchemaTests.java
Outdated
Signed-off-by: Daniel Garnier-Moiroux <git@garnier.wf>
Kehrlann
approved these changes
Apr 10, 2026
Kehrlann
left a comment
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Implemented changes.
Sorry, something went wrong.
ashakirin
pushed a commit
to ashakirin/java-sdk
that referenced
this pull request
Apr 10, 2026
…schemas dialect (modelcontextprotocol#749) * feat: remove JsonSchema an use a Map for inputSchema - Fixes modelcontextprotocol#886 Co-authored-by: Daniel Garnier-Moiroux <git@garnier.wf>
JohannesLichtenberger
pushed a commit
to sirixdb/sirix
that referenced
this pull request
Jul 27, 2026
The SDK dropped its JsonSchema record in 2.0 so that a tool's inputSchema can carry any JSON Schema dialect rather than the subset that record could express (modelcontextprotocol/java-sdk#749), which is what broke the Dependabot bump in #1144: SirixMcpServer.java:256: error: incompatible types: JsonSchema cannot be converted to Map<String,Object> The schema helper now builds the document as a plain map, and "required" is omitted rather than emitted empty for the one tool that takes no arguments. The test's local copy of the helper gets the same treatment. Nothing else in the 2.0 breaking-change list applies here: sirix-mcp is stdio-only, so the SSE deprecation and the transport-builder removals do not reach it, and the rest of the surface it uses is unchanged. Worth knowing before editing any of the fourteen schemas: since 2.0 the SDK validates this document against the 2020-12 meta-schema at registration time and validates incoming tool arguments against it, so a "required" naming a property that "properties" does not declare is now rejected rather than ignored. That is documented on the helper. Verified by reproducing the failure against 2.0.0 first, then fixing: sirix-mcp is 47 tests across 6 classes, 0 skipped, 0 failures, including McpServerE2ETest, which registers all 13 tools through the real SDK and runs full tool-call pipelines -- so registration-time schema validation and call-time argument validation both accept the new shape. Note that McpServerE2ETest carries its own copy of the tool registration rather than calling SirixMcpServer's, so that module's own fourteen call sites are compile-checked only. Both copies now use the identical shape.
JohannesLichtenberger
pushed a commit
to sirixdb/sirix
that referenced
this pull request
Jul 28, 2026
The SDK dropped its JsonSchema record in 2.0 so that a tool's inputSchema can carry any JSON Schema dialect rather than the subset that record could express (modelcontextprotocol/java-sdk#749), which is what broke the Dependabot bump in #1144: SirixMcpServer.java:256: error: incompatible types: JsonSchema cannot be converted to Map<String,Object> The schema helper now builds the document as a plain map, and "required" is omitted rather than emitted empty for the one tool that takes no arguments. The test's local copy of the helper gets the same treatment. Nothing else in the 2.0 breaking-change list applies here: sirix-mcp is stdio-only, so the SSE deprecation and the transport-builder removals do not reach it, and the rest of the surface it uses is unchanged. Worth knowing before editing any of the fourteen schemas: since 2.0 the SDK validates this document against the 2020-12 meta-schema at registration time and validates incoming tool arguments against it, so a "required" naming a property that "properties" does not declare is now rejected rather than ignored. That is documented on the helper. Verified by reproducing the failure against 2.0.0 first, then fixing: sirix-mcp is 47 tests across 6 classes, 0 skipped, 0 failures, including McpServerE2ETest, which registers all 13 tools through the real SDK and runs full tool-call pipelines -- so registration-time schema validation and call-time argument validation both accept the new shape. Note that McpServerE2ETest carries its own copy of the tool registration rather than calling SirixMcpServer's, so that module's own fourteen call sites are compile-checked only. Both copies now use the identical shape.
imuromtsev
added a commit
to explyt/java-sdk
that referenced
this pull request
Sep 29, 2026
fix: Accept any JSON Schema in Tool.inputSchema (backport upstream modelcontextprotocol#749)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Following the Model Context Protocol specification for JSON schemas usage, the schema should, by default follow the 2020-12 dialect: json-schema-2020-12 if no $schema specified.
Motivation and Context
The need for this change arose from the requirement for a tool that can handle one of two properties objects. This can be achieved by defining an inputSchema with oneOf at the top level, for example:
inputSchema: { type: object, oneOf: [ { properties: {}, required: ["test"] }, { properties: {}, required: ["test", "command"] } ] }The current state
The schema is currently deserialized to a JsonSchema record and ignores oneOf at the top level. A specific fix for this issue would be to add a new field to the JsonSchema record for oneOf; however, this approach does not scale well if additional top-level entries (such as allOf) are needed. This PR shifts to using a Map<String, Object> to deserialize the inputSchema
Next Steps and improvements
I suggest adding validation for schemas based on the schema specifications from the SDK, not only checking for serialization errors. This would help fail fast and provide feedback about any issues in the defined schemas.
How Has This Been Tested?
Existing Tests have been adjusted for these changes, and a new test has been introduced with json schemas that have oneOf at the top level to verify that deserialization do not ignore it.
Breaking Changes
Users would need to change the tool's inputSchema data type
Types of changes
Checklist
Additional context