MCP Kotlin SDK: an MCP client and server library for JVM, Native, JS and Wasm

What the MCP Kotlin SDK is for in a Kotlin codebase

Model Context Protocol standardises how an application hands context to a language model, keeping the context provider separate from the model interaction itself. The Kotlin SDK is the implementation of that specification for Kotlin, maintained in collaboration with JetBrains. It exists on both sides of the wire: you can build an MCP client that talks to any MCP server, or an MCP server that exposes resources, prompts and tools to whatever client connects.

The audience is narrow but real. If your product is Kotlin and you want the model-facing surface of it written in the same language as the rest of the stack, this removes the need to shell out to a Node or Python MCP process. The README also targets JVM, Native, JS and Wasm from one codebase, which matters for teams using Kotlin Multiplatform rather than plain Android or server-side Kotlin.

The repository layout reflects that split. There are separate modules for kotlin-sdk-client, kotlin-sdk-server, kotlin-sdk-core and kotlin-sdk-testing, plus a kotlin-sdk umbrella module, so a client-only application does not have to pull in the server API.

How the SDK models MCP primitives and transports

The SDK separates what you expose from how the bytes travel. On the server side the README lists prompts, resources, tools, completion, logging and pagination as features; on the client side it lists roots and sampling. Capabilities are declared per side through ServerCapabilities and client capabilities, which is how an MCP peer learns what the other end supports before calling it.

Transports are a distinct layer. The README documents STDIO, Streamable HTTP, SSE and WebSocket, plus a ChannelTransport used for testing. That last one is the interesting design choice: because the transport is an interface rather than a hardcoded socket, the testing module can drive a client and server pair over in-memory channels without opening a port. The integration-test and conformance-test directories at the repository root suggest the project exercises both its own tests and the shared MCP conformance suite.

The API is coroutine-friendly. Client creation, connection and tool listing are suspend-based calls, which is why the quickstart wraps everything in runBlocking. If your application already runs on structured concurrency, the MCP session slots into the same scope rather than forcing a callback bridge.

Installing the SDK and listing tools from a first client

The artifacts live on Maven Central under the io.modelcontextprotocol group. Add the repository and the umbrella dependency, or pick the client-only or server-only artifact if you do not need both sides.

repositories {
    mavenCentral()
}

dependencies {
    implementation("io.modelcontextprotocol:kotlin-sdk:$mcpVersion")
}

The README does not pin a version number in the snippet; it points at the Maven Central badge for the latest one. In a Kotlin Multiplatform project the same coordinate goes into commonMain, and the README notes it works as a common dependency as well as a platform one.

One step is easy to miss. The SDK uses Ktor but does not add Ktor engine dependencies transitively, so you declare an engine yourself. For a client that means something like ktor-client-cio; for a server, ktor-server-netty or ktor-server-cio.

dependencies {
    implementation("io.ktor:ktor-client-cio:$ktorVersion")
    implementation("io.modelcontextprotocol:kotlin-sdk-client:$mcpVersion")
}

With dependencies in place, a minimal client installs the SSE plugin on an HttpClient, constructs a Client with an Implementation name and version, wraps a StreamableHttpClientTransport around the URL, calls connect, then listTools. The README's example defaults to http://localhost:3000/mcp when no argument is passed. What you should see is the tool list printed to stdout after the connection completes; if nothing prints, the server at that URL is the first thing to check, not the SDK.

Where the MCP Kotlin SDK is the wrong choice

The versioning is the first limitation. The most recent release in the repository is 0.15.0, published on 2026-07-28, preceded by 0.14.0 and 0.13.0 at roughly monthly intervals. A pre-1.0 library on that cadence means the API can move between minor versions, and code written against 0.13.0 is not guaranteed to compile against 0.15.0 without changes. Teams that need a frozen interface for a long-lived product should treat that as a real cost.

The Ktor engine requirement is a second friction point. Because engines are not transitive, every consuming project makes its own engine decision, and the README does not state which engines are supported on which of the four target platforms. A Wasm or Native target may not have the same engine options as the JVM, and the README is silent on that mapping.

Finally, the licence metadata on the repository is NOASSERTION even though the README badge and the LICENSE file point to Apache 2.0. That mismatch is worth resolving before a legal review rather than during one. None of this makes the SDK unsuitable; it makes it a dependency you pin deliberately.

How it compares with the official TypeScript and Python SDKs

The Model Context Protocol project publishes reference SDKs in other languages, and the difference is less about protocol coverage than about where the code runs. The TypeScript SDK targets Node and browser runtimes, and the Python SDK targets CPython. Both are natural fits when the surrounding application is already JavaScript or Python, and both can be launched as a subprocess by an MCP host that speaks stdio.

The Kotlin SDK's distinguishing property is the multiplatform target set. A single commonMain dependency can compile toward JVM, Native, JS and Wasm, which none of the scripting-language SDKs offer because their runtimes do not exist in those places. That matters if the MCP server or client is a component inside a larger Kotlin Multiplatform application rather than a standalone process.

The trade-off runs the other way too. Choosing the Kotlin SDK means accepting a pre-1.0 API and managing Ktor engines, while the scripting SDKs are consumed through a package manager with no engine decision at all. If your MCP surface is a small sidecar, a Node or Python process may be less work than a new Gradle module.

Maintenance signals, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10, which is recent. Releases have landed at a steady pace through 2026: 0.13.0 on 2026-06-02, 0.14.0 on 2026-06-30, and 0.15.0 on 2026-07-28. That pattern suggests active work rather than a project parked after an initial push, though the pre-1.0 version number still governs how you should plan upgrades.

Upgrade cost concentrates in two places. The first is the SDK version itself, since minor releases may change API. The second is Ktor, because the SDK does not pin an engine for you and a Ktor major upgrade can ripple through your own dependency declarations. The README and the release notes do not document a migration or rollback procedure, so pinning both mcpVersion and ktorVersion in your build is the practical safeguard.

On licensing, the README badge and the LICENSE file indicate Apache 2.0, while the repository metadata reports NOASSERTION. Apache 2.0 is permissive and includes a patent grant, but the discrepancy between the two signals is something to confirm with whoever handles licensing on your side. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt the MCP Kotlin SDK when you already build on Kotlin and want MCP client or server code in the same codebase, particularly if you target more than one platform. Skip it if you need a stable 1.0 API surface, since the 0.15.0 release of 2026-07-28 shows the versioning is still pre-1.0, or if you are not on Kotlin at all. Before writing production code, check the LICENSE file against the repository's NOASSERTION licence metadata, and confirm whether the transport you need is documented for your target platform, since the README documents the transports but not their per-platform availability.

Frequently asked questions

Official sources

1. Issues
2. modelcontextprotocol/kotlin-sdk on GitHub
3. Project website
4. README
5. Releases