Skip to main content
Glama

Optimize routes

optimize_routes
DestructiveIdempotent

Plan delivery routes (vehicle routing problem, VRP): assign stops to vehicles and sequence each route from one depot, minimizing distance within max stops per vehicle, weight (kg), volume (m3) and time windows; dozens to thousands of stops. Send exactly one source of stops: plan_id, a saved plan (list_plans, get_import_result); dataset_id, an import; or stops, only for stops whose latitude and longitude are in this conversation (files, lists and addresses go through import_deliveries first). depot: depot_id from list_fleet, latitude/longitude, or an address (tell the user the depot_resolved match). A plan_id or dataset_id run is saved in that plan; stops save a new plan on every call (plan_name). A run spends one monthly stop per stop. Within 24 h of a plan's charged run, the same plan with the same stops or fewer (id and coordinates) is another try: no stops charged, plan limits still apply (Spanish 'otro intento'; never call it free); next_optimize_charged and charged_because say which applies. To vary a stops run (vehicles, max_stops), rerun its plan_id: sending the stops again charges again. Every call runs and charges, so first tell the user the stops it charges and those left, the vehicles and the constraints, get a yes, then call once. Arrival times need route_start_time. exclude_stop_ids leaves stops of a plan or dataset out for this run only. Identical arguments are deduplicated; a request over the account plan, or needing a constraint it lacks, is rejected and never partially applied. Tell the user when plan_replaced or plan_temporary is set. Returns optimization_id, with the result when it finishes within seconds; poll get_optimization_result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoDelivery date YYYY-MM-DD in time_zone. Default: today.
depotYesWhere every route starts: a saved depot, coordinates, or an address the server geocodes.
stopsNoStops whose coordinates are in this conversation. Every call saves a new plan.
plan_idNoA saved plan (list_plans, get_import_result). The run is saved in that plan.
vehiclesYesFleet for this run (1-50 vehicle types).
plan_nameNoWith stops: name of the new plan. Default: Optimization YYYY-MM-DD.
time_zoneNoIANA time zone for date and times, e.g. America/New_York.UTC
dataset_idNoAn import's stops (get_import_result, list_datasets), run in the plan it loaded into.
depot_nameNoDepot name shown in the plan.
use_volumeNoOptimize by volume. Omit to follow the vehicles' max_volume_m3; false keeps volumes for reference.
use_weightNoOptimize by weight. Omit to follow the vehicles' max_weight_kg; false keeps weights for reference.
max_load_ratioNoHighest share of each vehicle's weight/volume capacity to fill. Default 0.95 (5% margin); 1 only when the user asks to fill vehicles completely.
idempotency_keyNoOptional key to deduplicate retries. By default identical arguments are deduplicated.
exclude_stop_idsNoWith plan_id or dataset_id: stops to leave out of this run only; the plan keeps them.
route_start_timeNoTime routes leave the depot, local HH:MM. Needed for arrival times and time windows.
use_time_windowsNoRespect the stops' time windows. Omit to follow the data; false keeps them for reference.
max_route_minutesNoTarget journey length per route in minutes (travel + service). A balancing target, not a hard limit: the engine evens routes out towards it and some may run longer. Tell the user it is a target, check the durations in the result, and when routes exceed it offer more vehicles or fewer stops per vehicle.
service_time_minutesNoMinutes spent at each stop.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoStructured error when the tool call failed.
resultNoPresent when the optimization finished within the call.
statusNoqueued / running / completed / failed. Absent on a preflight-only reply.
plan_idNoThe plan this lives in, in the user's Vepathos account (list_plans).
progressNoPresent while queued or running.
plan_nameNoName of that plan.
preflightNoPresent instead of an optimization when confirmed was false: nothing ran, nothing was charged.
expires_atNoWhile running: when an unfinished run is dropped (UTC). Completed runs stay.
free_retryNoTrue when this run is another try (no monthly stops charged). Say 'another try' / 'otro intento'; never call it free.
account_urlNoOpens the plan in the user's Vepathos account. Requires signing in; private to the account.
plan_replacedNoSet when the library was full: this plan was removed to make room. Tell the user its name.
quota_chargedNoFalse when this run is another try of the plan or the trial: no stops charged.
schedule_dateNoDate used for the run, YYYY-MM-DD.
depot_resolvedNoPresent when the depot was given as an address: tell the user the matched address the routes start from.
plan_temporaryNoTrue when every library slot is kept or favorite: the plan lives outside the library and is deleted later. Tell the user.
optimization_idNoHandle for get_optimization_result.
submitted_stopsNoStops accepted into this job.
idempotent_replayNoTrue when identical arguments returned an optimization that already existed.
full_trial_appliedNoPresent when this job used the one-time MCP full trial.
poll_after_secondsNoCall get_optimization_result again after about this many seconds.
vehicles_availableNoFleet units declared (sum of vehicles[].count).
free_retries_remainingNoOther tries of this plan still available after this run: within 24 h, same stops or fewer, by plan_id. Say 'other tries' / 'otros intentos'; do not call the run free.
stops_remaining_this_periodNoStops left in the plan's current billing period (null means unlimited).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses the charging model ('A run spends one monthly stop per stop'), the 'otro intento' retry semantics, deduplication of identical arguments, rejection behavior, plan persistence/replacement effects, and the requirement to tell the user when plan_replaced or plan_temporary is set. This far exceeds what annotations alone convey. No contradiction with annotations is present.

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

Conciseness4/5

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

The description is long, but every sentence carries operational value for an 18-parameter, billing-sensitive tool. It is appropriately front-loaded with the core purpose and then covers sources, charging, exceptions, and post-call behavior. It is somewhat dense as a single monolithic paragraph, which prevents a 5, but there is no redundant filler.

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

Completeness5/5

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

Given the tool's complexity, destructive/charging behavior, and rich output schema, the description covers everything an agent needs: stop source selection, depot formats (including telling the user about depot_resolved), charging and retry rules, consent-before-call, deduplication, rejection conditions, plan lifecycle, required route_start_time, and how to obtain results. Nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantic clarity: the exclusivity of the three stop sources, the persistence differences between plan_id/dataset_id and stops, that route_start_time is needed for arrival times, and that max_route_minutes is a target rather than a hard limit. These nuances go beyond the schema property descriptions.

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?

The description opens with a specific verb and resource ('Plan delivery routes (vehicle routing problem, VRP)') and precisely states the objective: assign stops to vehicles, sequence routes from one depot, and minimize distance subject to capacity and time-window constraints. It also distinguishes itself from sibling tools by referencing get_optimization_result for polling and import_deliveries for file/list/address-based stops.

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

Usage Guidelines5/5

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

The description gives explicit routing guidance: exactly one source of stops (plan_id, dataset_id, or in-conversation stops), with files/lists/addresses explicitly directed to import_deliveries first. It also mandates a precondition ('first tell the user the stops it charges... get a yes, then call once') and points to get_optimization_result for retrieval, making when-to-use and when-not-to-use unambiguous.

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.

Resources