build_scenario

com.hydrata/hydrata-mcp-server · Verify this server

Build a scenario's package (mesh + inputs) after showing what it will cost, and poll until built. Order of operations, so the number is shown before anything is spent: 1. GET the scenario detail. A record with no `boundary`/`computed_status` keys is a non-member's read of a public project → refused: a build needs the EDITOR role. 2. Re-call checks on `latest_run` (a re-POST is NOT deduplicated after `built`/`complete` — it would dispatch a duplicate build): no run → proceed; run `created`/`building` → resume polling, no POST; run `built`/`queued`/`computing`/`processing`/`complete` with `latest_run_is_valid` not false → return that state, no POST unless rebuild=true; run `error`/`cancelled`, or `latest_run_is_valid` false (the scenario was edited since the build) → proceed. 3. Spend gates, each a refusal with `outcome: "refused"` and no POST: the scenario has no boundary or its boundary row has no features (the server would admit the build and fail it in make_package); the estimate is None (resolution is 0/unset); the estimate is above 100,000 triangles and confirm is not true — the refusal states the number; re-call with confirm=true to proceed. An estimate of 0 over a boundary WITH features is buildable and is reported, not refused. 4. POST /projects/<id>/scenarios/<pk>/build/. Every 4xx comes back verbatim as a normal result with `http_status`: 422 MESH_TOO_LARGE (`error_code`, `estimate`, `ceiling`, `detail` — the server's hard ceiling; coarsen `resolution` or shrink the boundary; no run was created), 409 COMPUTE_TARGET_UNAVAILABLE, 400/403/404. A 409 WITHOUT an error_code is the dedup body ({status, run_id, detail}: a build is already in flight) — the tool resumes polling that run. 5. On 202 poll the detail's `computed_status` (created → building → built | error), bounded by timeout_seconds. Returns a COMPACT state, never the whole detail: `outcome` (built, error, cancelled, complete/queued/computing/processing for a run past the build, timed_out, or refused), `computed_status`, `mesh_triangle_count_estimate`, `posted`, the POST's `build` body + `http_status` when one was made, and the latest run's `run_id`, `run_status`, `error_message`, `user_message`, `mesh_triangle_count`. `timed_out` is normal (make_package re-downloads the terrain from S3 every build; minutes): call again with the same arguments — step 2 resumes polling the same run, it never POSTs twice — or cancel_run(run_id) if the run is stuck in `created` with no worker. `error` is terminal: `error_message` says why (fix the inputs, then call again — an errored latest run is rebuilt). Units: `resolution` on the SCENARIO is a LENGTH in metres — ANUGA maximum_triangle_area = resolution²/2 (run_utils.py:227/:290; FloatField default 100, not nullable; 0 makes the estimate None) and the same value becomes the raster cell size; a MeshRegion FEATURE's `resolution` is consumed by the mesher as an AREA (max_triangle_area, m²) while the estimate prices it as a length, so attached regions mesh ~15x more than estimated (Towradgi 100/36/8 m² regions: estimate ~18k, mesh ~283k); the smallest MeshRegion value becomes the raster cell size.