Further split of this library into modules (e.g. api, client, server)

[morisil]

Is your feature request related to a problem? Please describe.
I want to use some of the MCP defined types as data transfer objects received in the kotlin multiplatform project with js targets. In general my clients don't care about the server transport part. The current structure of this projects forces me to also depend on server compontens from ktor.

Describe the solution you'd like
This project can be split into multimodule multiplatform project, where types API is kept as a separate module.

Describe alternatives you've considered
I guess an alternative would be dependency exclusions.

[morisil]

BTW I would be happy to contribute a PR for this issue.

[EmptyDreams]

I strongly agree that splitting the SDK into multiple modules is a great idea! It would be even better if the server doesn’t have a strong dependency on Ktor and Kt Serialization.

My project isn’t built using Ktor or Kt Serialization, and introducing this dependency would force me to pull in a lot of redundant dependencies, causing our server’s binary size to bloat rapidly.

I’m somewhat of a perfectionist—having multiple dependencies with the same functionality or unused dependencies in the code really bothers me.

Just to add, the reason I mentioned hoping to avoid a strong dependency on Ktor is that I want to embed MCP into the current server process rather than running it as a separate process. If it were a separate process, I’d have to write additional code for inter-process communication.

[morisil]

I already did the split in my local code base, but didn't have time to prepare a PR. Technically the API module can be split from the ktor dependency, but I cannot imagine it being split out of the kotlinx-serialization, as generating serializers is a part of the API compilation process. It shouldn't be a big issue though, as kotlinx-serialization is supporting all the platforms.

[EmptyDreams]

but I cannot imagine it being split out of the kotlinx-serialization, as generating serializers is a part of the API compilation process.

Yes, this is an issue. Many JSON frameworks rely on annotations to work, making it difficult to maintain compatibility across multiple frameworks.