-
Notifications
You must be signed in to change notification settings - Fork 318
Description
Is your feature request related to a problem? Please describe.
Currently the CallTool function only handles text output well.
If the Caller expects a specific type e.g. map[string]int or a struct then the Caller has to workaround the current state of the SDK.
This leads to unnecessary CPU and Memory Consumption and that despite of the server side of the SDK handling this scenario so well.
Describe the solution you'd like
There is a variant of my request with and without generics
Without generics, the CallTool function would allow to specify the output reference e.g.
CallTool(..., output any) error
The SDK would then directly unmarshal into the output reference.
Describe alternatives you've considered
So above is not a show stopper, as a workaround exists
Additional context
Here my workaround code:
result, err := session.CallTool(c.context, &mcp.CallToolParams{
Name: toolName,
Arguments: input,
Meta: mcp.Meta{"progressToken": progressToken},
})
if err != nil {
return err
}
if result.IsError {
var errMsg string
for _, content := range result.Content {
if tc, ok := content.(*mcp.TextContent); ok {
if errMsg != "" {
errMsg += "\n"
}
errMsg += tc.Text
}
}
if errMsg == "" {
errMsg = "tool call failed"
}
return errors.New(errMsg)
}
if output == nil {
return nil
}
var textContent *mcp.TextContent
for _, content := range result.Content {
if tc, ok := content.(*mcp.TextContent); ok {
textContent = tc
break
}
}
if textContent == nil {
return errors.New("unexpected content type in tool result")
}
if output != nil {
if err := json.Unmarshal([]byte(textContent.Text), output); err != nil {
return err
}
}Needless to say, I dont like it.