Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#3,572 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend-api-design, security

Research direction

Look at the Tool.run method and how it wraps pydantic ValidationError into ToolError. The error message is built from str(ValidationError). Find where tool validation happens, likely in the tool manager or argument model. The goal is to add a masking option or a hook to customize the error message without leaking input_value. Check existing server configuration for similar flags. A successful change will produce a validation error that describes the rule but not the sensitive data.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Python
Stars
24.3k
Forks
4k
Avg merge
1d 16h
Merged PRs (30d)
25

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/python-sdk

All issues in modelcontextprotocol/python-sdk

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.