feat: allow users to add constraints and validators to ToolParam

[bcallender]

TL;DR

Added parameter constraints and validators to tool parameters to enable better validation of user inputs.

What changed?

• Added NumericConstraint and ToolParameterConstraints message types to the protocol buffer definitions
• Added constraints field to ToolParameter message to support numeric bounds (gt, ge, lt, le), multiple_of, min/max length, and regex pattern validation
• Added validator_names field to ToolParameter to support custom validators
• Implemented a validator registry system with a ParamValidator protocol
• Added a RegexValidator implementation with comprehensive regex validation
• Updated serialization/deserialization to handle the new constraint fields
• Modified the Pydantic model generation to apply constraints and validators
• Updated the MCP demo setup to use regex validators for query parameters

How to test?

1. Create a tool with parameter constraints:

tool = ToolParam(
    name="min_age",
    description="Filter `users` by minimum age.",
    constraints=ToolParamConstraints(gt=0, lt=120)
)

1. Create a tool with a regex validator:

tool = ToolParam(
    name="search_query",
    description="Regex pattern for querying user profile information",
    validator_names=["regex"]
)

1. Verify that invalid inputs are rejected with appropriate error messages when using the tool.

Why make this change?

This change enhances the tool parameter system by adding robust validation capabilities. By supporting both declarative constraints (like min/max values, length limits) and custom validators, we can ensure that user inputs meet specific requirements before executing tool functions. This improves error handling, security, and user experience by providing immediate feedback on invalid inputs rather than failing during execution.

[bcallender]

• feat: allow users to add constraints and validators to ToolParam #222 👈 (View in Graphite)
• feat: automated tool creation #163
• feat: declarative tool creation #150 : 1 other dependent PR (#153 )
• refactor: add .exprs() function to each LogicalPlan to get its referenced LogicalExprs #168
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[YoungVor]

Looks good! Had a few questions and nits

[YoungVor]

is it right to simply strip this? Wouldn't that change the behavior of what your matching silently?

[YoungVor]

According to opus, you can also have 'named' backrefs that you aren't catching in the backreference check, but the exotic construct check might catch it

[YoungVor]

TIL about ReDoS :D

Opus mentions overlapping alternation as another form of ReDoS, but its not possible to catch every case. For e.g.: "(a|ab)+"

Is there a timeout for the regex validator?

[YoungVor]

nit: _infer_param_base_type, or similar

[YoungVor]

I vaguely remember there being some reason for this - but 'optional' is a different concept than 'default'.. why not allow an optional param without a default?

[YoungVor]

Opus recommended a few more tests:

@pytest.mark.parametrize(
    "pattern,expected_error_substring",
    [
        # Empty/whitespace
        ("   ", "empty"),
        
        # Too long
        ("a" * 300, "too long"),
        
        # Unbalanced brackets
        ("(", "parentheses"),
        (")", "parentheses"),
        ("[a-", "bracket"),
        ("]", "bracket"),
        ("a{1,2", "brace"),
        ("a}", "brace"),
        
        # Quantifier issues
        ("a{99999}", "Quantifier"),
        ("a{5,2}", "upper bound"),
        ("a{1,2,3}", "syntax"),
        
        # Alternation limit
        ("a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z|aa", "alternation"),
        
        # Backreferences
        (r"\1", "backreference"),
        (r"\5", "backreference"),
        (r"\9", "backreference"),
        
        # Unsupported constructs
        (r"(?<=a)b", "construct"),
        (r"(?<!a)b", "construct"),
        (r"(?=a)", "construct"),
        (r"(?!a)", "construct"),
        
        # ReDoS patterns
        (r"(.+)+", "Nested"),
        (r"(.*)+", "Nested"),
        (r".*.*", "greedy"),
        (r".+.+", "greedy"),
        (r"(.*){3}", "Nested"),
        (r"(.+){2,5}", "Nested"),
        (r"(?:.*){2}", "Nested"),
        (r"(?:.+){3}", "Nested"),
        
        # Invalid regex syntax
        ("[z-a]", ""),  # py_validate_regex catches
        ("*abc", ""),   # py_validate_regex catches
    ],
)```

[YoungVor]

nit: good to include test to catch gt 120