Create representations for hosted MCP servers and content

[stephentoub]

AI services are starting to support server-side use of MCP servers. For example, Anthropic's service:
https://docs.anthropic.com/en/docs/agents-and-tools/mcp-connector
and OpenAI responses:
https://platform.openai.com/docs/guides/tools-remote-mcp

With the ModelContextProtocol library, it's easy to use any MCP server, including stdio ones, locally, treating every tool as an AIFunction, but there's not currently an abstraction for the hosted MCP server case, where the service uses the server directly.

• Rough sketch of how we could handle this well:
  1. Add a HostedMcpServer : AITool. This would be configurable with all the common stuff: server url, optional list of allowed tool names, indication of whether to allow auto invocation, etc.
  2. Add a HostedMcpServerToolCall : AIContent to represent the call the service makes to the server (including tool name and arguments) and similarly a HostedMcpServerToolResult to represent the result of the operation.
  3. The MCP spec recommends human in the loop on tool calls, and the OpenAI design defaults to not automatically invoking tools; interestingly Anthropic's doesn't, but I suspect that's coming. We might also need an AIContent to represent approval/denial for the server invoking a server-side tool.
  4. For IChatClient that don't have this capability, we can enable it via an McpServerChatClient : IChatClient that itself uses MCP clients. It would translate a HostedMcpServer tool into creating an McpClient and replacing the tool in the tool collection with the appropriate McpClientTool instances. With a FunctionInvokingChatClient in the pipeline, it would enable then similar automatic handling of MCP Server interactions.
     Add UseMcpClient modelcontextprotocol/csharp-sdk#1086.
  5. Update FunctionInvokingChatClient to support automatic approval.

Additional details originally captured in Follow-ups for MCP tool (#6779):

• Add abstraction for remote MCP servers #6664 adds the MCP tool and supporting types as experimental. Some things to follow-up on before marking them stable:
  1. Do we need the base "user input" / "user output" types?
  2. 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?
  3. We need to be stricter about which roles can contain approval responses, only user roles should be allowed, this applies to both MCP and FICC. We can reconsider supporting other roles in the future Add support for Connector ID and other follow ups #6881 (comment).
  4. 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?
  5. 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.
     UserInput Request/Response: rename id to requestId #7106
  6. 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.
  7. 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.
  8. Consider replacing Mcp approval types with Function approval ones: Create representations for hosted MCP servers and content #6492 (comment).
  9. Consider introducing a type for representing Server-side calls to avoid needing to introduce specialized contents for everything of this class e.g. OpenAPI and MCP: Create representations for hosted MCP servers and content #6492 (comment).

[jozkee]

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

Aside from what I said in #6779 (comment), I'm not opposed to remove them, I that could also alleviate 4. "The naming of "id" parameters is confusing".

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?

I resonate with Peder on #6779 (comment) and I don't think we need to change it. I will strike this one if you all agree.

[stephentoub]

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

We need them. Only debate is naming I think.