Support a strongly typed InputSchema

[rustyrazorblade]

Is your feature request related to a problem? Please describe.

The input schema is currently a json object, leaving the user to bang their head against the wall to figure out what should be passed in.

Describe the solution you'd like

A strongly typed InputSchema, with properties, required, additionalProperties.

Describe alternatives you've considered

Generating a type from a class would be nice, but I think it should generate an InputSchema object, not a json object.

Additional context

No additional context.

[devcrocod]

Do you mean an input schema for Tool?

In that case, it was already typed initially:

kotlin-sdk/kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/types.kt

Line 1236 in 458a49a

val inputSchema: Input,

Currently, the Input object doesn’t have the additionalProperties field, which we can add

[rustyrazorblade]

Well, what I mean is something more idiomatic Kotlin. Passing a JsonObject as schema in Kotlin is pretty strange to me. Being able to use a generic here and support a typed return would make more sense, I think:

Maybe something like this, effectively:

server.addTool<InputType, ReturnType>() { input ->
  ReturnType(input)
}

[devcrocod]

Okay, I see
btw, we still need to pass a json object, since the tool itself is defined through a json schema. We’re currently working on a library that can generate a json schema from a function. This should be a separate library, not part of the sdk.

The problem is that we can’t really do what you suggested, because a tool is essentially just a function. And we can’t pass it as a generic type. The only alternative would be to completely change the approach and use classes with an invoke method, but in my opinion that would be more of a workaround and not an intuitive solution for users.

I’m considering adding a temporary solution that would allow passing a function as a parameter and automatically generating a json schema for it via reflection (jvm only). But for now, passing a json object to describe the function schema remains the most reliable and straightforward option, even if it’s not the most convenient one

[rustyrazorblade]

I think I understand the reasoning behind the limitations. I see why you're suggesting a library, it may be the right approach.

The concern I have is that as the SDK stands today, I would definitely not call setting up tools straightforward or reliable. I spent an absurd number of hours trying to figure out why I got the return type wrong in my JSON object, eventually finding that I was incorrectly wrapping some data with an extra unnecessary layer. The lack of any sort of type checking - either runtime or compile time, made this a pretty frustrating experience.

I'll do some thinking on this and see if I can come up with something tangible that I can share for improvement.