Tool validation errors echo the rejected input value (input_value) — add a masking option or a public validation-error hook

[panandr]

What happens

When a tool call's arguments fail pydantic validation, Tool.run wraps the ValidationError into a ToolError whose message includes the pydantic rendering — and str(ValidationError) carries the offending value:

Error executing tool <name>: 1 validation error for <model>
<field>
  Input should be a valid string [type=string_type, input_value=12345, input_type=int]

That message is sent to the client as an isError result, so the rejected value is echoed back to the caller (and into the model's context).

Why it matters

Servers that handle sensitive input (PII/PHI, credentials, member identifiers) must not let a validation failure repeat the value; the error should describe the rule, not the data. We hit this building a healthcare-platform MCP server whose tool inputs can be PHI.

Workaround we use today (reaches private API)

We replace the SDK-generated arguments model with a subclass that raises MCPError(-32602, "<field>: <rule>") instead of the default ToolError:

tool = server._tool_manager.add_tool(fn, ...)
tool.fn_metadata.arg_model = PhiSafeArgModel(tool.fn_metadata.arg_model)

This depends on _tool_manager and fn_metadata.arg_model (both private) and on validation continuing to flow through model_validate, so it is fragile across minor releases.

Asks (any one would remove the private-API dependency)

1. An opt-in setting to omit input values from tool validation errors (e.g. a mask_error_details-style flag), or
2. A public/supported hook to customize argument-validation failures (or documenting arg_model as an extensible point), or
3. Excluding input_value from the argument-validation error text by default.

Version: mcp 2.2.0 (Python). Happy to open a PR if you can point at the preferred shape.

[sattyamjjain]

+1 for option 3 (drop input_value by default), with option 2 as the escape hatch.

Pydantic already has both switches, so the change may be small:

• e.errors(include_input=False) returns the error list without the rejected values, so the ToolError message can be built from that instead of str(e)
• or create the generated arg model with ConfigDict(hide_input_in_errors=True), then str(e) prints [type=string_type] without input_value=...

Checked both on pydantic 2.13.5.

It is worth checking the other validation paths too (structured output validation, resource template params). They probably format the error the same way.

While looking at this, I found the same leak in the validation-error path of my own guard library, so this pattern is easy to miss.