This server is an MCP-based last-mile delivery route planner that solves capacitated vehicle routing problems with time windows (CVRPTW) over stdio JSON-RPC.
Plan daily routes for a fleet, respecting capacity (weight and units), time windows, service times, driver shifts, depot return, and objective (distance, time, or balanced).
List deliveries and vehicles with optional filters (date, status, depot, active).
Get detailed route info: stop sequence, ETAs, cumulative load.
Evaluate inserting a delivery into active routes: marginal cost in km/min, best position, and feasibility.
Commit an insertion into a route at a chosen position and rewrite downstream ETAs.
Mark a vehicle out of service and retrieve its orphaned deliveries.
Reassign deliveries among active vehicles and report which ones do not fit.
Update delivery status (pending, assigned, delivered, failed).
Export printable route sheets as markdown or CSV.
Uses Google OR-Tools with automatic fallback to Clarke-Wright + 2-opt; optionally uses OSRM for real road distances; persists data in SQLite.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@delivery-mcp-server Plan optimized routes for today's deliveries"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP local que planifica rutas de vehiculos con capacidad y ventanas de tiempo (CVRPTW) para una flota de reparto de ultima milla. Hecho para CC3067 Redes — Proyecto 1, punto 5 (servidor local propio, no trivial).
Transporte: stdio, JSON delimitado por saltos de linea.
Protocolo: JSON-RPC 2.0 a mano — sin SDK de MCP.
Solver: Google OR-Tools (CVRPTW), con fallback automatico en Python puro Clarke-Wright + 2-opt.
Almacenamiento: SQLite, creada y sembrada en el primer arranque.
Por que no es trivial: respeta capacidad por peso y por unidades, ventanas de tiempo duras con tiempo de servicio por parada, el turno del conductor, el retorno obligatorio al depot, y reporta las entregas infactibles con un motivo en vez de fallar en silencio. Ademas permite analisis "que pasaria si" (costo marginal de insertar una entrega) y disrupciones de flota (vehiculo fuera de servicio -> reasignacion).
Herramienta | Parametros | Devuelve |
|
| entregas con peso, direccion y ventana horaria |
|
| flota con capacidad (kg/unidades) y turno |
|
| por vehiculo: secuencia de paradas, ETA, distancia, duracion; no asignadas + motivo; persiste el plan |
|
| detalle parada por parada con carga acumulada |
|
| km/min marginal por ruta activa, mejor posicion, factibilidad de capacidad y ventana |
|
| inserta y recalcula los ETA |
|
| marca inactivo, devuelve entregas huerfanas |
|
| redistribuye entre vehiculos activos; lista lo que no cupo |
|
| confirma el cambio |
|
| hoja de ruta imprimible |
Ejemplos completos de request/response: examples/usage.md.
Related MCP server: Logistics AI MCP
git clone https://github.com/JPLopez23/delivery-mcp-server.git
cd delivery-mcp-server
uv sync
# o: python -m venv .venv && source .venv/bin/activate && pip install -e .Si OR-Tools no instala en tu plataforma, quitalo del pyproject.toml: el
servidor cae automaticamente a la heuristica Clarke-Wright (respeta capacidad;
reporta las violaciones de ventana pero no las fuerza).
La base SQLite se crea de data/schema.sql + data/seed.sql en el primer
arranque. Borra data/routes.db para reiniciar. La ruta se cambia con la
variable de entorno ROUTE_DB.
Opcional: define OSRM_URL apuntando a una instancia de OSRM para usar
distancias reales de calle en vez de haversine + factor de rodeo.
El servidor habla MCP por stdin/stdout; lo lanza un anfitrion (el chatbot, o Claude Desktop). Prueba manual:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"t","version":"0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
'{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"plan_routes","arguments":{"date":"2026-08-30"}}}' \
| uv run python -m route_optimizer.serverEn el config/servers.json del anfitrion:
{
"name": "delivery",
"transport": "stdio",
"command": "uv",
"args": ["run", "--directory", "../delivery-mcp-server", "python", "-m", "route_optimizer.server"],
"env": { "ROUTE_DB": "data/routes.db" }
}{
"mcpServers": {
"delivery": {
"command": "uv",
"args": ["run", "--directory", "/ruta/absoluta/delivery-mcp-server", "python", "-m", "route_optimizer.server"]
}
}
}Transporte: stdio. Un mensaje JSON-RPC 2.0 por linea, UTF-8.
Metodos: initialize, notifications/initialized, tools/list,
tools/call, ping.
Version de protocolo: 2025-06-18.
Errores: codigos JSON-RPC estandar (-32700 parse, -32600 invalid
request, -32601 method not found, -32602 invalid params, -32603
internal). Los fallos de una herramienta vuelven como un result normal con
isError: true y un texto, para que el LLM reaccione.
Coordenadas: WGS-84 en grados decimales. Horas: HH:MM, 24h, local.
Modelo de datos: depots, vehicles, deliveries, routes, route_stops
(ver data/schema.sql).
uv run --with pytest python -m pytest -q18 pruebas en tests/test_tools.py: cada herramienta,
los tres escenarios de la guia (planificar el dia de la flota / insercion
urgente con costo marginal / averia de vehiculo + reasignacion) y las
restricciones que hacen no trivial al servidor: capacidad por peso y unidades,
ventanas de tiempo duras con tiempo de servicio, turno del conductor, retorno
al depot y reporte explicito de infactibilidades.
Repositorio publico, desarrollo individual para CC3067. OR-Tools se usa bajo su licencia Apache-2.0. Uso de IA generativa conforme al reglamento de la UVG.
Insert a delivery into a route at a position and rewrite downstream ETAs.
| Name | Required | Description | Default |
|---|---|---|---|
| position | Yes | 1-based seq to insert at | |
| route_id | Yes | ||
| delivery_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does reveal that downstream ETAs are rewritten, but it omits persistence/irreversibility, failure behavior, permission requirements, and whether the route is modified in place.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and immediately states the key consequence, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not describe return behavior, error cases, side effects beyond ETA rewriting, or how this tool relates to evaluate_insertion, so an agent may not call it correctly in all contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not add meaning beyond the parameter names. It does not clarify delivery_id or route_id semantics, nor does it explain position bounds or what happens on an invalid position.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert'), names the resource (a delivery into a route), and specifies the action's effect (rewrites downstream ETAs). This clearly differentiates it from evaluate_insertion, which would assess but not rewrite ETAs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Given the sibling evaluate_insertion, an agent must infer when to commit versus evaluate, and there are no exclusions, prerequisites, or validation conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marginal cost (km and minutes) of inserting a delivery into each active route for a date, the best position, and whether it violates capacity or time windows. Provide either delivery_id (existing) or a new_delivery object.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| delivery_id | No | ||
| new_delivery | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the computed outputs: marginal cost, best position, and violation checks. However, it does not explicitly state that this is a non-mutating evaluation, nor describe the response shape beyond the listed outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense, well-structured sentence. It front-loads the core outputs, then states the input requirements. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the main inputs, the decision context, and the key returned information. It could add date format guidance or clarification of 'active routes', but the provided description is largely sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds important meaning by explaining that date is the context, and that either delivery_id (existing) or a new_delivery object must be provided. It does not detail nested new_delivery fields, but the schema field names are already self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: computing marginal cost, best insertion position, and capacity/time-window feasibility for a delivery across active routes. The verb is implied by the tool name but the description itself is action-oriented and clearly differentiates from commit_insertion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly communicates when to use the tool: when assessing insertion cost and feasibility for a given date. It explains the two input modes (existing delivery_id or new_delivery object), but it does not explicitly say 'use this before commit_insertion' or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a printable route sheet for a route as markdown or CSV text.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | md | |
| route_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the action and output formats, omitting any details about side effects, required permissions, error handling, or whether the operation is read-only. For an export tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the basic function but lacks details on return value, error conditions, or prerequisites. It is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description should clarify parameter meaning. It only mentions 'for a route' (route_id) and 'as markdown or CSV text' (format), which adds little beyond the schema's structure. The required nature of route_id and default of format are not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: rendering a printable route sheet for a specific route, with explicit output formats (markdown or CSV). It distinguishes itself from sibling tools like get_route_detail by focusing on printable output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to siblings, nor does it mention any prerequisites or scenarios. An agent must infer its usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full stop-by-stop detail of a planned route: sequence, ETA, cumulative load.
| Name | Required | Description | Default |
|---|---|---|---|
| route_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It makes clear this is a read-style operation returning route details, but does not mention what happens for invalid or missing route_ids, permission requirements, or whether cumulative load is computed or stored. The verb 'get' implies read-only, which is reasonable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core purpose and immediately lists the key output dimensions, making it easy to scan while conveying the essential value of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, the description gives enough output detail to understand what the tool returns. However, there is no output schema and no mention of where route_id comes from or when this tool is appropriate, leaving some practical gaps for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the undocumented route_id parameter. It does not mention route_id at all, its origin, or how it relates to plan_routes. The parameter name is self-explanatory, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('route detail') and lists concrete output contents: stop-by-stop sequence, ETA, and cumulative load. It is clear enough to distinguish from list_deliveries and list_vehicles, though it does not explicitly differentiate from export_route_sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus siblings such as export_route_sheet or evaluate_insertion. The phrase 'planned route' vaguely implies it should be used after route planning, but no explicit condition or alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deliveries for a date with weight, address and time window.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the safety burden itself. 'List' implies a read-only operation and the fields describe what is returned, but the description does not explicitly confirm it has no side effects, nor does it mention optional filtering behavior or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence contains the core action, scope, and return fields with no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter list operation, this is minimally sufficient: an agent knows the date is required and what fields are returned. However, it leaves the optional status filter unexplained and provides no reassurance about read-only behavior, pagination, or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 50% of parameters carry schema descriptions, and the description does not compensate: the required 'date' is repeated but the optional 'status' parameter is not described beyond its enum values. No explanation of status as a filter is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List'), a resource ('deliveries'), a scoping condition ('for a date'), and the returned fields (weight, address, time window). This clearly distinguishes it from siblings like list_vehicles or plan_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The date condition implies this is for fetching a delivery manifest for a specific day, but there is no explicit statement of when to prefer it over siblings such as get_route_detail or export_route_sheet. No alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List fleet vehicles with capacity (kg / units), depot and driver shift.
| Name | Required | Description | Default |
|---|---|---|---|
| depot_id | No | ||
| only_active | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden of behavioral disclosure. The verb 'List' and the listed output fields signal a read-only retrieval operation, but the description does not disclose filtering behavior, whether inactive vehicles are included by default, or pagination/ordering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the action and resource, then lists the key output attributes. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description covers the main output fields but omits parameter behavior and any filtering context. It is adequate for a basic call but not fully complete for an agent deciding how to invoke it with parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain depot_id or only_active. The parameter names are somewhat self-explanatory, but the agent receives no guidance about filtering semantics, the default of only_active, or how depot_id affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List fleet vehicles') and clarifies the output focus: capacity (kg/units), depot, and driver shift. This clearly distinguishes it from sibling tools like list_deliveries or plan_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the verb and resource, but the description does not explicitly state when to choose this tool over alternatives or mention any exclusions. Sibling tools such as list_deliveries are not referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a vehicle inactive and return its orphaned (previously assigned) deliveries.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| vehicle_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It reveals the noteworthy side effect of returning orphaned deliveries and clarifies that these were previously assigned, but it does not disclose whether the operation is reversible, what exactly becomes inactive, or what happens to the deliveries after return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence with the primary action front-loaded and a useful parenthetical clarification. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description omits essential selection context, parameter explanation, and side-effect detail. It is better than a tautology but still incomplete for a mutation tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning for either parameter. 'vehicle_id' is implied by 'vehicle', but 'reason' is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource ('Mark a vehicle inactive') and adds a distinguishing side effect ('return its orphaned (previously assigned) deliveries'), which clearly separates this operation from sibling list/plan/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives such as reassign_deliveries or update_delivery_status. The intended context is only implied by the action name, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan routes for the fleet on a date (CVRPTW). Returns per-vehicle stop sequence, ETA, distance and duration, plus deliveries that could not be assigned and why. Persists the plan so it can be inspected and edited.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| objective | No | distance | |
| vehicle_ids | No | ||
| traffic_factor | No | travel-time multiplier (>=1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return contents (per-vehicle stop sequence, ETA, distance, duration, unassigned deliveries with reasons) and the important side effect that the plan is persisted. It does not mention overwrite behavior or computational cost, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and well-structured: one sentence for purpose, one for outputs, one for side effect. Every sentence adds useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core purpose, outputs, and persistence side effect. However, it omits parameter semantics and when-to-use guidance relative to sibling planning tools, leaving an agent to infer important details about optional inputs and behavior for a 4-parameter tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description does not compensate for the undocumented parameters. It mentions 'date' inline but does not explain objective, vehicle_ids, or traffic_factor beyond what the schema already provides. The enum values and the filtering semantics of vehicle_ids remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Plan routes for the fleet on a date' and identifies the problem type (CVRPTW). It clearly distinguishes itself from siblings like get_route_detail, evaluate_insertion, and export_route_sheet by focusing on plan creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when fleet routes need to be computed for a date, and the note about persisting the plan hints at a side effect, but it does not explicitly state when to use this tool versus alternatives like evaluate_insertion or commit_insertion. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redistribute the given deliveries among active vehicles for a date; lists what did not fit.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| delivery_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the operation mutates assignments and that unassigned deliveries are listed, but it does not explain whether existing route assignments are overwritten, whether the change persists immediately, or what side effects occur on current plans. This is a meaningful transparency gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence with the action verb front-loaded and the output behavior separated by a semicolon. There is no filler or repetition; every word adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain both invocation context and return behavior. It only partially explains results by saying what did not fit, but it does not describe the successful reassignment output, nor does it clarify how this relates to the sibling route-planning and insertion tools. The agent is left uncertain about side effects and next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps delivery_ids to 'the given deliveries' and date to 'for a date,' and adds context about 'active vehicles.' However, it does not explain the expected date format, what kind of delivery IDs are expected, or how active vehicles are chosen.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific mutating verb ('Redistribute') and names the resource ('the given deliveries') and scope ('among active vehicles for a date'). It also hints at a distinctive partial-failure output ('lists what did not fit'), which separates it from plain listing tools. It does not explicitly differentiate itself from siblings like plan_routes or commit_insertion, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to choose this tool over alternatives such as plan_routes, evaluate_insertion, or commit_insertion. It neither states prerequisites (e.g., needing active vehicles or pre-existing deliveries) nor says when not to use it. Any usage context is only implied by the word 'redistribute.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a delivery's status (pending | assigned | delivered | failed).
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| delivery_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It indicates the operation is a mutation ('Set') but does not disclose side effects, validation rules, failure behavior, or whether status transitions are restricted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the resource, and the value domain efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is minimally adequate. However, without annotations, output schema, or usage context, it leaves gaps around status transition rules and expected behavior in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. It only restates the enum values already present in the input schema and provides no additional meaning for delivery_id, its format, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a specific resource ('delivery's status') and enumerates the four valid status values. This makes the tool's purpose unmistakable and clearly distinguishes it from sibling tools like reassign_deliveries or mark_vehicle_out_of_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings, when status transitions are allowed, or what the expected workflow is. The only implied usage is the generic action stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0commit_insertionevaluate_insertionexport_route_sheetget_route_detaillist_deliverieslist_vehiclesmark_vehicle_out_of_serviceplan_routesreassign_deliveriesupdate_delivery_statusScored across 10 tools
Each tool has a clear, distinct purpose: listing deliveries/vehicles, planning routes, viewing route details, evaluating/committing insertions, managing vehicle status, reassigning, updating delivery status, and exporting. No overlapping or ambiguous tools.
All tool names follow a consistent verb_noun snake_case pattern (list_, plan_, get_, evaluate_, commit_, mark_, reassign_, update_, export_). Verbs are specific and accurately describe actions.
10 tools is well-scoped for a delivery route planning MCP server, covering the full workflow without unnecessary bloat or missing essentials.
The surface covers the main lifecycle: listing, planning, viewing, modifying, and exporting. Minor gaps exist such as directly adding/removing deliveries or canceling a route, but the core operations are well represented.
Agentic-AI route optimization for delivery fleets, capacity- and time-window-safe.
Route optimization for delivery fleets: plan, edit, and re-optimize multi-stop routes by prompt.
Optimize crew and workforce schedules, resource allocation, and routing with linear and mixed-inte…
Field operations on a deterministic solver — run jobs, crews & fleet from Claude or ChatGPT.