Cross-SDK consistency: hardcoded internal key "is_override"

This line uses the string "is_override" directly, but that key is declared as internal const string OverridesBuiltInToolKey = "is_override" in CopilotTool.cs — it isn't part of the public API surface.

Every other SDK exposes this intent through a typed, discoverable API:

• Node.js: overridesBuiltInTool: true (option in defineTool)
• Python: overrides_built_in_tool=True (kwarg in @define_tool)
• Go: grepTool.OverridesBuiltInTool = true (struct field)
• Java: ToolDefinition.createOverride(...) (factory method)
• Rust: .with_overrides_built_in_tool(true) (builder method)

Two options to bring .NET into alignment:

Option A — Use CopilotTool.DefineTool (the idiomatic .NET helper):

CopilotTool.DefineTool(
    CustomGrep,
    new CopilotToolOptions { OverridesBuiltInTool = true },
    new AIFunctionFactoryOptions { Name = "grep", Description = "Custom grep override" }),

This keeps the AIFunctionArguments-based parameter access (the "low-level" part of the test) while using the typed override flag.

Option B — Make OverridesBuiltInToolKey public so callers who intentionally use raw AIFunctionFactory.Create can reference a typed constant instead of a magic string:

["is_override"] = true,  // ← becomes: [CopilotTool.OverridesBuiltInToolKey] = true

Option A is preferred for consistency, since it still demonstrates the low-level AIFunctionArguments pattern without leaking an internal key.

Cross-SDK consistency note: This hardcodes the raw "is_override" string, which is the internal value of CopilotTool.OverridesBuiltInToolKey (currently internal const). In all other SDKs the low-level override path uses a named, public API element:

For .NET, callers doing the raw approach must know the magic string "is_override". Consider making CopilotTool.OverridesBuiltInToolKey public so this test (and any other low-level callers) can write:

[CopilotTool.OverridesBuiltInToolKey] = true,

instead of relying on the private string value. Alternatively, the test could use CopilotTool.DefineTool() with CopilotToolOptions { OverridesBuiltInTool = true } for the override tool — even in a "low-level" test, the other two tools still demonstrate the raw AIFunctionArguments path.

Minor null-safety concern: content() returns String and can be null if the field is absent in the JSON response. Calling .toLowerCase() directly on it would throw a NullPointerException.

All other SDK tests guard against this:

• Node.js: const content = assistantMessage?.data.content ?? "";
• Python: content = assistant_message.data.content or ""
• Go: explicitly checks if content == "" { t.Fatalf(...) }
• Rust: uses a helper assistant_message_content() that handles null

Suggest:

String content = response.getData().content();
assertNotNull(content, "Expected non-null content in assistant response");
assertFalse(content.isEmpty(), "Expected non-empty content");
assertTrue(content.toLowerCase().contains("analyzing"), ...);

Cross-SDK consistency note — .NET "low-level" override key discoverability

The magic string "is_override" here is intentionally testing the low-level AIFunctionFactory.Create path, and that's correct. However, CopilotTool.OverridesBuiltInToolKey (which equals "is_override") is declared internal, so any .NET consumer who wants to use AIFunctionFactory.Create directly (instead of CopilotTool.DefineTool) has no discoverable public constant to reference.

The equivalent APIs in every other SDK are public and discoverable:

• Node.js: overridesBuiltInTool: true property on defineTool
• Python: overrides_built_in_tool=True parameter on @define_tool
• Go: grepTool.OverridesBuiltInTool = true public struct field
• Java: ToolDefinition.createOverride() public factory method
• Rust: .with_overrides_built_in_tool(true) public builder method

Suggestion: consider either (a) making OverridesBuiltInToolKey a public const to allow consumers to reference it without hardcoding the string, or (b) adding a comment here pointing to CopilotTool.DefineTool with new CopilotToolOptions { OverridesBuiltInTool = true } as the idiomatic alternative when AIFunctionFactory.Create isn't required.

Cross-SDK consistency note: All other SDKs expose overridesBuiltInTool as a typed, public API in their low-level tool definition (e.g., Java's ToolDefinition.createOverride(), Go's grepTool.OverridesBuiltInTool = true, Node.js's overridesBuiltInTool: true, Python's overrides_built_in_tool=True, Rust's .with_overrides_built_in_tool(true)). Here the .NET test sets "is_override" via a raw AdditionalProperties dictionary key, which is an internal SDK constant (CopilotTool.OverridesBuiltInToolKey).

Using CopilotTool.DefineTool() with CopilotToolOptions { OverridesBuiltInTool = true } would be the equivalent public SDK API and would align better with how other languages expose this feature:

CopilotTool.DefineTool(CustomGrep, new CopilotToolOptions
{
    OverridesBuiltInTool = true,
}, new AIFunctionFactoryOptions
{
    Name = "grep",
    Description = "Custom grep override",
}),

This is especially relevant since "is_override" is internal const — SDK users reading this test as documentation would copy a magic string that's not part of the documented public surface.