Skip to main content
Glama
Sign In

Fleet Route Optimizer

by com.kindoflost.routing
OverviewDiscussionsAdmin

Optimize delivery routes

optimize_routes
Read-only

Plan routes for one or more vehicles from one depot and return, per vehicle, the stop order with arrival times and load so far, plus stops that could not be served, totals, Google Maps links and warnings. Uses real road driving times. Solves take 10-60 s (more when many addresses must be looked up). Pass either example or the fields below. If the result has status 'running', call get_route_result with its job_id. Minimal example: {"depot": {"address": "1600 Pennsylvania Ave NW, Washington, DC 20500"}, "stops": [{"id": "Ana", "address": "..."}, {"id": "Bob", "lat": 38.9, "lon": -77.03, "window_open": "09:00", "window_close": "12:00", "service_minutes": 10}], "vehicles": 2}. Omitted: capacity = unlimited, no time windows, 1 vehicle, depot = the first stop, stops are dropped only when they cannot be served at all; every default applied is listed in the result's 'assumptions'. Call get_route_example for complete, realistic inputs.

Input Schema

NameRequiredDescriptionDefault
goalNoOne sentence, in the user's own words, of what they are trying to do (e.g. 'plan tomorrow's deliveries for 3 vans'). Optional; helps improve the tool.
depotNoREQUIRED in practice: where every vehicle starts and ends, as an OBJECT with an address or lat+lon (a plain address string is also accepted and used as the address), e.g. {"address": "1 Main St, Springfield, IL 62701"} or {"lat": 41.4993, "lon": -81.6944}. If omitted, the first stop is used as the depot (reported in 'assumptions').
stopsNoThe places to visit (not the depot). Each needs an address or lat+lon.
countryNoWhich geocoder reads the addresses: US (US Census, then OpenStreetMap) or OTHER (OpenStreetMap). Default US.
exampleNoSolve this built-in example instead of passing the fields below.
vehiclesNoEither a number of identical vehicles (unlimited capacity), or one object per vehicle.
parametersNoOptional engine settings: SearchParametersTimeLimit (seconds, default 30, max 60), NoImprovementSeconds (20), RouteTimeLimit (minutes, default 1440), DroppedOrderCost (100000 = serve every stop that can be served), MinuteCost (1), LatePenaltyPerMinute (0 = windows are hard), MaxWaitMinutes (1440), MinimumDriveTime (5).
wait_secondsNoHow long to wait for the solve inside this call (default 25).
previous_routesNoRe-optimize from existing routes: one list of stop ids (or 1-based stop numbers) per vehicle, in visiting order. The solver starts from these and improves them; new stops are fitted in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / depot / description
      Previous value: -"Where every vehicle starts and ends. Needs an address or lat+lon. If omitted, the first stop is used as the depot (reported in 'assumptions')."New value: +"REQUIRED in practice: where every vehicle starts and ends, as an OBJECT with an address or lat+lon (a plain address string is also accepted and used as the address), e.g. {\"address\": \"1 Main St, Springfield, IL 62701\"} or {\"lat\": 41.4993, \"lon\": -81.6944}. If omitted, the first stop is used as the depot (reported in 'assumptions')."
    • changedInput schema / properties / depot / type
      Previous value: -"object"New value: +[
+  "object",
+  "string"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / depot / description
      Previous value: -"Where every vehicle starts and ends. Needs an address or lat+lon."New value: +"Where every vehicle starts and ends. Needs an address or lat+lon. If omitted, the first stop is used as the depot (reported in 'assumptions')."
    • addedInput schema / properties / goal
      Added value: +{
+  "description": "One sentence, in the user's own words, of what they are trying to do (e.g. 'plan tomorrow's deliveries for 3 vans'). Optional; helps improve the tool.",
+  "maxLength": 300,
+  "type": "string"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnly/openWorld/non-idempotent; the description adds the operationally critical facts: solves take 10-60 s (longer with geocoding), the call may return a 'running' job, and every default applied is echoed in the result's 'assumptions'. That is context the agent cannot get from the annotations or schema.

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?

Purpose and return values are front-loaded in the first sentence, followed by timing, async contract, and defaults. The single dense paragraph and inline JSON example make it slightly heavy to scan, but nearly every clause carries information an agent needs.

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?

For a 9-parameter nested tool with no output schema, the description covers return shape, latency, async continuation, and default-handling behavior — everything needed to call it correctly. The remaining detail (individual parameter formats) is fully carried by the schema at 100% coverage.

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 goes further by summarizing the defaulting rules (unlimited capacity, no time windows, 1 vehicle, depot = first stop, drop only when unservable) and showing a concrete minimal payload that demonstrates depot/stops/vehicles interplay. It does not explain `previous_routes` or `parameters` beyond the schema, so it falls short of a 5.

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?

States a specific verb and resource ('plan routes for one or more vehicles from one depot') and immediately enumerates what comes back (stop order, arrival times, loads, unserved stops, totals, maps links, warnings). It also names the sibling used for polling ('call get_route_result with its job_id'), so the agent can place it in the workflow without opening the schema.

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?

Gives explicit routing rules: pass either `example` or the fields below, call get_route_result when status is 'running', and call get_route_example for complete realistic inputs. The alternative paths and the condition selecting each are spelled out rather than implied.

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

All Fleet Route Optimizer toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources