Fix ToJsonObject serialization failure with anonymous types and add support for custom JsonSerializerOptions

[Copilot]

Fix ToJsonObject serialization failure with anonymous types

Fixes a regression in 0.5.0-preview.1 where AIContent.AdditionalProperties containing anonymous types (e.g., from Semantic Kernel sampling) would fail with NotSupportedException during serialization.

Changes Made

• Fixed serialization of anonymous types: Changed ToJsonObject to use McpJsonUtilities.DefaultOptions.GetTypeInfo(typeof(IReadOnlyDictionary<string, object?>)) instead of strongly-typed JsonContext.Default.IReadOnlyDictionaryStringObject, allowing the resolver chain to handle user-defined types through reflection when available.

• Added optional JsonSerializerOptions parameters throughout the SDK: Added optional JsonSerializerOptions parameter to all public APIs that serialize or deserialize user-provided objects, enabling users to pass custom serialization options (converters, naming policies, type resolvers):

  • ToContentBlock - for converting AIContent to MCP protocol types
  • ToAIContent - for converting protocol types to AIContent
  • ToAIContents - for converting multiple content blocks
  • ToChatMessage - for converting protocol messages to chat messages
  • CreateSamplingHandler - for creating sampling handlers with custom serialization
  • AsSamplingChatClient - for creating sampling chat clients
  • McpServer.SampleAsync - for sampling operations with custom serialization
  • ToJsonObject (internal, required parameter) - for converting dictionaries to JsonObject

• Complete serialization chain coverage: Updated all serialization and deserialization operations throughout the library to accept and properly pass through user-supplied JsonSerializerOptions, ensuring no location in the library hard-codes McpJsonUtilities.DefaultOptions when serializing arbitrary user-provided objects.

• Comprehensive testing: Added tests in AIContentExtensionsTests.cs and McpClientToolTests.cs covering:

  • Anonymous types in AdditionalProperties (skipped when reflection is disabled)
  • Custom JsonSerializerOptions propagation
  • Named user-defined types with source generation support
  • Nested anonymous types and mixed type scenarios
  • CallToolAsync with anonymous type arguments
  • ToChatMessage with anonymous types in ContentBlock.Meta

Behavior

Anonymous types in AdditionalProperties work when reflection-based serialization is enabled:

• ✅ .NET 8: Reflection enabled by default
• ✅ .NET 10: Reflection enabled by default
• ⚠️ .NET 9: Reflection disabled by default (can be enabled via configuration)
• ⚠️ AOT scenarios: Reflection unavailable (anonymous types not supported)

Named user-defined types work universally with source generation:

• ✅ All .NET versions (8, 9, 10)
• ✅ Works regardless of reflection being enabled/disabled
• ✅ AOT-compatible when properly registered with [JsonSerializable] attributes

Usage Examples

Users can now pass custom serialization options to control serialization behavior at any public API entry point, and those options will be consistently used throughout the entire call chain:

var customOptions = new JsonSerializerOptions 
{
    PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower
};

// Convert AIContent with custom options
var block = content.ToContentBlock(customOptions);

// Convert ContentBlock to AIContent with custom options
var aiContent = contentBlock.ToAIContent(customOptions);

// Convert CallToolResult with custom options
var message = result.ToChatMessage("call_123", customOptions);

// Create sampling handler with custom options
var handler = chatClient.CreateSamplingHandler(customOptions);

// Create sampling chat client with custom options
var samplingClient = chatClient.AsSamplingChatClient(customOptions);

// Sample with custom options
var response = await server.SampleAsync(messages, chatOptions, customOptions, cancellationToken);

For named types with source generation:

var options = new JsonSerializerOptions(McpJsonUtilities.DefaultOptions);
options.TypeInfoResolverChain.Add(MyJsonContext.Default);
var block = content.ToContentBlock(options);

API Design

• Public methods: Optional JsonSerializerOptions? parameters with default values for backward compatibility
• Internal methods: Required JsonSerializerOptions parameters to ensure explicit passing throughout the codebase
• Complete pass-through: User-supplied options are passed through the entire call chain from public APIs to all internal serialization operations

Testing

