feat(core): add extensions field to ClientCapabilities and ServerCapabilities#678
feat(core): add extensions field to ClientCapabilities and ServerCapabilities#678eritscher wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds MCP extension negotiation support by introducing an extensions capabilities field so clients/servers can advertise supported extensions (with optional per-extension settings) during the initialize handshake.
Changes:
- Add
extensions: Map<String, JsonObject>?toClientCapabilitiesandServerCapabilities(serializable). - Extend the client capabilities DSL to set
extensions, and add/expand tests covering DSL + serialization behavior. - Update the published API surface file to reflect the new constructors/components.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/types/capabilities.kt | Adds extensions to capability data classes and updates KDoc. |
| kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/types/capabilities.dsl.kt | Adds extensions(...) to ClientCapabilitiesBuilder. |
| kotlin-sdk-core/src/commonTest/kotlin/io/modelcontextprotocol/kotlin/sdk/types/dsl/InitializeDslTest.kt | Verifies initialize DSL can set/read extensions. |
| kotlin-sdk-core/src/commonTest/kotlin/io/modelcontextprotocol/kotlin/sdk/types/dsl/CapabilitiesDslTest.kt | Adds DSL tests for null/empty/overwrite behavior for extensions. |
| kotlin-sdk-core/src/commonTest/kotlin/io/modelcontextprotocol/kotlin/sdk/types/CapabilitiesTest.kt | Adds serialization + round-trip coverage for extensions on both client/server capabilities. |
| kotlin-sdk-core/api/kotlin-sdk-core.api | Updates API signatures for new capability fields. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/types/capabilities.kt
Outdated
Show resolved
Hide resolved
kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/types/capabilities.kt
Outdated
Show resolved
Hide resolved
kpavlov
left a comment
kpavlov
left a comment
There was a problem hiding this comment.
Thank you, @eritscher
That looks good! Could you please take a look at the ktlint issues and also address the GitHub Copilot findings?
eritscher
force-pushed
the
add-extensions-capabilities
branch
from
171a9e8 to
bc8514d
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| public val roots: Roots? = null, | ||
| public val elicitation: JsonObject? = null, | ||
| public val experimental: JsonObject? = null, | ||
| public val extensions: Map<String, JsonObject>? = null, | ||
| ) { |
There was a problem hiding this comment.
Adding the new extensions parameter to ClientCapabilities changes the primary constructor/signature and Kotlin default-args synthetic constructor, which is ABI-breaking for already-compiled Kotlin/Java consumers (potential NoSuchMethodError). This should be called out as a breaking change in the PR/release notes, or mitigated by preserving the old constructor signature (e.g., a deprecated secondary constructor delegating to the new one with extensions = null).
There was a problem hiding this comment.
@kpavlov not sure if this is a false positive. It doesn't look anything has been done to preserve constructor signatures in the past. I can mention this in the PR description.
| val prompts: Prompts? = null, | ||
| val logging: JsonObject? = null, | ||
| val completions: JsonObject? = null, | ||
| val experimental: JsonObject? = null, | ||
| val extensions: Map<String, JsonObject>? = null, |
There was a problem hiding this comment.
Same ABI concern as ClientCapabilities: adding extensions changes the ServerCapabilities constructor and breaks binary compatibility for compiled consumers. Please mark as breaking and/or add a compatibility constructor overload delegating with extensions = null.
kpavlov
force-pushed
the
add-extensions-capabilities
branch
from
bc8514d to
924f425
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@kpavlov / @devcrocod |
…bilities Add support for MCP extension negotiation during the initialize handshake, as defined in the MCP extensions specification. Clients and servers can now advertise supported extensions via a new `extensions: Map<String, JsonObject>?` field on their respective capabilities objects.
kpavlov
force-pushed
the
add-extensions-capabilities
branch
from
d073294 to
b6eaeb6
Compare
Add support for MCP extension negotiation during the initialize handshake, as defined in the MCP extensions specification. Clients and servers can now advertise supported extensions via a new
extensions: Map<String, JsonObject>?field on their respective capabilities objects.Motivation and Context
Extensions are supported part of the MCP spec and are available in other language libraries e.g. Golang .
How Has This Been Tested?
Existing and added unit tests
Breaking Changes
Adding a new field to existing ClientCapabilities and ServerCapabilities fields will break already compiled clients. They will need to recompile on upgrading.
Types of changes
Checklist
Additional context