Handle nullable arrays in tool inputSchemas

[cliffhall]

• In DynamicJsonForm.tsx

  • In debouncedUpdateParent, formatJson, and validateJson,
    • when trimming the JSON value, use ?.trim() in case the field is null

• In jsonUtils.ts

  • in tryParseJson
    • use ?.trim() in case the field is null

• In schemaUtils.ts

  • in normalizeUnionType
    • add condition to handle the case where there is an anyOf with array or null as options

• In ToolsTab.tsx

  • for nullable fields, in null checkbox, in onCheckedChange handler
    • when not checked, if prop type is array, set field value to undefined (empty input field that can be edited rather than the word "null" as the default could provide)

Fixes #846

Motivation and Context

We recently merged a PR that added support for nullable fields, but the case of nullable arrays was not handled. This PR adds builds on that work.

In issue #846, we can see that when a tool's inputSchema has a nullable array field like this:

We respond like this:

How Has This Been Tested?

Nullable Array tool parameter

Added a nullable array field with default of null to the mcp-maintainer-toolkit project, which is based on the everything reference server but easier for adding weird testing scenarios. This duplicates the problematic structure reported in the #846. We're using number instead of integer, but this PR supports nullable arrays of any primitive type, so integer, string, or boolean would also work.

Invoke tool with null checkbox checked

Since this tool param has a default of null, the null checkbox starts out checked. Just hitting the submit button sends a null for the field.

Invoke the tool with null checkbox unchecked but empty field

Unchecking the null checkbox and submitting an empty field, causes the field not to be sent, but on the server, since it has a default of null, the server parses the missing field as containing a null value, also as expected.

Invoke tool with an actual array

Unchecking the null checkbox and entering an array of numbers, we can see it operates as expected.

Breaking Changes

Nope.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context