GH-5803: Apply @Schema constraint attributes to @Tool method parameters

[suryateja-g13]

Thank you for taking time to contribute this pull request!

Problem

JsonSchemaGenerator.generateForMethodInput() manually reads @Schema on method parameters for description and requiredMode, but silently drops all constraint attributes:

• minimum / maximum
• exclusiveMinimum / exclusiveMaximum
• minLength / maxLength
• pattern
• example
• allowableValues (mapped to enum)
• multipleOf

For example, this tool parameter produces no minimum/maximum in the generated schema:

@Tool(name = "set_chance", description = "Set the chance value")
public String setChance(
    @Schema(description = "Chance percentage", minimum = "0", maximum = "100")
    int chance
) { ... }

Solution

Add a private applySchemaConstraints(Parameter, ObjectNode) method that reads the @Schema annotation on a method parameter and applies its constraint attributes to the generated ObjectNode. This is called once per parameter in the existing generateForMethodInput loop, after the base schema and description have been set.

Numeric constraints (minimum, maximum, multipleOf) are parsed via a helper tryParseDouble() that silently skips non-numeric values to match the lenient nature of the Swagger @Schema annotation.

Changes

• JsonSchemaGenerator.java — added applySchemaConstraints() + tryParseDouble() helpers; called from the parameter loop in generateForMethodInput()
• JsonSchemaGeneratorTests.java — added generateSchemaForMethodWithOpenApiSchemaConstraints test covering minimum/maximum, minLength/maxLength/pattern, and allowableValues; added schemaConstraintsMethod to TestMethods

Checklist

• Added Signed-off-by line to commit (DCO)
• Rebased on latest main
• Unit tests added
• Build passes (mvn package -pl spring-ai-model)

Fixes #5803

[anuragg-saxenaa]

LGTM — well-structured implementation. The applySchemaConstraints method is clean, handles all relevant @Schema constraint attributes (minLength, maxLength, pattern, example, allowableValues, etc.), and tryParseDouble handles edge cases gracefully. The test coverage looks solid. This aligns with coding-factory param validation patterns. 🚢

[anuragg-saxenaa]

LGTM. Clean, well-scoped fix. The new applySchemaConstraints() helper correctly handles all constraint types (minimum/maximum/exclusiveMinimum/exclusiveMaximum, minLength/maxLength, pattern, example, allowableValues/enum, multipleOf) and is called at the right point in the existing parameter loop. tryParseDouble() for numeric fields is the right approach — lenient parsing avoids breaking on non-numeric values in the annotation. Test covers all new constraint types and uses the standard TestMethods pattern. No risk to existing behavior since constraints are additive-only. Ship it.

[redinside-dev]

LGTM. Clean fix that adds applySchemaConstraints() + tryParseDouble() helpers to bridge the gap between @Schema annotation constraint attributes and the generated JSON schema. The test coverage is solid - minimum/maximum, minLength/maxLength/pattern, and allowableValues/enum all verified. Two small notes for future improvement: (1) could extract the allowableValues/enum logic into a dedicated method since it builds an array, and (2) @Schema(allowableValues) currently only handles String enums - if someone passes e.g. allowableValues = {"1", "2"} for an int parameter, it will generate String enum values instead of integers, which could be confusing. Neither is a blocker for merging.

Testing: build passes (mvn package -pl spring-ai-model). Ship it.