Six stops.
One deadline.
Will the route hold?
A short route can still be a risky plan. Let Rust find a route, turn distance into time under your assumptions, then test the deadline.
Run this same mission with your AICan this route meet your deadline?
Only input geometry is shown. A route appears after native execution returns its receipt.
Preparing the 3D route table…
Only your input points are shown. The raised surface and pins are display only; no path or result is inferred.
Read the stored route orders
Point indices are zero-based. The last edge returns to the first point. Playback shows traversal order, not computation time or vehicle speed.
No valid complete stored tour is available for this view.
A connection has to mean something.
Two directly callable engines. One checked conversion. Your inputs stay inside this native execution.
Nothing has run. Your constraints define the mission.
Find the route.
Choose a closed tour through the six supplied points. The receipt says whether exact search finished.
route_optimizer Expected path · not yet plannedMake time explicit.
Check every leg against its original coordinates. Convert kilometres using your declared speed, then round each positive leg upward.
route_durations.v1 Expected path · not yet plannedTest the deadline.
Simulate the declared duration uncertainty. Return the share of runs within your deadline, with a sampling bound.
simulate_plan Expected path · not yet plannedFor every positive leg: ceil(distance_km ÷ 60 × 60) minutes. The adapter rechecks coordinates and distances before passing the full duration vector to the simulator.
The boundary stays visible.
This mission finds a nominal geometric route and assesses that one route. It does not compare alternate routes for robustness, measure traffic or prove that a deadline is safe.
- Six fixed points, a closed tour, a declared constant speed. Exactness concerns the bounded route search over floating-point distances.
- Independent uniform variation of each rounded duration is an assumption. Shared congestion and waiting times are absent.
- Every sample is used; changing the deadline requires an explicit new plan and execution. There is no adaptive stopping or automatic retry.
- Planning and native CPU execution remain separate. Both underlying engines are still independently callable through MCP.
Reproduce the mission with your assistant
Call compose_capabilities to inspect the plan, then execute_composition with these same arguments. The server recompiles and validates the path.
{
"goals": [
"simulate_plan.result.v1"
],
"available": [
"route_optimizer.request.v1",
"route.speed_kmh.v1",
"duration.independent_uniform.v1",
"sampling.fixed.v1",
"budget.minutes.v1"
],
"constraints": {
"allowed_tools": [
"route_optimizer",
"simulate_plan"
],
"local_only": true,
"max_steps": 3,
"max_search_states": 128,
"max_structural_cost": 32
},
"inputs": {
"route_optimizer": {
"metric": "euclidean_km",
"points": [
{
"x": 0,
"y": 0
},
{
"x": 4,
"y": 0
},
{
"x": 5,
"y": 3
},
{
"x": 3,
"y": 5
},
{
"x": 0,
"y": 4
},
{
"x": 2,
"y": 2
}
],
"return_to_start": true,
"time_budget_ms": 1000
},
"simulate_plan": {
"budget": 20,
"uncertainty": 0.25,
"samples": 10000,
"seed": 42
}
},
"adapters": {
"route_durations.v1": {
"speed_kmh": 60
}
}
}Follow the assistant walkthrough