cuopt_mcp (#1916) currently exposes LP and MILP solving only (cuopt_solve_lp/cuopt_solve_milp), backed by cuopt.grpc.client.grpc_client.Client. Routing/VRP isn't wired in.
Why this is bigger than adding another tool
LP/MILP submission is file-based — problem_path works because MPS/LP are standard formats Read() parses directly. VRP has no file-format equivalent: a routing problem is built programmatically via DataModel calls (fleet size, cost matrix or coordinates, demand, capacity, time windows, breaks, etc.). A cuopt_solve_vrp tool needs a structured JSON input schema covering that construction surface instead of a problem_path string — real design work, not just plumbing.
What's already reusable
RoutingClient (merged into the same cuopt.grpc.client.grpc_client extension module as Client) has a near-identical shape — submit/status/wait/cancel/result/delete — so the tool-calling pattern this PR established (async submit, _guard-shaped errors, generated settings catalogue) should carry over cleanly once the input schema exists.
Gaps to close
- Design a JSON Schema for VRP problem construction (fleet, tasks, time windows, matrices, etc.) to replace
problem_path.
cpp/src/grpc/codegen/field_registry.yaml only has pdlp_settings/mip_settings — no routing settings section, so cuopt_list_settings-style generated discovery doesn't cover routing yet. Extending codegen to routing settings (or hand-writing a schema, which the existing settings catalogue deliberately avoids) is its own piece of work.- New tools:
cuopt_solve_vrp, plus routing-appropriate cuopt_result shaping (route sequences/vehicle assignments look nothing like an LP variable vector).
Scoped as a follow-up to #1916, not part of it.
cuopt_mcp(#1916) currently exposes LP and MILP solving only (cuopt_solve_lp/cuopt_solve_milp), backed bycuopt.grpc.client.grpc_client.Client. Routing/VRP isn't wired in.Why this is bigger than adding another tool
LP/MILP submission is file-based —
problem_pathworks because MPS/LP are standard formatsRead()parses directly. VRP has no file-format equivalent: a routing problem is built programmatically viaDataModelcalls (fleet size, cost matrix or coordinates, demand, capacity, time windows, breaks, etc.). Acuopt_solve_vrptool needs a structured JSON input schema covering that construction surface instead of aproblem_pathstring — real design work, not just plumbing.What's already reusable
RoutingClient(merged into the samecuopt.grpc.client.grpc_clientextension module asClient) has a near-identical shape —submit/status/wait/cancel/result/delete— so the tool-calling pattern this PR established (async submit,_guard-shaped errors, generated settings catalogue) should carry over cleanly once the input schema exists.Gaps to close
problem_path.cpp/src/grpc/codegen/field_registry.yamlonly haspdlp_settings/mip_settings— no routing settings section, socuopt_list_settings-style generated discovery doesn't cover routing yet. Extending codegen to routing settings (or hand-writing a schema, which the existing settings catalogue deliberately avoids) is its own piece of work.cuopt_solve_vrp, plus routing-appropriatecuopt_resultshaping (route sequences/vehicle assignments look nothing like an LP variable vector).Scoped as a follow-up to #1916, not part of it.