Add URL mode elicitation support and typed `PrimitiveSchemaDefinition`
hierarchy to align with MCP specification 2025-11-25
closes#540
## How Has This Been Tested?
unit/integration/conformance
## Breaking Changes
- `ElicitRequestParams` changed from `data class` to `sealed interface`.
A deprecated factory function preserves source compatibility for
`ElicitRequestParams(message, requestedSchema)`.
- `RequestedSchema.properties` changed from `JsonObject` to `Map<String,
PrimitiveSchemaDefinition>`.
- `ElicitRequest.requestedSchema` is deprecated, use `(params as
ElicitRequestFormParams).requestedSchema`.
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Fix Kotlin language and api version to 2.1
- Remove language constructs not supported in Kotlin 2.1
<!-- Provide a brief summary of your changes -->
## Motivation and Context
To ensure binary compatibility
## How Has This Been Tested?
Regression tests
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [x] Build update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Remove all deprecation with error level
## Motivation and Context
next minor release
## How Has This Been Tested?
-
## Breaking Changes
Removing it is a binary-incompatible change
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Motivation and Context
closes#421#406
## How Has This Been Tested?
Unit tests
## Breaking Changes
NaN
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
Adds a comprehensive conformance test suite for the Kotlin MCP SDK,
covering core protocol operations, tool calls, elicitation, resources,
prompts, and 20 OAuth/auth scenarios
- Conformance server and client implementations
- OAuth/auth test scenarios: JWT, authorization code flow, client
credentials, PKCE, scope handling, cross-app access, client registration
- CI workflow
- Baseline file for tracking expected failures
- Shell script
fixes:
- #592
- #593
- #596
## Remaining known failures (tracked issues, will be fixed directly in
`main`)
- [x] `tools-call-with-logging`, `tools-call-with-progress`,
`tools-call-sampling`, `tools-call-elicitation`,
`elicitation-sep1034-defaults`- see #599,
- [x] `elicitation-sep1330-enums` - #587#600
- [x] `initialize` - #588
- [x] `tools_call`, `auth/scope-step-up`, `auth/scope-retry-limit` -
#589
- [ ] `elicitation-sep1034-client-defaults` - #414
- [x] `sse-retry` - #590
- [ ] `resources-templates-read` - #591
## Breaking Changes
from #596
- `StreamableHttpClientTransport` and
`mcpStreamableHttp`/`mcpStreamableHttpTransport`: old constructors
accepting `Duration` timeout are now `@Deprecated` — use the new
overloads with `ReconnectionOptions` instead
- `StreamableHttpClientTransport.close()` no longer calls
`terminateSession()` automatically
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
---------
Co-authored-by: Konstantin Pavlov <1517853+kpavlov@users.noreply.github.com>
closes#543
## How Has This Been Tested?
unit
## Breaking Changes
binary compatibility in the Tool class
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
---------
Co-authored-by: Konstantin Pavlov <1517853+kpavlov@users.noreply.github.com>
## Rethrow CancellationException in StdioServerTransport, fix ReadBuffer
### Changes
1. StdioServerTransport
- Replace generic `Throwable` catches with specific
`CancellationException` and `Exception` for clarity and correctness.
**breaking change** `Throwable` is not handled any more!
- Refactor launching jobs to separate methods
- Introduce `READ_BUFFER_SIZE` constant to replace inline buffer size
literals.
- Add suppress annotations for clearer intent and constructor
documentation for better usability.
- Extend StdioServerTransportTest
2. ReadBuffer
Previously, readMessage() returned null after consuming an unparseable
line even when more complete lines existed in the buffer. This caused
valid messages following a bad line in the same chunk to be silently
dropped until the next chunk arrived (or forever, in tests).
Fix the loop so null means only "no complete line available", not
"encountered a parse failure". Blank/whitespace-only lines are now
silently skipped via isBlank() rather than forwarded to the deserializer
and logged as errors.
Refactor the method into three focused helpers:
- readMessage() — outer loop over lines
- readLine() — consume the next newline-delimited line from the buffer
- tryRecover() — attempt deserialization from the first '{' onward
3. Add utility method `runIntegrationTest` for integration testing
(`runBlocking` + `withTimeout`). Use it in StdioServerTransportTest
4. Store processing Job reference and `calcelAndJoin()` it on close.
Partially addressing #574
## Motivation and Context
See #575, #564, #242
## How Has This Been Tested?
Unit test added
## Breaking Changes
Semantic change: `Throwable` and CancellationException are not handled
any more!
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
# Add DSL builder tests for Request, Capabilities, and Content types
- Introduced unit tests for `RequestDslTest`, `CapabilitiesDslTest`, and
`ContentDslTest` to validate DSL builder functionality.
- Covered edge cases, nested properties, custom fields, and overwrite
behavior for requests, capabilities, and content creation.
- Update AGENTS.md
## Motivation and Context
for confidence
## Breaking Changes
No
## Types of changes
- [x] Tests
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
1. Migrate test-utils module to multiplatform, add serialization
utilities
- Migrated `test-utils` to support Kotlin Multiplatform (JVM, JS,
Native).
- Added `verifySerialization`, `verifyDeserialization`,
`verifySerializationRoundTrip` utilities to streamline and validate JSON
serialization/deserialization
2. Refactor serialization tests to use test serialization utilities
- Updated serialization tests across the project to use
`verifySerialization` and `verifyDeserialization` utilities.
- Improved consistency and ensured proper round-trip validation for JSON
deserialization.
3. Remove some detekt baseline files and suppress `LongMethod` findings
- Deleted detekt baseline XML files for test sources.
- Suppressed `LongMethod` findings in relevant tests using `@Suppress`
annotations.
- Replaced empty method implementations with explicit `// noop` comments
for clarity.
- Adjusted min test coverage threshold in `build.gradle.kts`.
## Motivation and Context
To improve serialization testing
## How Has This Been Tested?
Unit tests
## Breaking Changes
No
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [x] Refactoring
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
Add $defs support in ToolSchema and update tests.
Motivation and Context
Fix parsing when tool schemas include $defs.
How Has This Been Tested?
`./gradlew :kotlin-sdk-core:jvmTest --tests
"io.modelcontextprotocol.kotlin.sdk.types.ToolsTest"`
Breaking Changes
No.
Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
Checklist
- [x] I have read the MCP Documentation
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
Additional context
N/A
# Detekt setup hardeing; address some issues
- Address some detekt findings: missing KDocs, formatting, use `check*`
& `orEmpty()``
- Remove unnecessary KDoc comments from deprecated classes in `types.kt`
- Add Detekt baseline XML files for all modules
- Enforce stricter Detekt rules by setting `failOnSeverity` from `None`
to `Error`
## Motivation and Context
Detekt is not actually failing the build on violations. This PR is
enabling Detekt to fail on errors. Baseline fines added for historical
issues. Follow-up for #501
## How Has This Been Tested?
Regressions
## Breaking Changes
No breaking changes.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Refactoring
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## refactor: Introduce AbstractClientTransport and simplify client
transport lifecycle
This PR unifies state management logic across client transports, except
for the websocket transport, as it needs more refactoring first and is
not the primary transport.
- Introduce `AbstractClientTransport` as base class for other client
transports.
- Migrate to `ClientTransportState` states with state machine,
streamline state management.
- Ensure proper cleanup and error handling consistency across transport
implementations.
- Add unit tests to validate `AbstractClientTransport` behavior and
state transitions.
- Update related documentation and API contract.
- Make sure `onClose` callback is called at most once
- fix
[StreamableHttpClientTransportTest.kt](https://github.com/modelcontextprotocol/kotlin-sdk/pull/516/changes#diff-b9fe8891d08a492448a7ed2dc782151c6a915ae1403a4d70c2034c6062c84cb5)
to throw `McpException` on connect when received invalid Json
## Motivation and Context
Unify lifecycle handling and eliminate duplication in client Transport
implementations.
## How Has This Been Tested?
Unit test, regression tests
## Breaking Changes
- `onClose` callback is now called only once
- send(...) will throw McpException with message "Transport is not
ready" when `ClientTransportState != Operational`
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] Refactoring
- [ ] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
See #517
#162
## Motivation and Context
- update readme
- add more snippets
- add knit
## How Has This Been Tested?
knit on CI
## Breaking Changes
None
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [x] I have added or updated documentation as needed
---------
Co-authored-by: devcrocod <devcrocod@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- increase the deprecation level
- remove tests that use deprecated objects with deprecation level =
error
## Motivation and Context
deprecation lifecycle
## How Has This Been Tested?
-
## Breaking Changes
-
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The dsl builders in [this
commit](74c93745cd (diff-598edaa01d))
were mistakenly marked internal and are therefore unusable. I have
simply marked them as public.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
No
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
---------
Co-authored-by: Konstantin Pavlov <1517853+kpavlov@users.noreply.github.com>
# Update/Fix build workflow
- `macos-latest-xlarge` is no longer available. Switch to cheaper
runner: `macos-latest-xlarge` -> `macos-latest`
- Refactor build to run matrix job under Linux and macOS
- Tune caching GH caching
- Add junit and logger properties
- Downgrade Junit to 5.14.2
- Extract `ProcessBuilder` creation logic into helper functions
- Disable `StdioClientTransportTest` on windows temporary
## How Has This Been Tested?
CI
## Breaking Changes
Functionally - no. Outdated/broken TypeScript tests were disabled
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] CI Update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
GitHub actions workflows were blocked because the selected
"macos-latest-xlarge" runner, which is not available for the free
open-source plan. With "macos-latest" workflow works.
# [WIP] StreamableHttpServerTransport implementation
- Implement StreamableHttpServerTransport for MCP spec
- Support both SSE streaming and direct HTTP JSON responses
- Add event store interface for resumability
> [!IMPORTANT]
> The work is in progress. StreamableHttpServerTransport is not
production-ready yet!!!
Based on #235
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
None
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
# Better exception handling in StdioClientTransport
Refactor `McpException` for improved handling with convenience
constructors and enhanced exception wrapping logic in
`StdioClientTransport`. Update tests to use `kotest` matchers and add
JUnit parameterized tests for exception handling.
## Motivation and Context
#442 follow up
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
- Add convenience constructors to JSONRPCRequest
- Make UUID string a default JSONRPCRequest
## Motivation and Context
To create request objects more easily
## How Has This Been Tested?
Unit tests
## Breaking Changes
No, this is a new API
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Add support for `TransportSendOptions` in `Transport.send` method
## Motivation and Context
This change extends the `Transport.send` method signature to support
advanced transport features like resumption tokens and progress
callbacks. This is needed to enable:
- Long-running request resumption after reconnection
- Request-response association tracking
- Progress token handling in transport layer
needed for #235
## How Has This Been Tested?
All transport tests passed
## Breaking Changes
Yes, it’s necessary to update the custom Transport implementations.
For users who rely on the transports provided by the sdk, there’s no
breaking change
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
This PR introduces type-safe DSL builders for all MCP request types,
making it easier to construct requests
### Current Solution
All request types now have DSL builders:
```kotlin
// Initialize request
val request = initializeRequest {
protocolVersion = "2024-11-05"
capabilities {
sampling(ClientCapabilities.sampling)
roots(listChanged = true)
}
info("MyClient", "1.0.0")
}
// Create message request with conversation
val messageRequest = createMessageRequest {
maxTokens = 1000
systemPrompt = "You are a helpful assistant"
messages {
user { "What is the capital of France?" }
assistant { "The capital of France is Paris." }
user { "What about Germany?" }
}
}
// Call tool request
val toolRequest = callToolRequest {
name = "searchDatabase"
arguments {
put("query", "users")
put("limit", 10)
}
}
// Elicit request with schema
val elicitRequest = elicitationRequest {
message = "Please provide your contact information"
requestedSchema {
properties {
put("email", JsonObject(mapOf(
"type" to JsonPrimitive("string"),
"description" to JsonPrimitive("Your email address")
)))
}
required = listOf("email")
}
}
```
Each DSL builder includes:
- Clear separation of required (but runtime) vs optional fields
- Multiple usage examples
- Concise error messages with examples when required fields are missing
- Cross-references to related types
### Design Considerations
1. Function Naming Convention
The current naming convention (e.g., initializeRequest, callToolRequest) might be confusing since these functions don't send requests, they just build request objects.
Alternative approach: Add a build prefix to clarify intent:
- `initializeRequest` → `buildInitializeRequest`
- `callToolRequest` → `buildCallToolRequest`
- `createMessageRequest` → `buildCreateMessageRequest`
This would make it clearer that these are builder functions.
2. Runtime vs Compile-Time Validation
Currently, required fields are validated at runtime in the `build()` method:
```kotlin
val request = initializeRequest {
protocolVersion = "2024-11-05"
// Missing required fields: capabilities, info
// Error thrown at runtime ❌
}
```
Alternative approach: Use Compose UI style where required parameters are in the function signature:
```kotlin
fun initializeRequest(
protocolVersion: String,
capabilities: ClientCapabilities,
info: Implementation,
block: InitializeRequestBuilder.() -> Unit = {}
): InitializeRequest
```
```kotlin
// Usage
val request = initializeRequest(
protocolVersion = "2024-11-05",
capabilities = ClientCapabilities(sampling =
ClientCapabilities.sampling),
info = Implementation("MyClient", "1.0.0")
) {
// Optional fields only
meta { put("key", "value") }
}
```
Pros:
- Compile-time safety for required fields ✅
- Clear which fields are required ✅
- Better IDE autocomplete ✅
Cons:
- Multiple trailing lambdas can be confusing:
```kotlin
// When required fields include lambdas
val request = elicitationRequest(
message = "Enter info",
requestedSchema = { /* lambda 1 */ }
) { /* lambda 2 for optional fields */ }
```
- Less consistent DSL feel
- More verbose for simple cases
## Motivation and Context
fix#220
## How Has This Been Tested?
locally
## Breaking Changes
None
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
Add tests with new schema types
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
## How Has This Been Tested?
The repository currently contains duplicated tests:
- tests using the new schema
- tests using the old schema for compatibility checks. they will be
removed once the deprecation level is raised
## Breaking Changes
No
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [x] Testing
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
---------
Co-authored-by: Konstantin Pavlov <1517853+kpavlov@users.noreply.github.com>
- add the warning message to `ExperimentalMcpApi` annotation
- change level from error to warning
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [x] I have added or updated documentation as needed
- Introduced `@ExperimentalMcpApi` annotation to mark experimental APIs.
- Added `mcpClient` function for initializing and connecting MCP
clients.
- Modified tests to utilize the new `mcpClient` function.
- Refactored variable naming in transport tests for improved
readability.
## Motivation and Context
To improve the creation of the MCP Client experience.
## How Has This Been Tested?
Integration test updated
## Breaking Changes
No
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
- Updated integration tests to include assertions for `meta` being
`null` in the `listTools`, `listResources`, `readResource`, and
`callTool` results.
- Renamed test cases in `SseServerIntegrationTest` for clarity.
- Added (deprecated) synthetic constructors for various request
parameter classes.
- Enhanced naming conventions and structure in integration test cases.
- Replaced `throw Error(...)` with `error(...)` for cleaner error
handling.
## Motivation and Context
To verify backwards-compatibility after schema change
## How Has This Been Tested?
CI, integration tests, regression tests (samples)
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [x] Test update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
# Refactor and enhance prompt handling logic and tests, update Kotest
version and modularize `AbstractTransport`
- Added more post-conditions/scenarios to ServerPromptsTest
- Extracted `AbstractTransport` to a dedicated file for modularity.
- Improved Protocol connection state validation: When disconnected, the
Protocol will throw `IllegalStateException` instead of `Error`.
- Minor Kotlin fixes and suppressions to improve code quality.
## Motivation and Context
Improve test scenarios in ServerPromptsTest
## How Has This Been Tested?
Integration tests updated
## Breaking Changes
When disconnected, the Protocol will throw `IllegalStateException`
instead of `Error`.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [x] Test update
- [x] Refactoring
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Add properties for types of new schema
## Motivation and Context
Added getters to simplify access to properties in request and
notification types.
## How Has This Been Tested?
All tests pass
## Breaking Changes
None
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
Implement the last version of the mcp schema and complete restructuring
of the mcp schema implementation from a monolithic `types.kt` file into
separate files.
- #158
- #185
- #353
- #298
- #248
## Motivation and Context
The previous implementation of the mcp schema was outdated and contained
several issues. In addition, it stored all mcp types in a single large
file, which made maintenance and further development more difficult
## How Has This Been Tested?
All tests passed
## Breaking Changes
Yes. The new types are now located in a separate package. Additionally,
many types have new parameters and modified constructors
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
to adopt the new structure:
**Before:**
```kotlin
import io.modelcontextprotocol.kotlin.sdk.InitializeRequest
import io.modelcontextprotocol.kotlin.sdk.Resource
```
**After:**
```kotlin
import io.modelcontextprotocol.kotlin.sdk.types.InitializeRequest
import io.modelcontextprotocol.kotlin.sdk.types.Resource
```
Replace `Instant` with `String` for `lastModified` in `Annotations`
## Motivation and Context
To fix serialization/kotlin library version conflicts
## How Has This Been Tested?
Unit test
## Breaking Changes
Yes
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
<!-- Provide a brief summary of your changes -->
## Motivation and Context
The recently released openAI [Apps SDK
](https://developers.openai.com/apps-sdk/reference/#_meta-fields-the-client-provides)adds
a '__meta_' field on the Tool Descriptor. This would be in addition to
it being available on Messages. It remains optional and defaults to an
empty json object, following existing conventions.
## How Has This Been Tested?
Unit tests for serialization added
## Breaking Changes
N/A
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [X] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [X] My code follows the repository's style guidelines
- [X] New and existing tests pass locally
- [X] I have added appropriate error handling
- [X] I have added or updated documentation as needed
## Additional context
https://developers.openai.com/apps-sdkhttps://developers.openai.com/apps-sdk/reference/#_meta-fields-the-client-provides
---------
Co-authored-by: Pavel Gorgulov <devcrocod@gmail.com>
## Motivation and Context
- 📦 Unifies Ktor library versioning by introducing the Ktor BOM
dependency.
- ✅ Re-enable build of MCP Server Sample
## How Has This Been Tested?
Regression tests
## Breaking Changes
No
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [x] Build configuration update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Bumps org.openapi.generator from 7.16.0 to 7.17.0.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps org.openapi.generator from 7.15.0 to 7.16.0.
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Konstantin Pavlov <1517853+kpavlov@users.noreply.github.com>
Changes to kotlin-sdk-core/build.gradle.kts to be compatible with gradle
9.x.x
## Motivation and Context
If including this project into a composite build that uses gradle 9.x.x,
recent changes to the build.gradle.kts are not compatible.
## How Has This Been Tested?
The build still works with gradle 8.x
## Breaking Changes
N/A
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
<!-- Provide a brief summary of your changes -->
## Motivation and Context
The
[schema](cca15204f6/schema/2025-03-26/schema.ts (L192))
for the InitializeResult contains an optional 'instructions' string
## Additional context
The instructions string is included in the schema for for version
"2025-03-26"
The instructions in the Server class are given as a provider function
with the result of the provider propagated to the underlying
ServerSession. As the ServerSession change is meant to allow for a
'Singleton scoped' server class, this provides the ability to
dynamically modify the instructions at the server level but have them be
immutable per session.
This also refactors the `serverInfo` and `instructions` properties to be
protected. This `Server` class is open and meant to be overridden, there
is no harm in having these immutable properties available to subclasses.
This adds the serverInstructions to the client as returned from the
InitializeResult. This is used to verify the response in the Server
tests.
One may run it manually to generate classes from JSON Schema
## Motivation and Context
Most of the generated classes could not be used in the current API
today.
On the other hand, it is useful to be able to generate such classes to
simplify manual API synchronization. So, Gradle plugin configuration is
preserved, but detached from the build pipeline.
- Add OpenAPI Generator to build system to automatically generate MCP
protocol data classes from the official schema.
- Configure code quality tools to exclude generated files
- Add deserialization test
## Motivation and Context
Writing classes by hand is error-prone, when json schema exists. See
#185,
Also, autogenerating model classes ensures the SDK is in sync with the
protocol and can quickly catch up with its changes (see #218)
## How Has This Been Tested?
Regression tests
## Breaking Changes
No
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Introduce a `ServerSession` to manage multiple connections to the mcp
server. `Protocall` logic of the `Server` was moved to `ServerSession`,
while MCP resources logic remained in `Server`
## Motivation and Context
1. Fix the multiple connection issues reported for SSE transport
2. Avoid server duplications during configurations: currently every connection
creates a session, but the server stays single
## How Has This Been Tested?
Added `SseIntegrationTest` and `WebSocketIntegrationTest` integration
tests to check connection with single and multiple clients
## Breaking Changes
This change caused several depreciations:
1. The `Server` -> `Protocol` inheritance (which caused single
connection issue) should be removed in future releases, now, all the
methods inherited from `Protocall` marked as `Deprecated` with a
`Warning`
2. Websocket Ktor server initialization changes in order not to create
server instance per connection
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
---------
Co-authored-by: devcrocod <devcrocod@gmail.com>
#152
## Motivation and Context
To simplify publishing, use the [recommended
plugin](https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-publish-libraries.html#set-up-the-publishing-plugin)
## Breaking Changes
no
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
fix#272
## How Has This Been Tested?
Locally
## Breaking Changes
No
## Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## #252 Add module documentation and enhance Dokka configuration
## How Has This Been Tested?
`./gradlew :docs:dokkaGenerate`
## Changes
- Add workflow to build and publish API documentation with Dokka
- Introduce `.github/workflows/apidocs.yaml` to build and deploy API
docs on `main` and release events.
- Configure Gradle for Dokka builds and update project dependencies.
- Include `:docs` module in project settings.
- Introduce `Module.md` for `kotlin-sdk-server`, `kotlin-sdk-client`,
and `kotlin-sdk-core` modules.
- Update `.gitignore` to include `.idea/icon.png` and add placeholder
icon files
- Remove outdated documentation HTML files
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
---------
Co-authored-by: devcrocod <devcrocod@gmail.com>
