Update MCP contents to extend Function contents by Copilot · Pull Request #7245 · dotnet/extensions

Copilot · 2026-01-30T07:13:17Z

Summary

This PR consolidates MCP server tool approval flow by making McpServerToolCallContent and McpServerToolResultContent inherit from FunctionCallContent and FunctionResultContent respectively, instead of having separate approval types.

Changes

Extend function content types: Made McpServerToolCallContent extend FunctionCallContent and McpServerToolResultContent extend FunctionResultContent
Remove specialized approval types: Deleted McpServerToolApprovalRequestContent and McpServerToolApprovalResponseContent classes - MCP approvals now use the existing FunctionApprovalRequestContent and FunctionApprovalResponseContent
Add invocation flag: Added InvocationRequired property to FunctionCallContent (defaults to true). For McpServerToolCallContent, this defaults to false since MCP tool calls are informational
Update OpenAI integration: Modified OpenAIResponsesChatClient to work with the unified approval model
Add API compatibility suppressions: Documented breaking changes in CompatibilitySuppressions.xml

Impact

This reduces complexity by reusing existing function call/result abstractions rather than maintaining parallel MCP-specific approval types. The approval mechanism now works consistently for both regular function calls and MCP server tool calls.

Original prompt

Create a new pull request in dotnet/extensions with:

Base branch: main

Head branch: copilot/update-mcp-server-tool-invocation

