Skip to main content
Glama

Route & Logistics Optimizer

Route, Assignment & Load Planner

route_optimizer
Read-only

Plans who goes where, in what order, in which vehicle. From stops (lat/lng or a road distance matrix) and vehicles it returns each vehicle's ordered stops with arrival/leave times, km, load, Google Maps links and GeoJSON, respecting delivery time windows, capacity (weight and volume), shift times, max stops/km, skills, stops locked to a vehicle, open routes and mid-day re-planning. Also: savings vs the user's current plan, vs driver instinct and vs list order; stops that cannot be served with the reason; address sanity checks; optimal technician-to-job assignment (skills, jobs per person); and loading items into the fewest vehicles with the proven minimum. Benchmarked within ~1.3% of best-known on Solomon/Uchoa instances, optimal on TSPLIB tours tested. Decision cards first. Up to 300 stops; larger: route_optimizer_get_engine.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "route_optimizer"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobsNoAssignment: id, lat, lng, skills.
seedNo
depotNo{lat, lng} of the depot/warehouse, or its id in matrix_ids.
itemsNoLoad packing: id, weight (or qty), volume, count.
stopsNoOne row per stop: id, lat, lng (or an id in matrix_ids), demand, volume, service_minutes, window_start, window_end, skills, vehicle (lock), priority, status. No names/phones/addresses.
day_endNo20:00
workersNoAssignment: id, lat, lng, skills, max_jobs.
currencyNoINR
vehiclesNoid, capacity, volume_capacity, shift_start, shift_end, start_lat/lng (or current_lat/lng + now for mid-day), end_lat/lng, skills, max_stops, max_km, cost_per_km, cost_per_hour, fixed_cost, count. Default: one vehicle.
day_startNo08:00
objectiveNodistance
speed_kmhNo
time_unitNoauto
bin_volumeNo
iterationsNoImprovement rounds (default scales with stops; fixed rounds = repeatable).
matrix_idsNo
cost_per_kmNo
road_factorNo
time_matrixNoOptional road travel times (minutes), same shape as distance_matrix.
bin_capacityNoCapacity of identical loads.
cost_per_hourNo
distance_unitNokm
current_routesNoThe user's existing plan: [{vehicle, stops: [stop ids in order]}].
currency_symbolNo
distance_matrixNoOptional road distances (km) from a router; rows/cols follow matrix_ids.
include_geojsonNo
return_to_depotNo
assignment_costsNoOptional workers x jobs costs (matrix or [{worker, job, cost}]).
minimize_vehiclesNoUse as few vehicles as possible first (then shortest).
time_limit_secondsNo
default_service_minutesNo

Output Schema

NameRequiredDescriptionDefault
alertsNo
routesNo
statusYes1 = ok, 0 = nothing could be planned
geojsonNo
messageNo
summaryNo
metadataYes
decisionsYesPlain-language cards, priority order. Relay these first.
load_planNo
assignmentNo
comparisonNo
assumptionsNo
address_checksNo
unserved_stopsNo
data_quality_reportNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the readOnly/non-destructive annotations: enumerated outputs (ordered stops with arrival/leave times, km, load, Maps links, GeoJSON), "Decision cards first", infeasible-stop reporting with reasons, and comparison baselines against the user's current plan and driver instinct. It also discloses the hard 300-stop cap and cites solution-quality evidence. It does not cover determinism (seed/iterations repeatability) or runtime bounds, which matter for a 20s default time limit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: the one-line purpose comes before the dense capability inventory, and the 300-stop escalation is placed last where it belongs. However the middle is a single semicolon-chained block mixing routing, assignment and packing features, and the Solomon/Uchoa/TSPLIB benchmark sentence is self-promotion that costs space without changing invocation behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 31-parameter, multi-mode optimizer, the description covers the domain model (stops, vehicles, workers, items, matrices), the constraint set, the limits, and the escalation path; an output schema exists so return shape need not be spelled out. The remaining gap is mode selection — with zero required parameters, an agent gets no explicit signal about which parameter groups must be supplied together.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 42% across 31 parameters, and the description compensates for the routing-relevant ones (stops with lat/lng or matrix_ids, windows, skills, locks, capacity weight/volume, max_stops/max_km, shift times). It says nothing about seed, objective, speed_kmh, road_factor, time_unit, currency, distance_unit, time_limit_seconds or iterations beyond a passing mention, leaving a large share of the surface unexplained in either place.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete, vivid verb+resource statement ("Plans who goes where, in what order, in which vehicle") and then enumerates the three modes it covers: routing from stops/vehicles, worker-to-job assignment, and load packing. It explicitly names the sibling route_optimizer_get_engine for the >300-stop case, so an agent can separate the two without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a hard routing rule to the alternative tool ("Up to 300 stops; larger: route_optimizer_get_engine") and describes when re-planning mid-day applies via current_lat/lng + now in the vehicle vocabulary. It stops short of telling the agent which parameter combinations trigger which of the three modes, leaving that to be inferred from the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.