# Prepare for release version 0.8.1
Bump mcp kotlin-sdk to 0.8.1
## How Has This Been Tested?
Regression tests on CI
## 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)
- [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
- [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
-->
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Implemented thread-safe notification service following eventual
consistency principle.
Fixes https://github.com/modelcontextprotocol/kotlin-sdk/issues/249
Contracts:
* If the client connection and feature update happened in the same
thread, the timestamps of the events will be consequent
```
server.connect(client)
server.add(feature)
// client will receive the notification
```
```
server.add(feature)
server.connect(client)
// client will NOT receive the notification
```
* If the client connection and feature update happened in the different
threads, both options can be possible
The flow of the notification is explained in the diagram:
<img width="663" height="413" alt="image"
src="https://github.com/user-attachments/assets/e2c4c108-53dd-408d-97ef-97110ce5c979"
/>
Documentation references:
https://modelcontextprotocol.io/specification/2025-06-18/server/prompts#list-changed-notificationhttps://modelcontextprotocol.io/specification/2025-06-18/server/tools#list-changed-notificationhttps://modelcontextprotocol.io/specification/2025-06-18/server/resources#list-changed-notificationhttps://modelcontextprotocol.io/specification/2025-06-18/server/resources#subscriptions
Questions:
* I haven't found the subscription confirmed response message content
docs, how it should look like?
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Multiple tests with various notification scenarios were added
## 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)
- [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
-->
Bumps
[org.jetbrains.kotlinx:kotlinx-io-core](https://github.com/Kotlin/kotlinx-io)
from 0.8.1 to 0.8.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/Kotlin/kotlinx-io/releases">org.jetbrains.kotlinx:kotlinx-io-core's
releases</a>.</em></p>
<blockquote>
<h2>v0.8.2</h2>
<h3>Bugfixes</h3>
<ul>
<li>Fixed the issue with Webpack not being able to process module import
introduced in <code>0.8.1</code> <a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/483">#483</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/Kotlin/kotlinx-io/blob/master/CHANGELOG.md">org.jetbrains.kotlinx:kotlinx-io-core's
changelog</a>.</em></p>
<blockquote>
<h2>0.8.2</h2>
<blockquote>
<p>Published 24 November 2025</p>
</blockquote>
<h3>Bugfixes</h3>
<ul>
<li>Fixed the issue with Webpack not being able to process module import
introduced in <code>0.8.1</code> <a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/483">#483</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="b4e59a49a0"><code>b4e59a4</code></a>
Release 0.8.2</li>
<li><a
href="b1914c2a87"><code>b1914c2</code></a>
Prevent node:module import processing by Webpack (<a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/485">#485</a>)</li>
<li>See full diff in <a
href="https://github.com/Kotlin/kotlinx-io/compare/0.8.1...0.8.2">compare
view</a></li>
</ul>
</details>
<br />
[](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>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
1. The currently failing checks are commented out in `ConformanceTest`,
see the TODOs.
2. I added detailed logging for Gradle task, Server, and Client to allow
easier output reading when viewing tests results outside of IDE.
3. As a future improvement, instead of hard-coding scenarios, we can get
them with `npx @modelcontextprotocol/conformance list` and run all of
them.
4. The conformance framework writes its result into
`kotlin-sdk-test/results` directory and contains JSONs like the one
below:
```json
[
{
"id": "mcp-client-initialization",
"name": "MCPClientInitialization",
"description": "Validates that MCP client properly initializes with server",
"status": "SUCCESS",
"timestamp": "2025-11-28T14:38:36.718Z",
"specReferences": [
{
"id": "MCP-Lifecycle",
"url": "https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle"
}
],
"details": {
"protocolVersionSent": "2025-06-18",
"expectedSpecVersion": "2025-06-18",
"versionMatch": true,
"clientName": "kotlin-conformance-client",
"clientVersion": "1.0.0"
}
},
{
"id": "server-info",
"name": "ServerInfo",
"description": "Test server info returned to client",
"status": "INFO",
"timestamp": "2025-11-28T14:38:36.718Z",
"specReferences": [
{
"id": "MCP-Lifecycle",
"url": "https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle"
}
],
"details": {
"serverName": "test-server",
"serverVersion": "1.0.0"
}
}
]
```
As another future improvement, we can do somethig with these JSON files,
like putting them into a job summary on GitHub.
5. The client test also generated stderr.txt file in
`kotlin-sdk-test/results/initialize-.......` which contains errors
because it tries to call a tool. I haven't investigated if it's just the
way I wrote the client or related to `StreamableHttpClientTransport`.
6. The server is the simplified version of the existing server for
Kotlin<--->Typescript tests. If conformance tests extend significantly,
we can either combine the server implementations or ditch the
integration tests.
## 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: -->
- [ ] 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
-->
---------
Co-authored-by: Konstantin Pavlov <1517853+kpavlov@users.noreply.github.com>
Upgrade SDK version to 0.8.0 in Weather STDIO server sample
## Motivation and Context
Keep samples up to date
## How Has This Been Tested?
Locally + CI
## 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] 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
-->
Refactor StreamableHttpClientTransport to skip SSE when the data field
is empty.
## Motivation and Context
TypeScript SSE Server started returning Server-Sent Events with only id
and empty data field (Heartbeat/Checkpoint), followed by an event with
data, e.g.:
```
id: d85c6bb0-0fa2-4828-81ad-3e951131aea5_1764226144689_7qb3iojc
data:
event: message
id: d85c6bb0-0fa2-4828-81ad-3e951131aea5_1764226144690_sodh20lo
data: {"result":{"protocolVersion":"2025-06-18","capabilities":{"logging":{},"tools":{"listChanged":true},"prompts":{"listChanged":true},"completions":{},"resources":{"listChanged":true}},"serverInfo":{"name":"simple-streamable-http-server","version":"1.0.0"}},"jsonrpc":"2.0","id":"7ce065b0678f49e5b04ce5a0fcc7d518"}
```
Such empty events might be used by the server as **Heartbeat** or
**Checkpoint** events. The client should retain the updated
Last-Event-ID and disregard the payload. It is essential to handle such
responses to ensure compatibility with updated TypeScript SDK.
## How Has This Been Tested?
- Added integration test
- Regression tests are green now
## 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. -->
- [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
-->
Bumps
[org.jetbrains.kotlinx:kotlinx-io-core](https://github.com/Kotlin/kotlinx-io)
from 0.8.0 to 0.8.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/Kotlin/kotlinx-io/releases">org.jetbrains.kotlinx:kotlinx-io-core's
releases</a>.</em></p>
<blockquote>
<h2>v0.8.1</h2>
<p>This release addresses an issue with Wasm/JS, where the
<code>require</code> function will no longer be available starting from
Kotlin <code>2.3.20</code> (and it was never guaranteed to be available
in Wasm/JS).</p>
<p>The release also includes some infrastructure changes.</p>
<h3>Bugfixes</h3>
<ul>
<li>Fixed the issue with the <code>require</code>-function that
Wasm/JS-projects migrating to future versions of Kotlin might face <a
href="https://redirect.github.com/Kotlin/kotlinx-io/pull/481">#481</a></li>
</ul>
<p>Thanks to <a
href="https://github.com/alex28sh"><code>@alex28sh</code></a>, <a
href="https://github.com/sargunv"><code>@sargunv</code></a>, and <a
href="https://github.com/iseki0"><code>@iseki0</code></a> for
contributions!</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/Kotlin/kotlinx-io/blob/master/CHANGELOG.md">org.jetbrains.kotlinx:kotlinx-io-core's
changelog</a>.</em></p>
<blockquote>
<h2>0.8.1</h2>
<blockquote>
<p>Published 21 November 2025</p>
</blockquote>
<p>This release addresses an issue with Wasm/JS,
where the <code>require</code> function will no longer be available
starting from Kotlin <code>2.3.20</code>
(and it was never guaranteed to be available in Wasm/JS).</p>
<p>The release also includes some infrastructure changes.</p>
<h3>Bugfixes</h3>
<ul>
<li>Fixed the issue with the <code>require</code>-function that
Wasm/JS-projects migrating to future versions of Kotlin might face <a
href="https://redirect.github.com/Kotlin/kotlinx-io/pull/481">#481</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="843f4d2af6"><code>843f4d2</code></a>
Release 0.8.1</li>
<li><a
href="855d120d9d"><code>855d120</code></a>
Merge branch 'develop'</li>
<li><a
href="45e6cea4bc"><code>45e6cea</code></a>
Add a list of published packages (<a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/482">#482</a>)</li>
<li><a
href="08e5fd8912"><code>08e5fd8</code></a>
Wasm/JS uses ES modules [1], and the require function is not guaranteed
to be...</li>
<li><a
href="dc2b7c5693"><code>dc2b7c5</code></a>
Apply power-assert plugin (<a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/478">#478</a>)</li>
<li><a
href="6fd869747c"><code>6fd8697</code></a>
Commit codestyle (<a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/474">#474</a>)</li>
<li><a
href="3aac3a5427"><code>3aac3a5</code></a>
Migrate to the BCV shipped with KGP (<a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/466">#466</a>)</li>
<li><a
href="e6d0f705b3"><code>e6d0f70</code></a>
Support a new publication scheme (<a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/460">#460</a>)</li>
<li><a
href="b1db70bb98"><code>b1db70b</code></a>
Update api reference url (<a
href="https://redirect.github.com/Kotlin/kotlinx-io/issues/462">#462</a>)</li>
<li><a
href="8f03d33fae"><code>8f03d33</code></a>
Update Kotlin version badge</li>
<li>See full diff in <a
href="https://github.com/Kotlin/kotlinx-io/compare/0.8.0...0.8.1">compare
view</a></li>
</ul>
</details>
<br />
[](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>
## Motivation and Context
Prepare for next develoment version
## 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] CI 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
-->
bump mcp kotlin-sdk to 0.8.0
## 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 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
May throw the following exceptions: `CancellationException`,
`McpException`, `StreamableHttpError`, and `SerializationException`
## Motivation and Context
This makes it possible to handle errors directly without needing to
inspect the cause. For example:
```kotlin
try {
client.connect(transport)
} catch (e: StreamableHttpError) {
// ...
}
```
## 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
- [ ] I have added or updated documentation as needed
Bumps
[com.vanniktech:gradle-maven-publish-plugin](https://github.com/vanniktech/gradle-maven-publish-plugin)
from 0.34.0 to 0.35.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/vanniktech/gradle-maven-publish-plugin/releases">com.vanniktech:gradle-maven-publish-plugin's
releases</a>.</em></p>
<blockquote>
<h2>0.35.0</h2>
<ul>
<li>Add support for publishing Kotlin Multiplatform libraries that use
<code>com.android.kotlin.multiplatform.library</code>.</li>
<li>Add support for validating deployments to Central Portal</li>
<li>Raise minimum Gradle version to 8.13</li>
<li>Raise minimum Android Gradle Plugin version to 8.2.2</li>
<li>Do not unconditionally disable DocLint</li>
<li>Fail publishing if <code>SONATYPE_HOST</code> is not set to
<code>CENTRAL_PORTAL</code>.</li>
<li>Fix misleading error message when Android library variant is not
found.</li>
<li>Downgrade transitive OkHttp version.</li>
<li>Don't check project heirarchy for POM properties when Isolated
proejcts is enabled.</li>
</ul>
<p>Thanks to <a
href="https://github.com/joshfriend"><code>@joshfriend</code></a>, <a
href="https://github.com/Flowdalic"><code>@Flowdalic</code></a> and <a
href="https://github.com/Goooler"><code>@Goooler</code></a> for their
contributions to this release.</p>
<h4>Minimum supported versions</h4>
<ul>
<li>JDK 11</li>
<li>Gradle 8.13</li>
<li>Android Gradle Plugin 8.2.2</li>
<li>Kotlin Gradle Plugin 1.9.20</li>
</ul>
<h4>Compatibility tested up to</h4>
<ul>
<li>JDK 24</li>
<li>Gradle 9.2.0</li>
<li>Gradle 9.3.0-milestone-1</li>
<li>Android Gradle Plugin 8.13.1</li>
<li>Android Gradle Plugin 9.0.0-alpha14</li>
<li>Kotlin Gradle Plugin 2.2.21</li>
<li>Kotlin Gradle Plugin 2.3.0-Beta2</li>
</ul>
<h2>0.35.0-rc1</h2>
<ul>
<li>Add support for publishing Kotlin Multiplatform libraries that use
<code>com.android.kotlin.multiplatform.library</code>.</li>
<li>Add support for validating deployments to Central Portal</li>
<li>Raise minimum Gradle version to 8.13</li>
<li>Raise minimum Android Gradle Plugin version to 8.2.2</li>
<li>Do not unconditionally disable DocLint</li>
<li>Fail publishing if <code>SONATYPE_HOST</code> is not set to
<code>CENTRAL_PORTAL</code>.</li>
<li>Fix misleading error message when Android library variant is not
found.</li>
<li>Downgrade transitive OkHttp version.</li>
<li>Don't check project heirarchy for POM properties when Isolated
proejcts is enabled.</li>
</ul>
<p>Thanks to <a
href="https://github.com/joshfriend"><code>@joshfriend</code></a>, <a
href="https://github.com/Flowdalic"><code>@Flowdalic</code></a> and <a
href="https://github.com/Goooler"><code>@Goooler</code></a> for their
contributions to this release.</p>
<h4>Minimum supported versions</h4>
<ul>
<li>JDK 11</li>
<li>Gradle 8.13</li>
<li>Android Gradle Plugin 8.2.2</li>
<li>Kotlin Gradle Plugin 1.9.20</li>
</ul>
<h4>Compatibility tested up to</h4>
<ul>
<li>JDK 24</li>
<li>Gradle 9.2.0</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/vanniktech/gradle-maven-publish-plugin/blob/main/CHANGELOG.md">com.vanniktech:gradle-maven-publish-plugin's
changelog</a>.</em></p>
<blockquote>
<h2><a
href="https://github.com/vanniktech/gradle-maven-publish-plugin/releases/tag/0.35.0">0.35.0</a>
<em>(2025-11-11)</em></h2>
<ul>
<li>Add support for publishing Kotlin Multiplatform libraries that use
<code>com.android.kotlin.multiplatform.library</code>.</li>
<li>Add support for validating deployments to Central Portal</li>
<li>Raise minimum Gradle version to 8.13</li>
<li>Raise minimum Android Gradle Plugin version to 8.2.2</li>
<li>Do not unconditionally disable DocLint</li>
<li>Fail publishing if <code>SONATYPE_HOST</code> is not set to
<code>CENTRAL_PORTAL</code>.</li>
<li>Fix misleading error message when Android library variant is not
found.</li>
<li>Downgrade transitive OkHttp version.</li>
<li>Don't check project heirarchy for POM properties when Isolated
proejcts is enabled.</li>
</ul>
<p>Thanks to <a
href="https://github.com/joshfriend"><code>@joshfriend</code></a>, <a
href="https://github.com/Flowdalic"><code>@Flowdalic</code></a> and <a
href="https://github.com/Goooler"><code>@Goooler</code></a> for their
contributions to this release.</p>
<h4>Minimum supported versions</h4>
<ul>
<li>JDK 11</li>
<li>Gradle 8.13</li>
<li>Android Gradle Plugin 8.2.2</li>
<li>Kotlin Gradle Plugin 1.9.20</li>
</ul>
<h4>Compatibility tested up to</h4>
<ul>
<li>JDK 24</li>
<li>Gradle 9.2.0</li>
<li>Gradle 9.3.0-milestone-1</li>
<li>Android Gradle Plugin 8.13.1</li>
<li>Android Gradle Plugin 9.0.0-alpha14</li>
<li>Kotlin Gradle Plugin 2.2.21</li>
<li>Kotlin Gradle Plugin 2.3.0-Beta2</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="8232338286"><code>8232338</code></a>
update to 0.35.0-rc1</li>
<li><a
href="85b409d29d"><code>85b409d</code></a>
0.35.0 prep</li>
<li><a
href="2e01bc6c45"><code>2e01bc6</code></a>
Always run CI on the latest Java (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1193">#1193</a>)</li>
<li><a
href="fb36ee35ad"><code>fb36ee3</code></a>
Update android.gradle to v8.13.1 (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1194">#1194</a>)</li>
<li><a
href="0f8135b032"><code>0f8135b</code></a>
Use Java 25 on CI (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1184">#1184</a>)</li>
<li><a
href="4cc5b526b5"><code>4cc5b52</code></a>
Clean up toolchain usages in tests (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1191">#1191</a>)</li>
<li><a
href="aa456e1f2b"><code>aa456e1</code></a>
Update plugin android-lint to v8.13.1 (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1195">#1195</a>)</li>
<li><a
href="32a9226878"><code>32a9226</code></a>
Update dependency com.android.library to v9.0.0-alpha14 (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1188">#1188</a>)</li>
<li><a
href="48a58afe3e"><code>48a58af</code></a>
Support deploying API html (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1192">#1192</a>)</li>
<li><a
href="a795a97d65"><code>a795a97</code></a>
Clean up android extensions in tests (<a
href="https://redirect.github.com/vanniktech/gradle-maven-publish-plugin/issues/1190">#1190</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/vanniktech/gradle-maven-publish-plugin/compare/0.34.0...0.35.0">compare
view</a></li>
</ul>
</details>
<br />
[](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.jlleitschuh.gradle.ktlint from 13.1.0 to 14.0.1.
[](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>
Add `McpClient.ipynb` example notebook demonstrating MCP client
## Motivation and Context
Provide more examples
## How Has This Been Tested?
Run Kotlin Notebook locally
## 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)
- [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
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
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
-->
Update JVM target to 11 in Gradle build configuration
## Motivation and Context
Drop the obsolete JVM 1.8 target to keep up with up-to-date tools, like
Kotest
## How Has This Been Tested?
CI
## Breaking Changes
The minimum JVM version is now 11
## 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)
- [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
## 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
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Add ids for server sessions (auto generated when created)
Support methods proxying from server to server session by id
## 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: -->
- [ ] 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. -->
- [ ] 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
-->
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
```
Bump version to 0.8.0-SNAPSHOT and update `mcp-kotlin` dependency to
0.7.7 in samples
## How Has This Been Tested?
Regression
## 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)
- [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
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
## Motivation and Context
Prepare to release 0.7.7
## How Has This Been Tested?
Regression
## 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)
- [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
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
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
-->
## Motivation and Context
Prepare for the subsequent development iteration
## 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: -->
- [ ] 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] Dependency 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
-->
Upgrade Gradle
## Motivation and Context
KTLO (🪔 To keep the lights on)
## 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: -->
- [ ] 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 tools 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
-->
Update Kotlin-MCP-Server with STDIO support, logging & CORS
### Summary
- Added support for STDIO transport mode (default behavior).
- Configured CORS and migrated SSE server to Ktor's Netty engine.
- Redirected logs to `./build/stdout.log` and updated log levels.
- New `TestEnvironment` setup for integration testing.
- Enhanced documentation with examples for server execution and MCP
Inspector usage.
- Introduced shadow JAR plugin for building runnable artifacts.
### Motivation and Context
Improves server versatility and developer experience by enabling STDIO
and refining setup.
## How Has This Been Tested?
Unit tests, tested locally (see README.md in sample)
**NB! sse plain configuration is not working at the moment**
## 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
- [ ] 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>
Add test for sse server
TODO: Add tests for the other protocols
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
## 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: -->
- [ ] 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] 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
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
## 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
-->
Fix#293
Also fixed a bug with initialization: properties must be declared before
the init block; otherwise, the initialization order is violated and an
NPE will occur in the init block.
## Motivation and Context
After initialization, MCP clients send a `logging/setLevel` request if
the logging capability is enabled. This request was previously not
handled, leading to an error that blocked the use of the MCP server in
the inspector and other clients.
## How Has This Been Tested?
Added integration test
## 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
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>
Konstantin Pavlov
Maria Tigina
dependabot[bot]
Sergey Karpov
Pavel Gorgulov
Ruslan Ibrahimau (Ibragimov)
Jeff Clyne