refactor: reformat McpSchema.java and reorganize imports

[tzolov]

• Remove unused imports (CallToolResult, TextContent)
• Standardize code formatting and indentation throughout
• Adjust formatter comments positioning
• Improve readability of record definitions and builder classes

Reformat McpSchema.java and reorganize imports for improved code consistency and readability

Motivation and Context

This change improves code maintainability and consistency by:

• Standardizing code formatting throughout the McpSchema.java file
• Organizing imports in a logical order (SLF4J imports moved to top)
• Removing unused imports to reduce clutter
• Ensuring consistent indentation and brace positioning across all record definitions and builder classes

How Has This Been Tested?

• Existing unit tests should continue to pass as no functional changes were made
• Code compilation verified to ensure no syntax errors introduced
• Import organization verified to maintain all necessary dependencies

Breaking Changes

No breaking changes - this is purely a formatting and import organization change with no functional modifications.

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

Additional context

This refactoring focuses solely on code style and organization:

• Applied consistent formatting to record definitions, builder classes, and enum declarations
• Adjusted @formatter:off/on comment positioning for better code structure
• Removed unused imports and Moved SLF4J Logger imports to the top of the import block for better organization
• No functional logic was modified, ensuring backward compatibility

[pantanurag555]

I think we should standardize the spacing before formatter comments across the file as well. Couldn't confirm that each instance of formatting was correct by taking a look but looks good for the most part. 1 question: Did we use ./mvnw spring-javaformat:apply to fix formatting or was it manual effort?

[pantanurag555]

Nit: Let's standardize either having a space or not before we write formatter on/off.

[tzolov]

Good point

[tzolov]

Thanks for the review @pantanurag555
I've updated the PR to put a single space in front of the on/off annotations.

Did we use ./mvnw spring-javaformat:apply to fix formatting or was it manual effort?

I did it by hand. But run the javaformat:apply after I moved the :on behind the record blocks to let their bodies get formatted by the rules.

Also, perhaps we can improve our format rules to remove trailing empty lines and add better rules for the import order and maybe prevent wildcard imports. Not sure how much of this is possible.

[YunKuiLu]

@tzolov
Could you provide a checkstyle.xml file in the project so we can unify the code style?
Thanks!

[LucaButBoring]

What are the // @formatter:on comments avoiding to begin with? Wouldn't it be better in the long run to adjust the formatter settings and rely purely on the formatter, whatever it happens to do? The point of a formatter is mostly to avoid needing to make these decisions on a case by case basis, even if it's imperfect sometimes.

[tzolov]

What are the // @formatter:on comments avoiding to begin with? Wouldn't it be better in the long run to adjust the formatter settings and rely purely on the formatter, whatever it happens to do? The point of a formatter is mostly to avoid needing to make these decisions on a case by case basis, even if it's imperfect sometimes.

The @formatter: are used to keep the record/enum fields (along with their jackson annotations) readable.
Perhaps this can be achieved with some formatter rules? I have not experience with this and have no time to explore it now.

[LucaButBoring]

I had a look at the spring-javaformat repo to see if there was documentation on this, but it looks like it isn't super customizable on its own. Doing any meaningful customization requires also adding Checkstyle and the Checkstyle plugin, it looks like.

Worth doing, but not a priority as I see it either, then. We have PRs waiting on this already, so something to revisit later. It'd be useful to at least set up a checkstyle.xml with the Spring config as a starting point, which would be a good fast-follow item.

[tzolov]

@LucaButBoring I agree that this needs to be addressed in a separate PR. Here is the ticket: #399

[tzolov]

rebased, squashed and merged at 8d71b76b21ec9179a1c4644710af08f2a33410cd