Proposal: have CallToolRequest hold CallToolParamsRaw #377
Description
In #327, we eliminated CallToolParamsFor[In]. In order to do this, we had to make a decision: what should the type of CallToolParams.Arguments be? json.RawMessage makes it easy to delegate server-side unmarshalling to the user, and avoid double-unmarshalling in typed tool handlers. However, it makes the client API awkward, since the user has to marshal its arguments before calling a tool.
To work around this, we opted for setting CallToolParams.Arguments to type any, and documented that on the server side the concrete type will be json.RawMessage. This allows the client side to pass any JSON-marshallable value. And so gives us the "best of both worlds".
However, I think the server side is a footgun we can avoid. If anyone is trying to implement their own tool binding, it's too easy to miss that the any is actually json.RawMessage and type assert to map[string]any.
I propose we change CallToolRequest.Params to be a CallToolParamsRaw, which is identical except for its Arguments field, which is json.RawMessage. This is a breaking change, but a minor one: the value of Arguments was already json.RawMessage, this just aligns its type with its value. Furthermore, users aren't writing this type name, they're just accessing the field or using the already-unmarshalled arguments.
As for the name: RawCallToolParams might be more grammatical, but CallToolParamsRaw sorts better in godoc.