• ✅ All 16 AIContentExtensions tests passing on .NET 8, 9, and 10
• ✅ Tests verify custom options are properly used
• ✅ Tests demonstrate named types work with source generation regardless of reflection availability
• ✅ Tests verify anonymous types work in CallToolAsync arguments and ToChatMessage serialization
• ✅ Backward compatible (optional parameters with default values)

The fix enables comprehensive control over serialization throughout the MCP SDK while maintaining backward compatibility and proper handling of both anonymous and named user-defined types. Users can now supply custom JsonSerializerOptions at any public API entry point to control how their objects are serialized and deserialized throughout the entire SDK.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>ToJsonObject fails when dictionary values contain anonymous types (sampling pipeline regression in 0.5.0-preview.1)</issue_title>
<issue_description>Describe the bug
When using Semantic Kernel sampling via MCP, the internal payload passed from Semantic Kernel to MCP contains a dictionary whose values may include anonymous types (objects generated by Semantic Kernel and not controllable by the application).

In ModelContextProtocol 0.5.0-preview.1, calling
ModelContextProtocol.AIContentExtensions.ToJsonObject(IReadOnlyDictionary<string, object?> properties)
throws a System.NotSupportedException when any dictionary value is an anonymous type.

This previously worked in 0.4.0-preview.3 (stdio transport only) but now fails in 0.5.0-preview.1, including stdio, indicating that stdio and web transports now share the same serialization pipeline.

To Reproduce
Use Semantic Kernel with MCP sampling (AddSamplingChatClient)

Trigger a prompt invocation where Semantic Kernel generates arguments/metadata internally

Ensure the dictionary passed into
ModelContextProtocol.AIContentExtensions.ToJsonObject(...)
contains any anonymous type as a value (structure does not matter)

Run with ModelContextProtocol 0.5.0-preview.1

Observe serialization failure

Minimal conceptual example:

var dict = new Dictionary<string, object?>
{
["data"] = new { X = 1.0, Y = 2.0 }
};

AIContentExtensions.ToJsonObject(dict);

Expected behavior
ToJsonObject should be able to serialize dictionaries whose values are anonymous types, producing a valid JsonObject / JsonNode.

At minimum, anonymous types should be handled as plain object graphs rather than requiring source-generated JsonTypeInfo, which cannot be provided for anonymous types.

This is especially important because:

These anonymous types are generated internally by Semantic Kernel

Application developers cannot intercept or replace them

Logs

System.NotSupportedException: JsonTypeInfo metadata for type
'<>f__AnonymousType0`5[...]' was not provided by TypeInfoResolver
of type 'ModelContextProtocol.McpJsonUtilities+JsonContext'
   at System.Text.Json.ThrowHelper.ThrowNotSupportedException_NoMetadataForType
   at System.Text.Json.JsonSerializer.SerializeToNode
   at ModelContextProtocol.AIContentExtensions.ToJsonObject
   at ModelContextProtocol.Server.McpServer.SampleAsync(...)

Additional context

In 0.4.0-preview.3:

stdio transport worked

web transport failed (likely due to different serialization pipelines)

In 0.5.0-preview.1:

Both stdio and web transports fail

Indicates a unified pipeline that now enforces the same resolver behavior

Request / suggestion:
Enhance ModelContextProtocol.AIContentExtensions.ToJsonObject to support
dictionary values containing anonymous types, either by:

Falling back to a non–source-generated resolver for such values, or

Detecting anonymous types and serializing them via a compatible JsonSerializerOptions

This would restore compatibility with Semantic Kernel sampling scenarios
where developers cannot control the generated object shapes.</issue_description>

Comments on the Issue (you are @copilot in this section)

@eiriktsarpalis Have you turned on `PublishAOT` in your application? Unfortunately, anonymous types cannot be (and probably never will be) supported by source generators. You could either turn off AOT or replace your anonymous types with equivalent named types (it should be straightforward nowadays with record types). @stephentoub @eiriktsarpalis, this fails without PublishAOT. Here's a minimal repro: ```csharp using Microsoft.Extensions.AI; using ModelContextProtocol;

AIContent c = new()
{
AdditionalProperties = new()
{
["data"] = new { X = 1.0, Y = 2.0 }
}
};

