I have some ideas about having a handler function that injects:

typeClientsstruct { rest..gql..}

Then all handlers don't have thisgetClient boilerplate. Added a lot of types though, would rather feel a bit more pain.

It doesn't really matter, but I do love EOF newlines being added by automation rather than omitted if it's possible.

I can add it, but I don't really understand why it's useful to you? Does it help in your IDE or something?

Do we want to return an mcp.Tool or have our own struct that gets converted later, I suppose it's an utter pain to make versions of all their structs.

I want our own types that can be adapted for mcp-go/go-sdk but I'm not paying that price right now. I want to do the move over to the typed handlers and then iterate from there.

Nice to see use of the typed handler (although this tool is not much of a showcase 😂).

I was going to ask the same thing as above, do we want to usemcp-go structs here. I suppose we should for now.

A use case I can imagine is wrapping an existing handler with another one (to add something like chunking, or other aggregations like returning only the count). That sad part with the string output is that instead of Marshalling the data just-in-time, I would have to unmarshall the json again to process it in this form. 😓 this is a tough problem to solve without having to just re-write tools.

I had imagined we'd have a tool handler type that returns an interface (can be marshalled into json whatever that interface is called), and error. We would then give that a thin wrapper that binds it intomcp-go. Maybe overkill for now, just something that is coming onto my radar.

All good thoughts and as per#447 (comment) there's lots I do want to tackle but I want to do it piecemeal where we move over to having a struct for args, then we can look at the abstractions that make sense around that, rather than biting it all off at once.