Register List<object> JSON metadata for Native AOT array tool arguments

[girishkvs]

Fixes #1846

Problem

Providers that produce CLR List<object> tool arguments can fail under Native AOT because the default MCP serializer context lacks metadata for that type.

tryAGI/Ollama is a concrete producer: its MEAI adapter converts JSON arrays using .ToList(). The same reporter filed tryAGI/Ollama#215 for the same read_multiple_files scenario. This does not affect every array representation: JsonElement arguments already pass through without this conversion.

Change

Keep the List<object> registration in McpJsonUtilities.JsonContext and the direct populated/empty-list checks.

Add OllamaProviderArrayRegression to the existing AOT compatibility app. The real published Ollama 1.15.2-dev.5 SDK reads mock JSON/NDJSON responses and supplies the arguments through FunctionInvokingChatClient to the existing MCP Join(string[] items) tool. The test checks the provider-created type, unchanged argument reference and actual tool result; it does not manufacture the provider's list.

Validation

The current AOT compatibility app was published through MSBuild.exe using SDK 10.0.401, with /t:Publish, /p:RuntimeIdentifier=win-x64 and /p:SelfContained=true, then its native executable was run. SourceLink matches main at 10.0.401; NuGet audits remain enabled.

Source / configuration	Result
Earlier negative control, SDK 10.0.303: registration removed; unchanged provider test	Reported List<object> missing-metadata exception through the provider/FICC/MCP path
Current registration present; Release	Four provider cases and all existing AOT assertions pass
Current registration present; Debug	The same four provider cases and existing assertions pass

The cases cover streaming/non-streaming and populated/empty arrays. Each also checks the existing JsonElement path. MCP Core builds for netstandard2.0, net8.0, net9.0 and net10.0; git diff --check passes.

No live provider calls or model downloads are needed. The regression stops after the MCP tool invocation; it does not claim to fix the provider's separate tool-result serialization behavior. Other OS native builds and the full repository test suite were not run locally.

[halter73]

Do we know which MEAI provider produces List<object> here? FunctionInvokingChatClient forwards the provider's arguments unchanged, and MEAI's OpenAI adapter parses JSON arrays as JsonElement, which we already handle. This test constructs List<object> directly, so it doesn't establish that this is a general MEAI array gap. Could we identify the provider and cover its path?

[girishkvs]

Found tryAGI/Ollama: ConvertJsonValue in OllamaClient.ChatClient.cs uses .ToList() for JSON arrays. The same reporter filed tryAGI/Ollama#215 for read_multiple_files. Added real-provider AOT coverage through FunctionInvokingChatClient and MCP; removing the registration fails the new test, and Release/Debug pass with it.

— girishkvs's Copilot 🤖