[mcp-core] Clarify tool input validation error message. Fixes #986

[HarshMehta112]

Tool input validation reused the JSON schema validator's output-oriented error message, producing misleading errors that referenced structuredContent and outputSchema even when the failure was about a
tool's input arguments. This makes the input validation message clearly refer to input.

Motivation and Context

Tool input validation (added in #873) reuses JsonSchemaValidator.validate(schema, content), whose error message is hardcoded for output validation. On invalid input, consumers/LLMs received:

Validation failed: structuredContent does not match tool outputSchema. Validation errors: [: required property 'age' not found]

This is misleading — the failure is about input arguments, not output. Fixes #986.

The fix adds a context-aware overload validate(schema, content, dataDescription) (a default method delegating to the existing 2-arg method, so it's backward compatible for custom validator
implementations). Input validation now passes an input-specific description, producing:

Validation failed: input arguments do not match tool inputSchema. Validation errors: [: required property 'age' not found]

Output validation continues to use the 2-arg method and is unchanged.

• ToolInputValidationIntegrationTests (sync + async, Tomcat streamable HTTP): asserts the error message references input (inputSchema) and does not contain outputSchema / structuredContent.
  Previously only checked a single substring (age / minimum).
• ToolInputValidatorTests: verifies the input-specific description is passed to the validator.
• DefaultJsonSchemaValidatorTests (jackson2 + jackson3): added coverage for the new 3-arg overload; existing 2-arg output-message tests left unchanged.
• All affected modules build clean and pass spring-javaformat:validate.

Breaking Changes

None. The new interface method is a default that delegates to the existing method, so custom JsonSchemaValidator implementations require no changes. Output validation behavior and messages are unchanged.

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

The validator already carries tool-specific wording (tool outputSchema), so adding a symmetric input-aware path is consistent with the existing design. An alternative — making the validator's message fully
generic and having callers prepend context — was rejected because it would also change the output message, widening scope beyond this issue.