-
Notifications
You must be signed in to change notification settings - Fork 156
Adds 'instructions' string to the Server and propagates to the InitializeResult #290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Adds 'instructions' string to the Server and propagates to the InitializeResult #290
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR implements the optional instructions
field from the MCP schema version "2025-03-26" by adding it to the Server constructor and propagating it through to the InitializeResult.
- Added
instructions
parameter to Server constructor with default value of null - Updated InitializeResult data class to include optional instructions field
- Added comprehensive test coverage for the new functionality
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
File | Description |
---|---|
kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/types.kt | Added instructions field to InitializeResult data class with documentation |
kotlin-sdk-server/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/server/Server.kt | Updated Server constructor to accept instructions parameter and pass it to InitializeResult |
kotlin-sdk-core/src/commonTest/kotlin/io/modelcontextprotocol/kotlin/sdk/TypesTest.kt | Added comprehensive tests for InitializeResult with and without instructions |
kotlin-sdk-test/src/jvmTest/kotlin/io/modelcontextprotocol/kotlin/sdk/server/ServerTest.kt | Added tests for Server constructor with instructions parameter variants |
kotlin-sdk-core/api/kotlin-sdk-core.api | Updated API signatures to reflect new InitializeResult structure |
kotlin-sdk-server/api/kotlin-sdk-server.api | Updated API signatures to reflect new Server constructor |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
0d8253e
to
6a95a59
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @jclyne
I have one question about testing, but overall looks good to me
} | ||
|
||
@Test | ||
fun `Server constructor should accept instructions parameter`() = runTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the test!
One question: Is it possible to verify in the test that the server has received the instructions string?
Also, the test could be parametrized
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The serverInstructions were added to the client as a property that can be verified in these tests.
val json = McpJson.encodeToString(result) | ||
val decoded = McpJson.decodeFromString<InitializeResult>(json) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think we should introduce some serialization helper for tests like this, like here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would probably be applicable to all the tests in this file, so I would prefer to leave it to a different PR if that's ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with both statements
…ons' into support-for-mcp-server-instructions
# Conflicts: # kotlin-sdk-server/api/kotlin-sdk-server.api # kotlin-sdk-server/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/server/Server.kt
…ation to the ServerTests (addresses PR feedback)
…sourced dynamically for each session if desired
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
kotlin-sdk-client/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/client/Client.kt
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@kpavlov We also need this for parity with FastMCP python servers. Any chance you can ballpark an ETA for this getting merged/released? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution!
I have a question regarding the api design, could you please take a look?
Everything else looks good to me!
public open class Server( | ||
protected val serverInfo: Implementation, | ||
protected val options: ServerOptions, | ||
protected val instructionsProvider: (() -> String)? = null, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this implemented as a lambda and not just a string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is allowing the instructions to potentially be dynamically loaded from a database or string server. With the change to the ServerSession, the Server seems to take more of a Singleton scope vs a Server per stream. The idea is that the Server has a provider method for the string which it evaluates as a string value for the ServerSession.
Its possible to add an additional constructor that just takes a static string and converts it to a lamda, but that is trivial for the caller.
I went ahead and added an alternative constructor that takes a static string
Hi @jclyne In the meantime, next week we’d like to set up snapshot releases |
Thanks @devcrocod! I would like to get this in the snapshot release if at all possible. |
Motivation and Context
The schema for the InitializeResult contains an optional 'instructions' string
How Has This Been Tested?
Its relatively simple change with unit tests included
Breaking Changes
No, field is optional and defaults to null
Types of changes
Checklist
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
andinstructions
properties to be protected. ThisServer
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.