Dotnet implementation silently drop parameters not used by tool during tool execution

[softnado]

Describe the bug
Assume there is one tool called Respond_To_Task (Guid taskId, String update, Boolean markComplete = false), in current implementation, if AI decided to call Respond_To_Task(taskId = guidA, update = "Done", phase = "completed"), the call will succeed but the markComplete passed to tool backend is false. Both AI and Backend will not able to detect such gap until someone outside of the system checking the behavior issue.

To Reproduce
Steps to reproduce the behavior:

1. Define some mcp client with such tool definition, and test it with the instructed call pattern, it will succeed.

Expected behavior
Error out or warning out when there is parameters mismatch instead of silently drop or ignore.

Logs
If applicable, add logs to help explain your problem.

Additional context
Add any other context about the problem here.

[stephentoub]

I'm unclear as to what the concern is. You specified a default value for markComplete, stating that it's optional for the AI to provide a value for.

If you want markComplete to be required, don't specify a default value.

[softnado]

The concern here is that there is no signal indicate this happened and both end believe the intended operation been executed correctly while what actually been executed is not what should happen. Understand this can be tool implementation practice change but it is not obvious such behavior is what been implemented today.

[stephentoub]

I don't understand. Your "expected behavior" was to error out or warning; if that's the behavior you want, just don't add the default value. The property in the tool schema is either required or optional, and if you specify optional (which is what you get with a default value), you're explicitly telling the model it's fine to not provide... it is not erroneous or warning-worthy.

It's no different in this regard from calling a method in C# with an optional parameter that has a default value: if the caller doesn't specify one, the callee gets the default value. It's not an error or a warning.

[softnado]

Agree adjust the tool implementation pattern can get the expected behavior as suggested. The risk is that when put the parameter as is, tool developer not aware of ["default implementation" will silently drop the not used parameter without warning or failure], to get reminded that "Shouldn't use parameter with default" because model may pass something different intended for that parameter but with wrong name, then execution succeed but result is wrong. Maybe the attribute can allow customization of the parameters mapping. Or the document of MCP dotnet sdk can call out this specifically.

[jeffhandley]

@mikekistler, @halter73, and I were chatting with @softnado offline about this and thought it would be valuable to assess the behavior across the SDKs.

Unmatched Tool Arguments: Cross-SDK Behavior Report (MCP SDKs)

Key Takeaways

1. Only 2 of 7 implementations reject unmatched arguments: The Go SDK and FastMCP. Both do so by generating schemas with additionalProperties: false and validating at runtime.

2. The Rust SDK is a notable near-miss: It generates schemas with additionalProperties: false but does not validate against them at runtime — serde silently drops unknown fields.

3. The Java SDK is unique in passing through: Unlike other SDKs that silently drop extra arguments, the Java SDK preserves them in the arguments map passed to the handler. The handler could theoretically detect and act on them, but the SDK provides no signal.

4. The Go SDK's opt-out is per-tool only: There is no global configuration to disable strict validation. Users must either supply a custom InputSchema per tool or use the raw Server.AddTool API.

5. 5 of 7 implementations silently ignore/pass through: C#, TypeScript, Python, Java, and Rust all allow unrecognized arguments without any signal — each using their language's default deserialization behavior.

Relevant Specification Work

• modelcontextprotocol/modelcontextprotocol#1898 — Open issue about additionalProperties: false on protocol types. Comment from @sirkirby (2026-04-08) explicitly raises the tool argument case and notes it has security implications. Comment from @pja-ant argues servers should not break on unknown fields for inter-version compatibility. This is the most active spec-level discussion about this topic.
• SEP-1303 (accepted) — Established that input validation errors should be tool execution errors (isError: true), which is relevant to how rejections should be communicated even if the spec doesn't yet mandate that they happen.