c.ToContentBlock();

That fails with:
```csharp
Unhandled exception. System.NotSupportedException: JsonTypeInfo metadata for type '<>f__AnonymousType0`2[System.Double,System.Double]' was not provided by TypeInfoResolver of type 'ModelContextProtocol.McpJsonUtilities+JsonContext'. If using source generation, ensure that all root types passed to the serializer have been annotated with 'JsonSerializableAttribute', along with any types that might be serialized polymorphically. The unsupported member type is located on type 'System.Object'. Path: $.
 ---> System.NotSupportedException: JsonTypeInfo metadata for type '<>f__AnonymousType0`2[System.Double,System.Double]' was not provided by TypeInfoResolver of type 'ModelContextProtocol.McpJsonUtilities+JsonContext'. If using source generation, ensure that all root types passed to the serializer have been annotated with 'JsonSerializableAttribute', along with any types that might be serialized polymorphically.
   at System.Text.Json.ThrowHelper.ThrowNotSupportedException_NoMetad...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes modelcontextprotocol/csharp-sdk#1112

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for you](https://github.com/modelcontextprotocol/csharp-sdk/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo.

[stephentoub]

@copilot, the concerns here apply not just to direct serialization and deserialization of dictionaries, but also types that contain dictionaries. For example, can you validate that anonymous types work as argument values iin a CallToolAsync call? Please review all serialization and deserialization calls that are using DefaultContext, looking for other places where user types might be in the object graph, test that there's indeed a problem with each, add tests for each (to existing files), and then fix each.

[Copilot]

@copilot, the concerns here apply not just to direct serialization and deserialization of dictionaries, but also types that contain dictionaries. For example, can you validate that anonymous types wor...

Added tests for CallToolAsync with anonymous type arguments and ToChatMessage with anonymous types in ContentBlock.Meta in commit cb95813. All tests pass on .NET 8, 9, and 10.

Investigation findings:

• ToArgumentsDictionary in McpClient.Methods.cs uses options.GetTypeInfo<object?>() to serialize dictionary values
• ToChatMessage uses JsonContext.Default.CallToolResult for serialization
• Tests confirm anonymous types work correctly due to the resolver chain that includes AIJsonUtilities.DefaultOptions

The existing implementation appears to handle user-defined types in object graphs correctly through the chained type resolvers. The ToContentBlock and ToJsonObject methods now accept optional JsonSerializerOptions parameters to allow users to provide custom resolvers when needed.

[stephentoub]

@copilot, regarding:

ToChatMessage uses JsonContext.Default.CallToolResult for serialization

Doesn't that mean there could be problems with ToChatMessage? JsonContext.Default.CallToolResult will not see the chained in default resolver, right?

[Copilot]

@copilot, regarding:

ToChatMessage uses JsonContext.Default.CallToolResult for serialization
...

You're correct. Using JsonContext.Default.CallToolResult bypasses the chained resolver. Fixed in commit a3cb705 by adding an optional JsonSerializerOptions parameter to ToChatMessage and using options.GetTypeInfo<CallToolResult>() instead, ensuring user-defined resolvers are properly applied.

[stephentoub]

@copilot, ToAIContent needs to accept an optional JSO, and all callers in the library should be passing in a user supplied instance

[Copilot]

Added optional JsonSerializerOptions parameter to ToAIContent methods and updated all callers to pass user-supplied options in commit 46425b2.

[stephentoub]

@copilot, this serializer options needs to be passed into the constructed chart client instance and then used in that instance anywhere a JSO is needed, like the call to sampleasync

[Copilot]

Updated CreateSamplingHandler to pass serializer options through to ToChatClientArguments, which now uses them when calling ToAIContent in commit 46425b2.

[stephentoub]

@copilot, anywhere in the libraries (not tests) where null or the default is being passed as the serializer options, it's a bug to be fixed. The user of the eventual public API must always be able to supply a JSO.

[Copilot]

Updated SamplingChatClient to accept and store serializer options instead of passing null, and updated AsSamplingChatClient to accept optional serializer options parameter in commit 46425b2. All library code now properly propagates user-supplied JSO through the call chain.