## 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
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>
Add `StreamableHttpClientTest` with test infrastructure setup and
dependencies
<!-- Provide a brief summary of your changes -->
## Motivation and Context
To test Streaming HTTP Transport
## How Has This Been Tested?
Integration test added
## Breaking Changes
No, only tests
## 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
-->
<!-- 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
-->
<!-- Provide a brief summary of your changes -->
Replace the CIO dependency with only server/client core dependency.
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
In order to minimize the size of package. There are probably other
existing engines like Netty/Tomcat(server) or Java/OkHttp/Apache(client)
in the classpath. So we can reuse existing infrastructure.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
I have run:
- kotlin-sdk-client: jvmTest, jsTest
- kotlin-sdk-test: jvmTest, jsTest
- kotlin-sdk-server: allTests
- All `build` of samples
I have an issue about `samples/kotlin-mcp-server`.
`io.modelcontextprotocol` is not found in `commonMain`.
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
Yes. They need to `implementation` CIO engine manually if they use it in
their app.
## 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. -->
- [ ] 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
-->
closes https://github.com/modelcontextprotocol/kotlin-sdk/issues/111
---------
Co-authored-by: Konstantin Pavlov <1517853+kpavlov@users.noreply.github.com>
* 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
