MCP100 verdict
Not currently recommended. Official Kotlin Multiplatform MCP SDK for implementing clients and servers across JVM, Native, JS, and Wasm. Capabilities: Build MCP clients and servers; Expose tools, resources, prompts, completion and logging; Use stdio, Streamable HTTP, SSE, WebSocket, and in-process test transports; Target JVM, Native, JS, and Wasm
MCP100 Assessment
Editorial verdict
Reviewed October 21, 2026
Task Fit
Mapped
Developer workflows
Trust
Status warning
maintenance_source_health; install_supply_chain; advisory_freshness; adoption_evidence_presence; resource_type_requirements
Maintenance
Date unavailable
No dated repository or package update is currently stored.
Popularity
Signals unavailable
No independently comparable adoption metric is currently stored.
Evidence scope
1.5k shared-repository stars · not MCP-specific
No MCP-specific package metric is stored
Repository identity: modelcontextprotocol/kotlin-sdk
Package identity: io.modelcontextprotocol:kotlin-sdk
Stars observed October 21, 2026 · Downloads observed October 21, 2026
Repository evidence: exact_resource_repo. Not MCP-specific/comparable for MCP-server adoption. Keep as SDK/resource, not server. SDK popularity must not enter MCP-server adoption ordering.
Package evidence: exact_sdk_artifact_no_comparable_public_download_metric. Not MCP-specific/comparable for MCP-server adoption. No attributable public download metric was verified. Keep as SDK/resource, not server. SDK popularity must not enter MCP-server adoption ordering.
Publisher activity observed October 21, 2026
Current source snapshot
Source relationship: First-party MCP
Reviewed October 21, 2026
Evidence-backed setup
This profile has type-appropriate, source-backed setup rather than an MCP-server client connector configuration.
Type-appropriate, source-backed setup for this sdk profile.
Capability
Official Kotlin Multiplatform MCP SDK for implementing clients and servers across JVM, Native, JS, and Wasm. Capabilities: Build MCP clients and servers; Expose tools, resources, prompts, completion and logging; Use stdio, Streamable HTTP, SSE, WebSocket, and in-process test transports; Target JVM, Native, JS, and Wasm
Not measured yet
Estimated token footprint of the MCP tool schemas exposed to the agent.
Reviewed access
Review the exact access boundary before connecting this MCP to accounts, credentials, or sensitive data.
Related reviewed MCPs
Retrieve current library and framework documentation for coding agents.
Choose this instead if
Choose Context7 MCP instead if current library and API documentation inside coding agents.
Retrieve current library and framework documentation for coding agents.
Discover and run MCP servers through Docker's MCP gateway.
Choose this instead if
Choose Docker MCP Gateway instead if running multiple MCP servers behind one stdio connection.
Discover and run MCP servers through Docker's MCP gateway.
Work with repositories, issues, pull requests, and GitHub workflows.
Choose this instead if
Choose GitHub MCP instead if repository, issue, pull-request, and code context.
Work with repositories, issues, pull requests, and GitHub workflows.
github:modelcontextprotocol is listed as First-party MCP in MCP100’s current evidence.
Current official resources:
Original product, capability, tool, and usage documentation from the MCP publisher. Installation sections appear under Install & Agents.
Kotlin Multiplatform SDK for the Model Context Protocol. It enables Kotlin applications targeting JVM, Native, JS, and Wasm to implement MCP clients and servers using a standardized protocol interface.
The Model Context Protocol allows applications to provide context for LLMs in a standardized way, separating the concerns of providing context from the actual LLM interaction. This Kotlin SDK implements the MCP specification, making it easy to:
The MCP protocol defines core primitives that enable communication between servers and clients:
| Primitive | Server Role | Client Role | Description |
|---|---|---|---|
| Prompts | Provides prompt templates with optional arguments | Requests and uses prompts | Interactive templates for LLM interactions |
| Resources | Exposes data sources (files, API responses, etc.) | Reads and subscribes to resources | Contextual data for augmenting LLM context |
| Tools | Defines executable functions | Calls tools to perform actions | Functions the LLM can invoke to take actions |
| Sampling | Requests LLM completions from client | Executes LLM calls and returns results | Server-initiated LLM requests (reverse direction) |
Capabilities define what features a server or client supports. They are declared during initialization and determine what operations are available.
Servers declare their capabilities to inform clients what features they provide:
| Capability | Feature Flags | Description |
|---|---|---|
prompts | listChanged | Prompt template management and notifications |
resources | subscribelistChanged | Resource exposure, subscriptions, and update notifications |
tools | listChanged | Tool discovery, execution, and list change notifications |
logging | - | Server logging to client console |
completions | - | Argument autocompletion suggestions |
experimental | Custom properties | Non-standard experimental features |
Clients declare their capabilities to inform servers what features they support:
| Capability | Feature Flags | Description |
|---|---|---|
sampling | - | Client can sample from an LLM (execute model requests) |
roots | listChanged | Client exposes root directories and can notify of changes |
elicitation | - | Client can display schema/form dialogs for structured input |
experimental | Custom properties | Non-standard experimental features |
The Server API lets you wire prompts, resources, and tools with only a few lines of Kotlin. Each feature is registered
up front and then resolved lazily when a client asks for it, so your handlers stay small and suspendable.
Prompts are user-controlled templates that clients discover via prompts/list and fetch with prompts/get when a user
chooses one (think slash commands or saved flows). They’re best for repeatable, structured starters rather than ad-hoc
model calls.
val server = Server(
serverInfo = Implementation(
name = "example-server",
version = "1.0.0"
),
options = ServerOptions(
capabilities = ServerCapabilities(
prompts = ServerCapabilities.Prompts(listChanged = true),
),
)
)
server.addPrompt(
name = "code-review",
description = "Ask the model to review a diff",
arguments = listOf(
PromptArgument(name = "diff", description = "Unified diff", required = true),
),
) { request ->
GetPromptResult(
description = "Quick code review helper",
messages = listOf(
PromptMessage(
role = Role.User,
content = TextContent(text = "Review this change:\n${request.arguments?.get("diff")}"),
),
),
)
}
Use prompts for anything that deserves a template: bug triage questions, onboarding checklists, or saved searches. Set
listChanged = true only if your prompt catalog can change at runtime and your server will emit
notifications/prompts/list_changed when it does.
Resources are application-driven context that clients discover via resources/list or resources/templates/list, then
fetch with resources/read. Register each one with a stable URI and return a ReadResourceResult when asked—contents
can be text or binary blobs.
val server = Server(
serverInfo = Implementation(
name = "example-server",
version = "1.0.0"
),
options = ServerOptions(
capabilities = ServerCapabilities(
resources = ServerCapabilities.Resources(subscribe = true, listChanged = true),
),
)
)
server.addResource(
uri = "note://release/latest",
name = "Release notes",
description = "Last deployment summary",
mimeType = "text/markdown",
) { request ->
ReadResourceResult(
contents = listOf(
TextResourceContents(
text = "Ship 42 reached production successfully.",
uri = request.uri,
mimeType = "text/markdown",
),
),
)
}
Resources can be static text, generated JSON, or blobs—anything the client can surface to the user or inject into the
model context. Set subscribe = true if you emit notifications/resources/updated for changes to specific URIs, and
listChanged = true if you’ll send notifications/resources/list_changed when the catalog itself changes.
Tools are model-controlled capabilities the client exposes to the model. Clients discover them via tools/list, invoke
them with tools/call, and your handlers receive JSON arguments, can emit streaming logs or progress, and return a
CallToolResult. Keep a human in the loop for sensitive operations.
val server = Server(
serverInfo = Implementation(
name = "example-server",
version = "1.0.0"
),
options = ServerOptions(
capabilities = ServerCapabilities(
tools = ServerCapabilities.Tools(listChanged = true),
),
)
)
server.addTool(
name = "echo",
description = "Return whatever the user sent back to them",
) { request ->
val text = request.arguments?.get("text")?.jsonPrimitive?.content ?: "(empty)"
CallToolResult(content = listOf(TextContent(text = "Echo: $text")))
}
Register as many tools as you need—long-running jobs can report progress via the request context, and tools can also
trigger sampling (see below) when they need the client’s LLM. Set listChanged = true only if your tool catalog can
change at runtime and your server will emit notifications/tools/list_changed when it does.
Completion provides argument suggestions for prompts or resource templates. Declare the completions capability and
handle completion/complete requests to return up to 100 ranked values (include total/hasMore if you paginate).
val server = Server(
serverInfo = Implementation(
name = "example-server",
version = "1.0.0"
),
options = ServerOptions(
capabilities = ServerCapabilities(
completions = ServerCapabilities.Completions,
),
)
)
val session = server.createSession(
StdioServerTransport(
input = System.`in`.asSource().buffered(),
output = System.out.asSink().buffered()
)
)
session.setRequestHandler<CompleteRequest>(Method.Defined.CompletionComplete) { request, _ ->
val options = listOf("kotlin", "compose", "coroutine")
val matches = options.filter { it.startsWith(request.argument.value.lowercase()) }
CompleteResult(
completion = CompleteResult.Completion(
values = matches.take(3),
total = matches.size,
hasMore = matches.size > 3,
),
)
}
Use context.arguments to refine suggestions for dependent fields (e.g., framework list filtered by chosen language).
Logging lets the server stream structured log notifications to the client using RFC 5424 levels (debug → emergency).
Declare the logging capability; clients can raise the minimum level with logging/setLevel, and the server emits
notifications/message with severity, optional logger name, and JSON data.
val server = Server(
serverInfo = Implementation("example-server", "1.0.0"),
options = ServerOptions(
capabilities = ServerCapabilities(
logging = ServerCapabilities.Logging,
),
)
)
val session = server.createSession(
StdioServerTransport(
input = System.`in`.asSource().buffered(),
output = System.out.asSink().buffered()
)
)
session.sendLoggingMessage(
LoggingMessageNotification(
LoggingMessageNotificationParams(
level = LoggingLevel.Info,
logger = "startup",
data = buildJsonObject { put("message", "Server started") },
),
),
)
Keep logs free of sensitive data, and expect clients to surface them in their own UI.
List operations return paginated results with an opaque nextCursor, clients echo that cursor to fetch the next page.
Supported list calls: resources/list, resources/templates/list, prompts/list, and tools/list.
Treat cursors as opaque—don’t parse or persist them across sessions.
val server = Server(
serverInfo = Implementation("example-server", "1.0.0"),
options = ServerOptions(
capabilities = ServerCapabilities(
resources = ServerCapabilities.Resources(),
),
)
)
val session = server.createSession(
StdioServerTransport(
input = System.`in`.asSource().buffered(),
output = System.out.asSink().buffered()
)
)
val resources = listOf(
Resource(uri = "note://1", name = "Note 1", description = "First"),
Resource(uri = "note://2", name = "Note 2", description = "Second"),
Resource(uri = "note://3", name = "Note 3", description = "Third"),
)
val pageSize = 2
session.setRequestHandler<ListResourcesRequest>(Method.Defined.ResourcesList) { request, _ ->
val start = request.params?.cursor?.toIntOrNull() ?: 0
val page = resources.drop(start).take(pageSize)
val next = if (start + page.size < resources.size) (start + page.size).toString() else null
ListResourcesResult(
resources = page,
nextCursor = next,
)
}
Include nextCursor only when more items remain an absent cursor ends pagination.
Clients advertise their capabilities (roots, sampling, elicitation, etc.) during initialization. After that they can
serve requests from the server while still initiating calls such as listTools or callTool.
Roots let the client declare where the server is allowed to operate. Declare the roots capability, respond to
roots/list, and emit notifications/roots/list_changed if you set listChanged = true. URIs must be file://
paths.
val client = Client(
clientInfo = Implementation("demo-client", "1.0.0"),
options = ClientOptions(
capabilities = ClientCapabilities(roots = ClientCapabilities.Roots(listChanged = true)),
),
)
client.addRoot(
uri = "file:///Users/demo/projects",
name = "Projects",
)
client.sendRootsListChanged()
Call addRoot/removeRoot whenever your file system view changes, and use sendRootsListChanged() to notify the
server. Keep root lists user-controlled and revoke entries that are no longer authorized.
Sampling lets the server ask the client to call its preferred LLM. Declare the sampling capability (and
sampling.tools if you allow tool-enabled sampling), and handle sampling/createMessage. Keep a human in the loop for
approvals.
val client = Client(
clientInfo = Implementation("demo-client", "1.0.0"),
options = ClientOptions(
capabilities = ClientCapabilities(
sampling = ClientCapabilities.Sampling(tools = buildJsonObject { }), // drop tools if you don't support tool use
),
),
)
client.setRequestHandler<CreateMessageRequest>(Method.Defined.SamplingCreateMessage) { request, _ ->
val content = request.messages.lastOrNull()?.content?.firstOrNull()
val prompt = if (content is TextContent) content.text else "your topic"
CreateMessageResult(
model = "gpt-4o-mini",
role = Role.Assistant,
content = TextContent(text = "Here is a short note about $prompt"),
)
}
Inside the handler you can pick any model/provider, require approvals, or reject the request. If you don’t support tool
use, omit sampling.tools from capabilities.
All transports share the same API surface, so you can change deployment style without touching business logic. Pick the transport that best matches where the server runs.
StdioClientTransport and StdioServerTransport tunnel MCP messages over stdin/stdout—perfect for editor plugins or
CLI tooling that spawns a helper process. No networking setup is required.
StreamableHttpClientTransport and the Ktor mcpStreamableHttp() / mcpStatelessStreamableHttp() helpers expose MCP
over a single HTTP endpoint with optional JSON-only or SSE streaming responses. This is the recommended choice for
remote deployments and integrates nicely with proxies or service meshes.
These helpers automatically install ContentNegotiation with McpJson — do not install it yourself, or a warning will
be logged. Both accept a path parameter (default: "/mcp") to mount the endpoint at any URL:
embeddedServer(CIO, port = 3000) {
mcpStreamableHttp(path = "/api/mcp") {
MyServer()
}
}.start(wait = true)
Session limits: mcpStreamableHttp() keeps every session in memory until the client deletes it, the server closes
it, or it expires. A session expires after sessionIdleTimeout (30 minutes by default) without requests; its client
then receives 404 Not Found and has to initialize a new session. An open GET stream does not keep a session alive
(expiry closes the stream too), so a client that only listens for notifications should send ping requests. At most
maxSessions sessions (10,000 by default) are open at once; while that many are open, a request that would open another
one receives 503 Service Unavailable. Any request other than initialize that carries no Mcp-Session-Id, a plain
GET /mcp included, receives 400 Bad Request, so point health checks at a separate route. Size both limits to your
traffic:
embeddedServer(CIO, port = 3000) {
mcpStreamableHttp(sessionIdleTimeout = 10.minutes, maxSessions = 1_000) {
MyServer()
}
}.start(wait = true)
CORS for browser-based clients (e.g. MCP Inspector): if you connect from a browser-based client you need to install the Ktor CORS plugin so that MCP-specific headers are allowed and exposed:
install(CORS) {
anyHost() // restrict to specific origins in production
allowMethod(HttpMethod.Options)
allowMethod(HttpMethod.Get)
allowMethod(HttpMethod.Post)
allowMethod(HttpMethod.Delete)
allowNonSimpleContentTypes = true
allowHeader("Mcp-Session-Id")
allowHeader("Mcp-Protocol-Version")
exposeHeader("Mcp-Session-Id")
exposeHeader("Mcp-Protocol-Version")
}
[!WARNING] The SSE transport is deprecated in the MCP specification and will be removed in a future release. Use the Streamable HTTP transport instead.
Server-Sent Events remain available for backwards compatibility with older MCP clients. Two Ktor helpers are provided:
Application.mcp { } — installs SSE and ContentNegotiation with McpJson automatically, then registers MCP
endpoints at /. Do not install ContentNegotiation yourself — the SDK handles it.Route.mcp { } — registers MCP endpoints at the current route path; requires install(SSE) in the application
first. Use this to host MCP alongside other routes or under a path prefix:embeddedServer(CIO, port = 3000) {
install(SSE)
routing {
route("/api/mcp") {
mcp { MyServer() }
}
}
}.start(wait = true)
WebSocketClientTransport plus the matching server utilities provide full-duplex, low-latency connections—useful when
you expect lots of notifications or long-running sessions behind a reverse proxy that already terminates WebSockets.
ChannelTransport provides a simple, non-networked transport for testing and local development.
It uses Kotlin coroutines channels to provide a full-duplex connection between a client and server,
allowing for easy testing of MCP functionality without the need for network setup.
Start a sample HTTP server on port 3000:
./gradlew :samples:kotlin-mcp-server:run
Connect with the MCP Inspector or Claude Desktop/Code:
npx -y @modelcontextprotocol/inspector --connect http://localhost:3000
# or
claude mcp add --transport http kotlin-mcp http://localhost:3000
In the Inspector, confirm prompts, tools, resources, completions, and logs show up. Iterate locally until you’re ready to host the server wherever you prefer.
The samples directory contains runnable projects demonstrating MCP server and client implementations with various transports. See the samples overview for a comparison table and detailed descriptions.
Please see the contribution guide and the Code of conduct before contributing.
This project is licensed under Apache 2.0 for new contributions, with existing code under MIT—see the LICENSE file for details.