FEAT: Support almost all Tier 1, 2 and 3 Kotlin targets

[nomisRev]

• Support all Tier 1, 2 and 3 targets by Kotlin.
• Remove dependency on Kotest Json due to not supporting all targets

Motivation and Context

Make the library available for as many targets as possible as recommended in the official library author's guidelines.

How Has This Been Tested?

Same use-cases as other MCP servers, not tested on actual devices.

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

Additional context

/

[devcrocod]

Hi @nomisRev,
Thanks for your contribution!

I’ve reverted your changes for now for two reasons:

• The test is failing on macOS ARM
• I’m currently working on publishing a new release, and there are issues with the current klibs and publishing process

I also have some concerns about adding all targets:

• It increases the build requirements. For example, building and testing requires the tvos sdk
• It’ll limit us in the future, as we might be restricted when adding new libraries to the project

I think we can revisit the idea of adding more targets after we split the sdk into client and server #110
What do you think?

[nomisRev]

I’m currently working on publishing a new release, and there are issues with the current klibs and publishing process

Yes, I noticed we don't follow the same publishing setup as we do in most other Kotlin projects. Any strong reason to use JReleaser instead of the official recommended gradle-maven-publish-plugin?

It increases the build requirements. For example, building and testing requires the tvOS sdk

Those are indeed the trade-offs of supporting more targets, but I strongly feel we should follow our own recommendations..

It’ll limit us in the future, as we might be restricted when adding new libraries to the project

Since this is an SDK, we should try to refrain from adding dependencies altogether. Unless perhaps essential dependencies like Ktor, or KotlinX. The KMP ecosystem should already have everything we need to properly support MCP on all these targets.

I think we can revisit the idea of adding more targets after we split the sdk into client and server #110
What do you think?

Any updates on this front? I see 110 closed in favour of 33, and a closed PR 😅 Adding targets shouldn't really affect the client / server split. Why is adding targets a blocker?

The test is failing on macOS ARM

We need to investigate, and report the issues to Kotlin, Ktor, or somewhere else if there is any.

[devcrocod]

Yes, I noticed we don't follow the same publishing setup as we do in most other Kotlin projects. Any strong reason to use JReleaser instead of the official recommended gradle-maven-publish-plugin?

Is it officially recommended by Kotlin? Because from what I see, sonatype actually recommends using jreleaser.

To be honest, I’m not sure why we switched to JReleaser, initially we were using gradle-maven-publish. That said, I’m not planning to switch away from jreleaser for now, since the issues we had with it have been resolved.

Since this is an SDK, we should try to refrain from adding dependencies altogether. Unless perhaps essential dependencies like Ktor, or KotlinX. The KMP ecosystem should already have everything we need to properly support MCP on all these targets.

Agreed, but I would still take that risk into accountб it depends on how the specification evolves.

Any updates on this front? I see 110 closed in favour of 33, and a closed PR 😅 Adding targets shouldn't really affect the client / server split. Why is adding targets a blocker?

There are no blockers here. In my opinion, this approach will be simpler. I’ll be able to move and clean up the scripts in buildSrc, set up builds for specific targets, and split the tests.

At the moment, we’re planning to change the Server implementation #198. After that, I’ll start working on the tasks you mentioned

[nomisRev]

Is it officially recommended by Kotlin? Because from what I see, sonatype actually recommends using jreleaser.

It's in our official documentation, and it's what most Kotlin libraries have converged to using. Including Ktor. The Sonatype recommendation is for JVM, not KMP specifically which has quite a lot of other complexities but very glad to hear JReleaser is working fine as well 👍

Agreed, but I would still take that risk into accountб it depends on how the specification evolves.

Is there anything concrete why you wouldn't want to add more targets? Like anything in the MCP specification that indicates the project might have to introduce an external dependency for something we otherwise cannot easily support in Kotlin relying only on Ktor, or KotlinX?

At the moment, we’re planning to change the Server implementation #198. After that, I’ll start working on the tasks you mentioned

Awesome, looking forward to this progress 👍