Reported in review on #1916.
`cuopt_solve_lp`/`cuopt_solve_milp` pick a settings schema (`pdlp_settings` vs `mip_settings`) based only on which tool was called, not on the parsed model. After `Read()`, the model's variable types are known — an `.lp` file with a `Generals`/`Binaries` section submitted via `cuopt_solve_lp` silently becomes an LP relaxation (integrality dropped) instead of failing loudly.
Suggestion: in `tools.submit`, after `_read_problem`, check the model's variable types against `kind`; if `kind == "pdlp_settings"` and any variable is integer/binary, raise a clear `CuOptMCPError` telling the caller to use `cuopt_solve_milp` instead (or at minimum return a warning field in the response).
Not done in #1916 to keep that PR's scope to the review items already raised.
Reported in review on #1916.
`cuopt_solve_lp`/`cuopt_solve_milp` pick a settings schema (`pdlp_settings` vs `mip_settings`) based only on which tool was called, not on the parsed model. After `Read()`, the model's variable types are known — an `.lp` file with a `Generals`/`Binaries` section submitted via `cuopt_solve_lp` silently becomes an LP relaxation (integrality dropped) instead of failing loudly.
Suggestion: in `tools.submit`, after `_read_problem`, check the model's variable types against `kind`; if `kind == "pdlp_settings"` and any variable is integer/binary, raise a clear `CuOptMCPError` telling the caller to use `cuopt_solve_milp` instead (or at minimum return a warning field in the response).
Not done in #1916 to keep that PR's scope to the review items already raised.