User explicitly wants a new PR (do not attempt to update/retarget existing agent PR #7244).

Use an appropriate PR title/description derived from the branch name (update MCP server tool invocation). No additional code changes requested—just open the PR.

This pull request was created from Copilot chat.

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Microsoft Reviewers: Open in CodeFlow

Copilot

Pull request overview

This PR simplifies the MCP server tool invocation approval mechanism by consolidating approval types. Instead of having separate McpServerToolApprovalRequestContent and McpServerToolApprovalResponseContent classes, it makes McpServerToolCallContent and McpServerToolResultContent inherit from FunctionCallContent and FunctionResultContent respectively, and reuses the existing FunctionApprovalRequestContent and FunctionApprovalResponseContent for MCP approvals.

Changes:

Removed McpServerToolApprovalRequestContent and McpServerToolApprovalResponseContent classes
Made McpServerToolCallContent extend FunctionCallContent and McpServerToolResultContent extend FunctionResultContent
Added InvocationRequired property to FunctionCallContent (defaults to true, set to false for MCP tools)
Updated OpenAI integration and tests to work with the unified approval model
Added API compatibility suppressions for breaking changes

Reviewed changes

Copilot reviewed 25 out of 25 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
`McpServerToolApprovalRequestContent.cs`	Deleted - approval now handled through `FunctionApprovalRequestContent`
`McpServerToolApprovalResponseContent.cs`	Deleted - approval now handled through `FunctionApprovalResponseContent`
`McpServerToolCallContent.cs`	Now extends `FunctionCallContent`, inherits `Name`, `CallId`, and `Arguments` properties, sets `InvocationRequired = false`
`McpServerToolResultContent.cs`	Now extends `FunctionResultContent`, simplified to only add `CallId` through base constructor
`FunctionCallContent.cs`	Added `InvocationRequired` property and polymorphic JSON serialization for `McpServerToolCallContent`
`FunctionResultContent.cs`	Added polymorphic JSON serialization for `McpServerToolResultContent`
`UserInputRequestContent.cs`	Removed `McpServerToolApprovalRequestContent` from JSON derived types
`UserInputResponseContent.cs`	Removed `McpServerToolApprovalResponseContent` from JSON derived types
`AIContent.cs`	Updated comments to reflect removed types
`OpenAIResponsesChatClient.cs`	Updated to create `FunctionApprovalRequestContent` wrapping `McpServerToolCallContent` instead of separate MCP approval types, updated error handling to use `Result` property
`OpenAIJsonContext.cs`	Removed `IReadOnlyDictionary<string, object?>` serialization (now uses `IDictionary`)
`AIJsonUtilities.Defaults.cs`	Removed MCP approval types from JSON serialization registration
`FunctionInvokingChatClient.cs`	Updated approval filtering to check `InvocationRequired` property on function calls
`CompatibilitySuppressions.xml`	Added suppressions for removed types and changed properties across all target frameworks
Test files	Updated to use new API, added tests for mixed MCP/function approval scenarios, fixed namespace

...ies/Microsoft.Extensions.AI.Tests/ChatCompletion/FunctionInvokingChatClientApprovalsTests.cs

test/Libraries/Microsoft.Extensions.AI.OpenAI.Tests/OpenAIResponseClientTests.cs

test/Libraries/Microsoft.Extensions.AI.OpenAI.Tests/OpenAIResponseClientIntegrationTests.cs

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/FunctionResultContent.cs

stephentoub · 2026-01-30T16:30:50Z

@copilot please revise the PR summary based on the current state of the PR

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot · 2026-01-30T16:37:18Z

@copilot please revise the PR summary based on the current state of the PR

Updated the PR summary to accurately reflect the current state of the PR. The summary now correctly describes that McpServerToolCallContent and McpServerToolResultContent extend FunctionCallContent and FunctionResultContent respectively, and that InvocationRequired is only on FunctionCallContent (not FunctionResultContent).

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

…alization and tests

Copilot

Pull request overview

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

jozkee · 2026-01-30T21:49:04Z

src/Libraries/Microsoft.Extensions.AI.OpenAI/OpenAIResponsesChatClient.cs

-            Output = [mtci.Error is not null ?
-                new ErrorContent(mtci.Error.ToString()) :
-                new TextContent(mtci.ToolOutput)],
+            Result = mtci.Error ?? (object)mtci.ToolOutput,


I think this is not a big concern for McpServerToolResultContent because it's content intended for the LLM and just included in the messages for information reasons.

There's no clear way to identify results as errors. Using ErrorContent was also somewhat of a bug because OpenAI's McpToolCallItem.Error is BinaryData so we were turning that into string in order to pack it in ErrorContent.

Using ErrorContent was also somewhat of a bug

Can you elaborate? McpToolCallItem.Error for whatever reason is modeled in the client as BinaryData, but it's a string in OpenAI's docs:
https://platform.openai.com/docs/api-reference/responses/object#responses-object-output-mcp_tool_call-error
which just means the client library is choosing to represent it as bytes.

OpenAI docs are wrong, in my testing, error is returned as object. See also openai/openai-dotnet#596 (comment).

If it's a json object that can still be represented as a string. The binary data is effectively just a utf8 string.

OK, that's fair. FICC sets Result as "Error: Function failed" when an AIFunction throws, do we want to

align this with that and return $"Error: {mtci.Error.ToString()}" or

Keep wrapping with ErrorContent to keep fidelity with previous behavior?

If we go with the second, I don't think we would want to change FICC to wrap errors in ErrorContent since it may be too disruptive.

I think I'm missing the context. Can you expand on the question? What is it you're trying to do?

stephentoub

This direction makes sense to me.

stephentoub · 2026-02-03T13:45:52Z

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/McpServerToolCallContent.cs

-    public McpServerToolCallContent(string callId, string toolName, string? serverName)
+    /// <exception cref="ArgumentNullException"><paramref name="callId"/> or <paramref name="name"/> is <see langword="null"/>.</exception>
+    /// <exception cref="ArgumentException"><paramref name="callId"/> or <paramref name="name"/> is empty or composed entirely of whitespace.</exception>
+    [JsonConstructor]


Is this necessary?

stephentoub · 2026-02-03T13:46:19Z

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/FunctionCallContent.cs

+// If they're included while still experimental, any JsonSerializerContext that includes
+// FunctionCallContent will incur errors about using experimental types in its source generated files.
+// [JsonPolymorphic(TypeDiscriminatorPropertyName = "$type")]
+// [JsonDerivedType(typeof(McpServerToolCallContent), "mcpServerToolCall")]


I assume our plan is that all this becomes stable as part of this PR? Assuming yes, can you fix up the commented-out code accordingly?

stephentoub · 2026-02-03T13:46:27Z

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/FunctionCallContent.cs

+// These should be added in once McpServerToolCallContent is no longer [Experimental].
+// If they're included while still experimental, any JsonSerializerContext that includes
+// FunctionCallContent will incur errors about using experimental types in its source generated files.
+// [JsonPolymorphic(TypeDiscriminatorPropertyName = "$type")]


Is this necessary?

Are you questioning whether the JsonPolymorphic attributes are necessary if uncommented? If so, I believe yes if we want to support polymorphism. I was following what we did for other derived AIContents.

extensions/src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/UserInputRequestContent.cs

Lines 16 to 18 in 99b3272

[JsonPolymorphic(TypeDiscriminatorPropertyName = "$type")]

[JsonDerivedType(typeof(FunctionApprovalRequestContent), "functionApprovalRequest")]

[JsonDerivedType(typeof(McpServerToolApprovalRequestContent), "mcpServerToolApprovalRequest")]

The JsonDerivedType attrs are necessary. I'm questioning specifically the JsonPolymorphic attribute, since it's specifying the default discriminator.

stephentoub · 2026-02-03T13:47:12Z

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/McpServerToolCallContent.cs

+    /// <exception cref="ArgumentException"><paramref name="callId"/> or <paramref name="name"/> is empty or composed entirely of whitespace.</exception>
+    [JsonConstructor]
+    public McpServerToolCallContent(string callId, string name, string? serverName)
+        : base(Throw.IfNullOrWhitespace(callId), Throw.IfNullOrWhitespace(name))


The base is just validating not-null on callId. Why does the derived also need to validate not-whitespace?

That is the current behavior in main. Looks like FCC allows whitespace to signal a nop function.

extensions/src/Libraries/Microsoft.Extensions.AI/ChatCompletion/FunctionInvocationContext.cs

Line 42 in 99b3272

get => field ??= new(string.Empty, _nopFunction.Name, EmptyReadOnlyDictionary<string, object?>.Instance);

There shouldn't be a case for a remote mcp call to have an empty id, I'd prefer keeping the tighter validation in here.

stephentoub · 2026-02-03T13:47:50Z

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/McpServerToolResultContent.cs

    /// <exception cref="ArgumentException"><paramref name="callId"/> is empty or composed entirely of whitespace.</exception>
+    [JsonConstructor]
    public McpServerToolResultContent(string callId)
+        : base(Throw.IfNullOrWhitespace(callId), result: null)


Same question

stephentoub · 2026-02-03T13:48:09Z

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/McpServerToolResultContent.cs

    /// <param name="callId">The tool call ID.</param>
    /// <exception cref="ArgumentNullException"><paramref name="callId"/> is <see langword="null"/>.</exception>
    /// <exception cref="ArgumentException"><paramref name="callId"/> is empty or composed entirely of whitespace.</exception>
+    [JsonConstructor]


For all of these [JsonConstructor]s, I'm not sure why they're needed.

I was following FCC/FRC pattern, but as per https://learn.microsoft.com/dotnet/standard/serialization/system-text-json/immutability#parameterized-constructors those are also not necessary.

For a class, if the only constructor is a parameterized one, that constructor will be used.

stephentoub · 2026-02-03T13:48:47Z

src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/UserInputRequestContent.cs

 [JsonPolymorphic(TypeDiscriminatorPropertyName = "$type")]
 [JsonDerivedType(typeof(FunctionApprovalRequestContent), "functionApprovalRequest")]
-[JsonDerivedType(typeof(McpServerToolApprovalRequestContent), "mcpServerToolApprovalRequest")]
 public class UserInputRequestContent : AIContent


I saw in your API proposal that this was being renamed. Can this PR be made to reflect all the changes you're hoping to make in one fell swoop?

stephentoub · 2026-02-03T13:54:09Z

src/Libraries/Microsoft.Extensions.AI.OpenAI/OpenAIResponsesChatClient.cs

-            Output = [mtci.Error is not null ?
-                new ErrorContent(mtci.Error.ToString()) :
-                new TextContent(mtci.ToolOutput)],
+            Result = mtci.Error ?? (object)mtci.ToolOutput,


I think I'm missing the context. Can you expand on the question? What is it you're trying to do?

Initial plan

2daa4b4

Copilot AI assigned Copilot and jozkee Jan 30, 2026

Copilot started work on behalf of jozkee January 30, 2026 07:13 View session

jozkee added 2 commits January 30, 2026 07:18

Rebase

b5dac2d

Add CompatibilitySuppressions.xml

052dbe3

Copilot AI changed the title ~~[WIP] Update MCP server tool invocation~~ Simplify MCP server tool invocation approval mechanism Jan 30, 2026

Copilot AI requested a review from jozkee January 30, 2026 07:19

Copilot finished work on behalf of jozkee January 30, 2026 07:19

jozkee marked this pull request as ready for review January 30, 2026 07:19

jozkee requested a review from a team as a code owner January 30, 2026 07:19

Copilot AI review requested due to automatic review settings January 30, 2026 07:19

Copilot started reviewing on behalf of jozkee January 30, 2026 07:19 View session

jozkee changed the title ~~Simplify MCP server tool invocation approval mechanism~~ Update MCP contents to extend Function contents Jan 30, 2026

jozkee requested a review from stephentoub January 30, 2026 07:21

Copilot AI reviewed Jan 30, 2026

View reviewed changes

Copilot started work on behalf of stephentoub January 30, 2026 16:31 View session

Fix ToolName->Name and CloneFcc to handle McpServerToolCallContent

59b5ebb

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Remove duplicate assertion for mcpCallContent.Name

500863e

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot finished work on behalf of stephentoub January 30, 2026 16:43

Update handling of experimental McpServerTool types in sourcegen seri…

0ee1ed6

…alization and tests

jozkee requested a review from Copilot January 30, 2026 17:32

Copilot started reviewing on behalf of jozkee January 30, 2026 17:32 View session

Copilot AI reviewed Jan 30, 2026

View reviewed changes

jozkee mentioned this pull request Jan 30, 2026

[API Proposal]: Abstract ToolResult Class. #7057

Open

jozkee reviewed Jan 30, 2026

View reviewed changes

jozkee mentioned this pull request Feb 2, 2026

[API Proposal]: Function approvals and MCP abstractions #7254

Open

stephentoub reviewed Feb 3, 2026

View reviewed changes

	[JsonPolymorphic(TypeDiscriminatorPropertyName = "$type")]
	[JsonDerivedType(typeof(FunctionApprovalRequestContent), "functionApprovalRequest")]
	[JsonDerivedType(typeof(McpServerToolApprovalRequestContent), "mcpServerToolApprovalRequest")]

Conversation

Copilot AI commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Impact

Microsoft Reviewers: Open in CodeFlow

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stephentoub commented Jan 30, 2026

Uh oh!

Copilot AI commented Jan 30, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jozkee Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoub left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jozkee Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Jan 30, 2026 •

edited

Loading

jozkee Jan 31, 2026 •

edited

Loading

jozkee Feb 3, 2026 •

edited

Loading