feat(model): add json schema generation support for all model types #176
Conversation
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
shorwood
commented
May 14, 2025
crates/rmcp/src/model/extension.rs
Outdated
| } | ||
|
|
||
| fn json_schema(generator: &mut schemars::SchemaGenerator) -> schemars::schema::Schema { | ||
| generator.subschema_for::<serde_json::Value>() |
Contributor
Author
There was a problem hiding this comment.
Unsure about this, feel free to suggest improvements.
Collaborator
There was a problem hiding this comment.
There's no need to implement JsonSchema for extensions.
Contributor
Author
There was a problem hiding this comment.
You're right, I adjusted some models like so:
#[schemars(skip)]
pub extensions: Extensions,Ok with this ?
shorwood
force-pushed
the
shorwood/schemars-json-schema
branch
from
3c6ebb4 to
330dfc4
Compare
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR implements JSON Schema support for all model types by adding the schemars::JsonSchema derive where applicable and updating tests to verify schema generation.
- Adds JSON Schema derivations on all model structs and enums via cfg_attr.
- Introduces new tests that compare generated schema against expected JSON files.
- Updates Cargo.toml to include schemars with additional features and test configuration.
Reviewed Changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| crates/rmcp/tests/test_message_schema.rs | Adds tests for JSON schema generation of client/server JSON-RPC messages. |
| crates/rmcp/src/model/* | Updates model definitions to derive JsonSchema when the schemars feature is enabled. |
| crates/rmcp/Cargo.toml | Adds and configures the schemars dependency with extra features. |
| README.md | Documents the newly added schemars feature. |
| let schema = schema_for!(ClientJsonRpcMessage); | ||
| let schema_str = serde_json::to_string_pretty(&schema).unwrap(); | ||
| let expected = std::fs::read_to_string("tests/test_message_schema/client_json_rpc_message_schema.json").unwrap(); | ||
| assert_eq!(schema_str, expected, "Schema generation for ClientJsonRpcMessage should match expected output"); |
There was a problem hiding this comment.
Comparing the formatted JSON schema as a string can be brittle due to potential whitespace or key ordering differences. Instead, parse both 'schema_str' and 'expected' into JSON values and compare those for a more robust test.
Suggested change
| assert_eq!(schema_str, expected, "Schema generation for ClientJsonRpcMessage should match expected output"); | |
| let schema_json: serde_json::Value = serde_json::from_str(&schema_str).unwrap(); | |
| let expected_json: serde_json::Value = serde_json::from_str(&expected).unwrap(); | |
| assert_eq!(schema_json, expected_json, "Schema generation for ClientJsonRpcMessage should match expected output"); |
Collaborator
|
Looks good to me. Just need to fix CI and suggestions from coplilot, please. |
This commit adds JSON Schema support for all model types by implementing `schemars::JsonSchema` trait. The feature is gated behind the new `schemars` feature flag. This enables automatic schema generation for API documentation and validation purposes. Added tests to verify schema generation for client and server JSON-RPC messages.
This commit adds a manual implementation of `JsonSchema` trait for the `NumberOrString` enum to properly represent its union type nature in JSON Schema. The schema now correctly specifies that the type can be either a number or a string using the `oneOf` validation keyword.
shorwood
force-pushed
the
shorwood/schemars-json-schema
branch
from
f7c895a to
35976a6
Compare
The `Extensions` type was incorrectly included in JSON schema generation, which could lead to confusing API documentation. This commit adds `#[schemars(skip)]` attribute to all `extensions` fields in request and notification structs, and removes the manual `JsonSchema` implementation for the `Extensions` type since it's an internal implementation detail that shouldn't be exposed in the schema.
shorwood
force-pushed
the
shorwood/schemars-json-schema
branch
from
35976a6 to
e211254
Compare
4t145
approved these changes
May 15, 2025
Collaborator
|
Merged, thank you for PR! |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This commit adds JSON Schema support for all model types by implementing
schemars::JsonSchematrait. The feature is gated behind the newschemarsfeature flag. This enables automatic schema generation for API documentation and validation purposes. Added tests to verify schema generation for client and server JSON-RPC messages.Motivation and Context
This change facilitates schema-driven tooling, enabling better API validation, documentation generation, and integration with OpenAPI-based systems. It addresses the need for structured metadata across all model types.
How Has This Been Tested?
Breaking Changes
No breaking changes. The new feature is opt-in and does not affect default builds.
Types of changes
Checklist
Additional context
The
schemarsfeature is isolated for minimal impact. Feel free to suggest improvements or additional test scenarios.