-
Notifications
You must be signed in to change notification settings - Fork 839
Open
Labels
area-aiMicrosoft.Extensions.AI librariesMicrosoft.Extensions.AI libraries
Milestone
Description
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:
- 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. - Add a
HostedMcpServerToolCall : AIContent
to represent the call the service makes to the server (including tool name and arguments) and similarly aHostedMcpServerToolResult
to represent the result of the operation. - 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.
- For
IChatClient
that don't have this capability, we can enable it via anMcpServerChatClient : IChatClient
that itself uses MCP clients. It would translate aHostedMcpServer
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. - Update FunctionInvokingChatClient to support automatic approval.
- Add a
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:
- 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?
- 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).
- 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.
- 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.
emmekappa and rogerbarreto
Metadata
Metadata
Assignees
Labels
area-aiMicrosoft.Extensions.AI librariesMicrosoft.Extensions.AI libraries