Unseal FunctionCallContent/FunctionResultContent; make MCP types extend them

[Copilot]

Address Review Feedback - All Comments Resolved ✅

All new review comments have been addressed:

Documentation Changes

1. ✅ FunctionApprovalRequestContent - Reverted parameter documentation from "requires user approval" back to "requires approval"
2. ✅ FunctionApprovalResponseContent - Reverted parameter documentation from "requires user approval" back to "for which approval was requested"
3. ✅ Reverted CreateResponse documentation from "function call" back to "call"

Constructor Changes

4. ✅ McpServerToolCallContent - Removed arguments: null parameter from base constructor call

JSON Serialization Changes

5. ✅ Changed all deserializations from IReadOnlyDictionaryStringObject to IDictionaryStringObject:

   • Line 212: McpToolCallApprovalRequestItem deserialization
   • Line 426: McpToolCallApprovalRequestItem streaming deserialization
   • Line 1298: AddMcpToolCallContent deserialization

6. ✅ Changed all serializations to use IDictionaryStringObject:

   • Line 1083: McpServerToolCallContent Arguments serialization
   • Line 1096: FunctionCallContent Arguments serialization (changed from AIJsonUtilities to OpenAIJsonContext)

FunctionInvokingChatClient Changes

7. ✅ Reverted error message from "CallId(s)" back to "FunctionCall.CallId(s)"
8. ✅ Simplified ApprovalResultWithRequestMessage struct - removed XML doc comment since we're using concrete FunctionCallContent type

All changes maintain the breaking changes we accepted (using IDictionary instead of IReadOnlyDictionary) while simplifying the code.

Original prompt

Can you take over #7104, augment it with implementing McpServerToolCallContent and McpServerToolResultContent by unsealing and extending FunctionCallContent and FunctionResultContent, add the necessary compatibility suppressions, update the branch and resolve conflicts.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Microsoft Reviewers: Open in CodeFlow

[jozkee]

@copilot please fix errors and address feedback.

[Copilot]

@copilot please fix errors and address feedback.

All feedback addressed in commits 598f78b, 23d5d20, and 29454f9. Changes include:

• Reverted to FunctionCallContent FunctionCall in approval types
• Removed wrapper properties from MCP types (breaking changes accepted)
• Fixed idToContentMapping type and simplified logic
• Added missing tests from PR Replace Mcp approvals with Function approvals #7104
• Fixed all build errors (unused usings, type conversions, property renames)

stale

[Copilot]

Pull request overview

This PR refactors the MCP (Model Context Protocol) approval types to use a unified approval mechanism by extending the existing FunctionCallContent and FunctionResultContent base types instead of having separate MCP-specific approval types.

Changes:

• Unsealed FunctionCallContent and FunctionResultContent to allow inheritance
• Made McpServerToolCallContent and McpServerToolResultContent extend the unsealed base types
• Removed McpServerToolApprovalRequestContent and McpServerToolApprovalResponseContent, using the unified FunctionApprovalRequestContent/FunctionApprovalResponseContent instead
• Changed Arguments from IReadOnlyDictionary<string, object?> to IDictionary<string, object?> for mutability
• Renamed Output property to Result in McpServerToolResultContent to align with base class

Reviewed changes

Copilot reviewed 24 out of 24 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
FunctionCallContent.cs	Unsealed class to allow inheritance
FunctionResultContent.cs	Unsealed class to allow inheritance
McpServerToolCallContent.cs	Now extends FunctionCallContent, exposing ToolName as alias for Name
McpServerToolResultContent.cs	Now extends FunctionResultContent
McpServerToolApprovalRequestContent.cs	Deleted - replaced by FunctionApprovalRequestContent
McpServerToolApprovalResponseContent.cs	Deleted - replaced by FunctionApprovalResponseContent
FunctionInvokingChatClient.cs	Added pattern matching to exclude McpServerToolCallContent from local approval processing; fixed spelling error
OpenAIResponsesChatClient.cs	Updated to use unified approval types; adjusted serialization for IDictionary
CompatibilitySuppressions.xml	Added suppressions for breaking changes
Test files	Updated tests to use unified approval types; added comprehensive mixed-scenario tests

[stephentoub]

I'm unclear how this is intended to work.

If a service sends an MCP call content, how does the client know it's not supposed to try to invoke something for it? Is this based on the premise that an FCC has an InvocationRequired property? Or is it based on the premise that FCCs that come with a paired FRC are implicitly considered not requiring invocation, in which case case what happens if the server sends the MCP call in one response and either doesn't have result content or sends it in a separate response?

Also, the FICC is being modified here to explicitly rule out some FCC-derived types. It doesn't scale for FICC to have to know about every FCC-derived type that should be ignored.