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.

[StefMa]

Hey @morisil
How is your process of splitting it up?
Do you need any help here?

The client has nothing to do with the server and vice versa. So it really makes sense to split it up.

I think we should be a bit pragmatic here and first getting in different module and then discuss which dependencies can be pulled out.

So if you have already something in place, feel free to share it. Maybe I find some time to work together with you on that, or take over of your a busy right know.

[morisil]

I will try to consult JetBrains folks first on this topic.