Tool Annotations struct has differently typed hints

[Vanja-S]

Describe the bug
The ToolAnnotations struct has hints with inconsistent types:

type ToolAnnotations struct {
	// If true, the tool may perform destructive updates to its environment. If
	// false, the tool performs only additive updates.
	//
	// (This property is meaningful only when ReadOnlyHint == false.)
	//
	// Default: true
	DestructiveHint *bool `json:"destructiveHint,omitempty"`
	// If true, calling the tool repeatedly with the same arguments will have no
	// additional effect on the its environment.
	//
	// (This property is meaningful only when ReadOnlyHint == false.)
	//
	// Default: false
	IdempotentHint bool `json:"idempotentHint,omitempty"`
	// If true, this tool may interact with an "open world" of external entities. If
	// false, the tool's domain of interaction is closed. For example, the world of
	// a web search tool is open, whereas that of a memory tool is not.
	//
	// Default: true
	OpenWorldHint *bool `json:"openWorldHint,omitempty"`
	// If true, the tool does not modify its environment.
	//
	// Default: false
	ReadOnlyHint bool `json:"readOnlyHint,omitempty"`
	// A human-readable title for the tool.
	Title string `json:"title,omitempty"`
}

Expected behavior
We expect that the types would be consistent between all hints either a boolean or a bool pointer.

[maciej-kisiel]

Please see #44 for explanation why it is modeled like this. Theoretically, I guess all annotations could be pointers, but:

1. That would be a backwards incompatible change, which we cannot make in v1.
2. It makes setting the currently non-pointer fields less convenient.
3. I believe it will also result in inclusion of the false defaults on the wire, increasing the payload sizes. I don't this this is desirable.

[Vanja-S]

Hey, thanks for the quick response. I looked at the mentioned issues. I guess it makes for a point regarding why it is implemented this way.
It could be just me, but IMHO this is not really an intuitive solution for the defaults problem. Maybe I can reopen the issue if and when a better alternative hits me.