# 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
-->
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
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
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>
- 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
-->
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
```
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
Split ServerTest per feature test classes
<!-- 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
## 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
-->
- Rename `connect` to `createSession` in `Server.kt `to make naming more
clear
- Add block to configure build to `Server.kt`
- Move sse test to jvm to be able to run, small test refactoring
- Introduce base integration test for sse server / client
With Ktor 3.2.3, tests don’t work correctly with wasm, so the websocket
tests were moved to the jvm target as the most important one
## How Has This Been Tested?
local
## 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)
- [ ] Documentation update
- [x] Refactoring
## 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
Update server-side tool error handling to return `CallToolResult` with
`isError: true` instead of throwing protocol-level exceptions,
conforming with MCP specification
## Motivation and Context
[The MCP specification
states](https://modelcontextprotocol.io/specification/2025-06-18/schema#calltoolresult):
> Any errors that originate from the tool SHOULD be reported inside the
result object, with isError set to true, not as an MCP protocol-level
error response. Otherwise, the LLM would not be able
to see that an error occurred and self-correct.
This PR updates the kotlin sdk to match this behavior
## How Has This Been Tested?
All tests pass successfully with the new behavior
## 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
## Additional context
The TypeScript SDK was recently updated
[#1044](https://github.com/modelcontextprotocol/typescript-sdk/pull/1044)
to conform with the MCP specification regarding tool error handling.
That’s why we got exceptions in the integration tests
- ktor 3.2.3
- Tests are ignored because Ktor 3.2.3 has issues with wasm in the test
environment. However, it works outside of tests. All other targets pass
these tests successfully.
## Motivation and Context
compatibility with older versions of Ktor
## Changes
- Updated `DecimalFormatSymbols` to use period as decimal separator
(Locale.US)
- Fixed test expectations in `testComplexInputSchemaTool`:
- `formattedResult`: `"11,000"` → `"11.000"`
- `tags`: Added actual test values `["test", "calculator",
"integration"]`
- Fixed test expectations in `testComplexNestedSchema`:
- `formattedResult`: `"0,00"` → `"0.00"`
## Motivation
1. **Standard Decimal Notation**: Using a comma as a decimal separator
could be confusing as it's commonly used for thousands separators in
many locales. Standardizing on the period (`.`) follows international
conventions and makes the output clearer.
2. **Test Data Correction**: During the Validate PR workflow for #289,
discovered that the `tags` array in the `expectedContent` variable of
`testComplexInputSchemaTool()` was incorrectly set to an empty array,
which didn't match the actual input values being tested.
---------
Co-authored-by: MAERYO <maeryo@hanwha.com>
According to
https://modelcontextprotocol.io/specification/2025-06-18/basic/index#meta,
the _meta parameter should be passable when calling tools. While the
CallToolRequest class (in types.kt) currently includes _meta in its
definition, SDK users cannot actually input _meta when invoking the
callTool method.
This Pull Request adds a metadata parameter to the CallTool method and
includes functionality to convert various data formats without loss.
Additionally, to encourage the use of valid Key name formats as defined
by the protocol, validation for prefixes has been implemented.
---------
Co-authored-by: MAERYO <maeryo@hanwha.com>
Co-authored-by: devcrocod <devcrocod@gmail.com>
<!-- 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.
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>
This PR adds integration test coverage by covering the Stdio transport.
The tests were refactored to accommodate Stdio without adding
duplication.
## 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] Test improvement
## 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
-->
---------
Co-authored-by: Pavel Gorgulov <devcrocod@gmail.com>
## Motivation and Context
Flaky integration tests
## How Has This Been Tested?
`./gradlew check`
## Changes
- Use random port for Ktor in tests
- Remove unused `TestUtils` utility class.
- Replace `runTest` with `runBlocking` in test cases.
- Adjust imports and formatting for consistency.
- Add `Awaitility` dependency for dynamic server setup.
- Update `Duration` usage from milliseconds to seconds.
- Minor configuration and code formatting updates.
## 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. -->
- [ ] 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
-->
* Modularize SDK: migrated client and server implementations to separate modules. Removed old configuration files and reorganized the source code structure
* add support native targets and update js/wasm configurations
* Refactor sample projects: add samples as composite builds, replace hardcoded dependencies with version catalog, remove obsolete gradle wrapper files
* Update .gitignore: exclude SWE agent directories (.claude/ and .junie/)
* Refine CodeQL workflow: update Kotlin build steps to target individual modules separately instead of building all at once
