Skip to content

cuopt_mcp: add VRP/routing support #1939

Open

Description

@ramakrishnap-nv

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.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions