Tweak how McpClientTool.InvokeAsync exposes some content

[stephentoub]

Enhanced InvokeCoreAsync in McpClientTool.cs to handle non-text content by converting it to AIContent when possible. This enables richer content handling for downstream IChatClients while maintaining fallback serialization for unsupported cases.

[PederHP]

Ah, this looks great for IChatClients with media tool result support.

The tests made me think that ResourceLinks could be handled similar to how vs code does.

Afaik it resolves those in a way where the message history retains that it's a link, and then it fetches the resource from the mcp server when needed, ie after tool call and on reconnect/resume.

It's tangential to this PR I know, but having a resource link AIContent with an McpClient reference and dynamic resolution would replicate this I think.

[narasamdya]

Left a small question in the PR; otherwise LGTM.

[stephentoub]

I almost prefer the existing behavior of always returning a JsonElement, since at least it's consistent.

This means that logic like this can't work:
https://github.com/dotnet/extensions/blob/3168e4d5c71be2e33c84a3d1e8a662450095f7be/src/Libraries/Microsoft.Extensions.AI.OpenAI/OpenAIResponsesChatClient.cs#L936

Doesn't this lose the "isError": true from the CallToolResult?

Yes, I'd addressed that as well as always converting, but it seems like I neglected to push my commit.

[stephentoub]

@halter73, @PederHP, what do you think about the latest variation?

[PederHP]

I think it's good. It has no way of combining AIContent conversion and structured output which might become an emerging pattern, given how it seems structured content is becoming a pseudo-metadata payload (ie OpenAI apps SDK). But one can do that conversion in middleware that will exist in such clients anyway.

Converting to AIContent whenever possible, is a pattern I've become fonder of in general, so I am glad to see it repeat here. Preserving IsError is good.