Hello all! Just wondering if the following could be implemented, introducing a validator in the ToolParam interface.


@Target({ ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ToolParam {

    /**
     * Whether the tool argument is required.
     */
    boolean required() default true;

    /**
     * The description of the tool argument.
     */
    String description() default "";

    /**
     * The validator that should be called upon Tool invocation.
     */
    ContraintValidator validator();

}

Thanks for your awesome job!

Comment From: sunyuhan1998

Hi @jirou97 Can you expand on this a bit more? What scenarios would you like to realize with this validator? What exactly does it "validate" during a tool call?

Comment From: jirou97

Basically my thoughts are moving away validation logic from the actual tool implementation. Example. 


@Tool(...)
public String updateUserPasswordTool(@ToolParam(description = "The user's id", validator = UserIdValidator.class) {

// Implement actual tool here

}

Where UserIdValidator, would ensure the provided userId has the correct form based on business needs (eg. not blank, numeric etc).

Do you think this could provide cleaner tool implementations with a better seperation of concerns?

Comment From: sunyuhan1998

Do you think this could provide cleaner tool implementations with a better seperation of concerns?

I think I understand what you mean. Besides decoupling parameter validation from tool implementation at the code level, what other improvements can we achieve in terms of user experience and functionality? For instance, could we design a mechanism for validators to provide user-friendly prompts (defined by developers within the validator) when the input parameters have incorrect format or type? For example: "The user ID you provided seems incorrect—could you please double-check it?"

Comment From: jirou97

Yes, this is exactly what I mean!