/gcbrun

Thanks for the PR @saurabhkoshatwar !

Could you please take a look at the integration test failure?

I'm also thinking if we could add any more integration/unit tests to verify this change. For instance to see if there could still be any validation failures while actually using hyphenated parameters?

/gcbrun

Thanks for the PR @saurabhkoshatwar !

Could you please take a look at the integration test failure?

I'm also thinking if we could add any more integration/unit tests to verify this change. For instance to see if there could still be any validation failures while actually using hyphenated parameters?

@saurabhkoshatwar Bumping this up in case it got missed :)

/gcbrun

@anubhav756 could you please rerun the tests? Thanks!

/gcbrun

/gcbrun

@anubhav756, please rerun /gcbrun

/gcbrun

@anubhav756, please rerun /gcbrun

@saurabhkoshatwar Done!

Hi @saurabhkoshatwar , @anubhav756 I was digging into this and I think we might have a validation order issue.

The current approach builds the Pydantic models with safe names (like user_id), but the actual tool invocation still passes the original hyphenated keys (like user-id). Since there’s no alias mapping, model_validate() is going to fail at runtime because it can’t find the underscored fields it’s looking for.

I tested this locally and it breaks as soon as you try to actually call the tool. I think it will be better if we use Pydantic's Field(alias=...) so the model knows how to map the original names to our safe identifiers.

Also, it would be good to add an E2E test case for this—the current unit tests only check that the model can be created, not that it actually validates hyphenated data during a real call.