Prerelease 0.7.2-alpha1

[devcrocod]

Motivation and Context

• test new publish plugin
• add package.kt to kotlin-sdk umbrella module to resolve klib generation errors during Maven publishing

Breaking Changes

no

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

[Copilot]

Pull Request Overview

This PR updates the version number from a SNAPSHOT to a prerelease alpha version to test a new publish plugin.

• Updates the mcp-kotlin version from "0.7.2-SNAPSHOT" to "0.7.2-alpha1"

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[kpavlov]

👍

[kpavlov]

Thank you, @devcrocod, for tackling the publication work — I really appreciate the effort.

I’d like to ask whether we can remove the kotlin-sdk module now instead of keeping it. I understand why it was introduced and the maintenance involved, but in practice:

• It can unintentionally pull server dependencies into client applications (and vice versa), which is confusing for users. I believe users can figure out what dependency they need - client , server or both - and add apropriate dependency to their project.
• It commonly ends up as an unused transitive dependency.
• It increases Gradle configuration complexity without delivering clear value after the client/server split.

Could we make a separate PR that focuses on removing the module and the related Gradle/config changes? We could also keep the version bump in its own PR so each change has a single, clear purpose.

[devcrocod]

@kpavlov
I’d like to keep the kotlin-sdk until there’s a clear need to remove it

• we have a choice: the user can use either kotlin-sdk, or client, or server
• we maintain compatibility with older releases where there was only one kotlin-sdk
• this simplifies sdk usage for new users
• we stay consistent with other sdks that provide a single artifact

[kpavlov]

Let's merge to unblock the release, but I am not fully agree with your arguments