Is your feature request related to a problem? Please describe.
Android applications can act as MCP hosts and connect to remote MCP servers to discover and invoke tools. The Kotlin SDK already provides client APIs and Streamable HTTP transport APIs that fit this use case.
Android applications may be able to consume the JVM variant in some configurations, but Android is not part of the SDK's declared target matrix.
As a result, the SDK does not publish an Android-specific variant or run Android compatibility tests. Android consumers must independently validate dependency resolution, runtime behavior, minified release builds, and SDK upgrades. A regression caused by a JDK-only API or an Android-incompatible dependency can therefore be discovered only downstream.
Describe the solution you'd like
Add officially supported Android targets for the client-facing modules:
kotlin-sdk-core
kotlin-sdk-client
The initial support scope could focus on Android applications connecting to remote MCP servers over HTTPS using Streamable HTTP.
The SDK should continue to accept a caller-provided Ktor HttpClient. Android consumers could then choose an appropriate engine, such as ktor-client-okhttp, without the SDK forcing a specific engine dependency.
An official Android client target would make this compatibility contract explicit and allow the SDK to detect Android regressions before release.
Suggested validation scope:
- Android dependency resolution and published Android variants
Client initialization and shutdown
StreamableHttpClientTransport
tools/list and tools/call
- JSON and SSE response handling
- request headers
- release/R8 compatibility
Describe alternatives you've considered
-
Consume the JVM variant from an Android application
This can work for some API and dependency combinations, but Android compatibility is not explicitly declared or continuously verified by the SDK.
-
Use a third-party Android MCP wrapper
This can provide a project-specific solution, but duplicates protocol integration, compatibility testing, and lifecycle handling outside the official SDK.
-
Implement the MCP protocol directly in an Android application
This avoids SDK compatibility uncertainty, but duplicates the protocol client, Streamable HTTP transport, lifecycle handling, and future specification updates.
Additional context
This proposal is intentionally client-only and has a limited initial scope. It does not propose:
- running an MCP server on Android;
- stdio transport support;
- Android-specific OAuth UI, credential storage, deep-link handling, or configuration screens;
- WebSocket support as an initial requirement;
- changes to the MCP protocol or existing public client APIs.
I would be interested in contributing this feature. Before starting implementation, I would appreciate maintainer guidance on the intended scope, supported Android versions, testing strategy, and publishing conventions, so that a potential contribution aligns with the project’s maintenance expectations.
If this direction is in scope, I am happy to prepare a small proof of concept and then submit a focused PR based on maintainer feedback.
Is your feature request related to a problem? Please describe.
Android applications can act as MCP hosts and connect to remote MCP servers to discover and invoke tools. The Kotlin SDK already provides client APIs and Streamable HTTP transport APIs that fit this use case.
Android applications may be able to consume the JVM variant in some configurations, but Android is not part of the SDK's declared target matrix.
As a result, the SDK does not publish an Android-specific variant or run Android compatibility tests. Android consumers must independently validate dependency resolution, runtime behavior, minified release builds, and SDK upgrades. A regression caused by a JDK-only API or an Android-incompatible dependency can therefore be discovered only downstream.
Describe the solution you'd like
Add officially supported Android targets for the client-facing modules:
kotlin-sdk-corekotlin-sdk-clientThe initial support scope could focus on Android applications connecting to remote MCP servers over HTTPS using Streamable HTTP.
The SDK should continue to accept a caller-provided Ktor
HttpClient. Android consumers could then choose an appropriate engine, such asktor-client-okhttp, without the SDK forcing a specific engine dependency.An official Android client target would make this compatibility contract explicit and allow the SDK to detect Android regressions before release.
Suggested validation scope:
Clientinitialization and shutdownStreamableHttpClientTransporttools/listandtools/callDescribe alternatives you've considered
Consume the JVM variant from an Android application
This can work for some API and dependency combinations, but Android compatibility is not explicitly declared or continuously verified by the SDK.
Use a third-party Android MCP wrapper
This can provide a project-specific solution, but duplicates protocol integration, compatibility testing, and lifecycle handling outside the official SDK.
Implement the MCP protocol directly in an Android application
This avoids SDK compatibility uncertainty, but duplicates the protocol client, Streamable HTTP transport, lifecycle handling, and future specification updates.
Additional context
This proposal is intentionally client-only and has a limited initial scope. It does not propose:
I would be interested in contributing this feature. Before starting implementation, I would appreciate maintainer guidance on the intended scope, supported Android versions, testing strategy, and publishing conventions, so that a potential contribution aligns with the project’s maintenance expectations.
If this direction is in scope, I am happy to prepare a small proof of concept and then submit a focused PR based on maintainer feedback.