Follow-ups for MCP tool

[stephentoub]

#6664 adds the MCP tool and supporting types as experimental. Some things to follow-up on before marking them stable:

• Do we need the base "user input" / "user output" types?
• The OpenAI Responses implementation currently looks for the tool approval as part of a Tool message. Is that right? Should it be User instead? Should it be any kind of message?
• Responses exposes a single MCP tool call message / instance, rather than a separate one for call and a separate one for result. We instead currently model it as two types, one for request and one for result. Is that the right split?
• The naming of "id" parameters is confusing; it's not clear which ID they're referring to, and more than once I passed in the wrong ID. We should revisit the naming.
• We need to ensure the hosted MCP tool works with variations, like OpenAI's connectors. This might entail replacing the Url property with something more general, possibly just a rename.

cc: @jozkee

[David] Adding another point to above list:

• In McpServerToolCallContent, it is too harsh to require Server name since it is only useful to disambiguate in cases of tool name collisions. We need to revisit which properties are required, at the bare minimum we should keep CallId.

[jozkee]

Do we need the base "user input" / "user output" types?

We briefly discussed having a common abstraction between FunctionApproval*Content and McpServerToolApproval*Content e.g.

public abstract class ApprovalRequestContent : UserInputRequestContent
{
    protected ApprovalRequestContent(string id) : base(id) { }

    public abstract ApprovalResponseContent CreateResponse(bool approved);
}

FunctionApprovalRequestContent : ApprovalRequestContent
McpServerToolApprovalRequestContent : ApprovalRequestContent

This way, you wouldn't have to write code to handle both types, just ApprovalRequestContent.
A problem I see with that is covariance for CreateResponse will not work for ns2.0 and netfx.

[jozkee]

The OpenAI Responses implementation currently looks for the tool approval as part of a Tool message. Is that right? Should it be User instead? Should it be any kind of message?

I think handling it for any kind of ChatRole would be the best. @westey-m, why did we go with FunctionApprovalRequestContent CreateResponse(bool) and not ChatMessage CreateResponse(bool) so we could decide which role was best for an approval response?

[westey-m]

@westey-m, why did we go with FunctionApprovalRequestContent CreateResponse(bool) and not ChatMessage CreateResponse(bool) so we could decide which role was best for an approval response?

@jozkee, It was because ChatMessage is slightly higher in the stack than AIContent and its subclasses. ChatMessage references AIContent, not typically the other way around. It's therefore less desirable for ApprovalRequestContent to reference ChatMessage. It is also a bit asymmetric when an request content doesn't generate a response content but rather a message containing a response content.

There is no technical constraint though, since both are in the same nuget package. We can certainly revisit this decision. It does provide a nicer user experience when returning ChatMessage, although there is more risk for confusion.

[PederHP]

• Responses exposes a single MCP tool call message / instance, rather than a separate one for call and a separate one for result. We instead currently model it as two types, one for request and one for result. Is that the right split?

It would align with Gemini and Anthropic which both split them in two. Gemini also allows the the result to not immediately follow the result, which is impossible to represent if they get merged. I know that there aren't official support for these in MEAI, but I think multi-provider is a decently common use case.

[stephentoub]

I know that there aren't official support for these in MEAI

There is, in that M.E.AI is the abstractions that are intended to be able to represent all of the services that are out there. The abstractions must take into account how all of these providers do things.

[jeffhandley]

Follow-up items merged into #6492.