Exception raised when a nullable parameter is sent as an empty string in the Http request

[aschabus]

I have an MCP server that uses nullable types for its parameters. For example:

[McpServerTool(Name = "get_data"), Description("Get data from the store")]
public async Task<IEnumerable<ResponseType>> GetData(
   [Description("Number of records to return")] int? limit = null,
   [Description("Start date")] DateTime? from = null,

When I use streamable HTTP (for example, via MCP Inspector), the data is sent as an empty string, like this:

"arguments":{ "limit": null, "from":"2025-01-01"}

When I compile this with ModelContextProtocol and ModelContextProtocol.AspNetCore version "0.1.0-preview.12", everything works as expected. However, if I use version "0.2.0-preview.3", I get the following Exception:

System.Text.Json.JsonException: The JSON value could not be converted to System.Nullable`1[System.DateTime]

How can I get this working?

[aschabus]

I also tested it with version "0.3.0-preview.1" and it fails as well.

[aschabus]

There is one more thing which seems to be related.
When the tools/list method is executed on the server, the server sends back default(T) for T?, even if the default value for the parameter is set to null for the parameter. In "0.1.0-preview.12", this works as expected.

[eiriktsarpalis]

I can't reproduce the issue from the inspector, however I noticed that we're producing invalid JSON schemas for Nullable<T> parameters which might be relevant to this issue. I filed dotnet/extensions#6596 to address this in the MEAI layer.

[sarahecraddock]

Hi @eiriktsarpalis, I'm going to be taking over this issue from my teammate @aschabus (as he's on vacation for a couple of weeks). I just wanted to confirm that I've pulled down the changes in your PR and tested with out code and I'm still seeing the same unexpected behaviour, so this doesn't seem to resolve the issue.

I've created a repro setup by making a couple of small tweaks to one of your samples in this repo (on a fork here). All the behaviour I'm going to mention I am repro-ing by running the sample (with my changes) and then spinning up MCP inspector to interact with the sample MCP server. I am seeing:

• With a nullable parameter is defined in the tools file with no default value, when I hit /list/tools I'm seeing no default value returned but the parameter appears as required.
• With a nullable parameter is defined in the tools file with a default null value, when I hit /list/tools I'm seeing the parameter correctly marked as not required but a default value returned from /list/tools and if I remove this default value and make it null then I can see an error in the logs which appears to be around it not liking that a null value has been provided.

Are you able to repro the behaviour with this sample?

[eiriktsarpalis]

With a nullable parameter is defined in the tools file with no default value, when I hit /list/tools I'm seeing no default value returned but the parameter appears as required.

This is by design. Whether a parameter is nullable is independent of whether it is optional (aka specifying a default value). You can have nullable parameters that are required or non-nullable parameters that are optional. See this article for more details.

if I remove this default value and make it null then I can see an error in the logs which appears to be around it not liking that a null value has been provided.

This is caused by the aforementioned bug that dotnet/extensions#6596 is fixing. Because the generated schemas for Nullable<T> parameters is being incorrectly advertised as non-nullable, the inspector interprets null inputs as "null" JSON strings resulting in the server (correctly) rejecting those inputs. You can verify that this is the case by changing your tool parameters from DateTime? (a struct) into string? (a reference type).

[sarahecraddock]

Is /list/tools returning a default (non-null) value when the default is explicitly configured as null in the tools file expected behaviour? We weren't seeing this behaviour with the previous version of the package, but are with the current version.

[eiriktsarpalis]

Is /list/tools returning a default (non-null) value when the default is explicitly configured as null in the tools file expected behaviour?

No, this is part of the issue that is being fixed by dotnet/extensions#6596. A nullable parameter without a default value should be required and not emit a default value in the schema.

We weren't seeing this behaviour with the previous version of the package, but are with the current version.

Which version specifically? I find that surprising since the fixed issue existed since the release of MEAI. Perhaps there existed other confounding factors that made it work, sharing a minimal repro targeting the previous version would help me diagnose.

[sarahecraddock]

Version 0.1.0-preview.12

[sarahecraddock]

I've pushed the downgraded versions change to another branch of the same repro I mentioned earlier in my fork here, so you can see that the default values were being passed as null with the older MCP package versions.

And when I bump the MCP package versions to latest with that same setup, and bump the Microsoft.Extensions.AI and Microsoft.Extensions.AI.Abstractions versions to a local build of the branch that you currently have PR-ed, I can still see default values being passed (even though the default should be null), unlike with the older versions of the MCP package.

[eiriktsarpalis]

I can confirm that default parameter handling works with 0.1.0-preview.12. This is because it references an older version of MEAI (9.4.3-preview.1.25230.7) which handled default values differently. Note that even with that earlier version the schema for nullable types was still being represented as non-nullable. All issues should be addressed once MCP incorporates the fix in dotnet/extensions#6596.