vortx-ai/emem/emem-field-signals

emem-field-signals

Network use. The commands in this skill send JSON to https://emem.dev and receive JSON from it. One step also receives an image. https://emem.dev is the service that the MCP server of the plugin connects to. The commands do not execute what they download. This skill ships no scripts. Its commands read no environment variable, key or credential. The only local files that they read are files that an earlier step saved from https://emem.dev. This skill writes out every request body.

Pick the call

Each question is one call.

field_boundaries and field_series are tools of the MCP server of the plugin. They are not in the short tool list that the server shows. The server runs them by name through tools/call. If your host calls only listed tools, or has no MCP, send the same JSON body to the REST route in the table.

field_burn_scar and field_actual_et have no MCP tool. Send their bodies to the REST routes. The two routes take the same body:

The warm-up fetches facts that the responder does not hold yet. When the budget ends, the call answers from the stored facts. The warm-up continues after the answer, so a retry can read more facts.

Step 1: get the field edges

Send this body to POST https://emem.dev/v1/field_boundaries, or call emem_field_boundaries with it:

{"polygon_bbox": {"min_lat": 30.90, "max_lat": 30.903, "min_lng": 75.80, "max_lng": 75.804}, "clean": true}

Save the answer as fields.json. Then print a summary:

jq -c '{count, returned, license, overlap_after_m2: .synthesis.overlap_after_m2,
  fields: [.geojson.features[] | {area_m2: .properties.area_m2, centroid: .properties.cell64_centroid}]}' fields.json

A result over the MCP wire budget (about 24 KB) comes back slimmed. The _emem_truncation field names what the server left out. To get every polygon, use the REST route.

clean: true resolves overlapping and duplicate polygons. Then synthesis.overlap_after_m2 must be 0. The responder reads the product for each map tile, so polygons extend past your bbox. total_area_m2 is the area over the tiles read, not over the bbox. Quote license and attribution with any map.

On 7 November 2026 this call gave 19 input polygons and 17 output polygons. It dropped 2 duplicates and resolved an overlap of 165,206 m² to 0. This answer has no receipt. Each polygon has a polygon_cid that identifies its outline.

Step 2: check for a residue burn

Send this body to POST https://emem.dev/v1/field_burn_scar:

{"geometry_geojson": {"bbox": [75.80, 30.90, 75.804, 30.903]}, "start": "2025-10-01", "end": "2025-11-30", "max_cells": 16}

Save the answer as burn.json. Then print a summary:

jq -c '{verdict, burn_events, events, observations}' burn.json

To check one field and not the full box, put a polygon from Step 1 in geometry_geojson in place of the bbox.

The call compares each pair of clear Sentinel-2 dates in each cell. It uses three sensors:

Each pair with a dNBR of 0.1 or more gets a verdict in cell_signals[]. The verdict depends on the number of sensors that agree: 0 is no_burn, 1 is single_sensor_signal, 2 is likely_burn, 3 is high_confidence_burn. The call does not compare pairs more than 30 days apart.

The verdict for the field:

For inconclusive, make the window wider, or retry after the warm-up ends. observations.warmed shows which bands finished the warm-up in the budget. CAMS smoke bands are in sensors_not_evaluated with the reason: they are 0.4° model fields.

On 7 November 2026 this call gave verdict: "signal_only" and burn_events: 0. Each of the 16 cells had a median of 14 clear dates. Two of ten cell signals were single_sensor_signal. The receipt named 451 fact cids. These counts grow while the warm-up adds facts: an earlier call on the same day saw 6 clear dates and 195 fact cids. On 28 September 2026 the same call gave inconclusive, because the responder had not fetched the Sentinel-2 facts yet.

Step 3: get the crop water use

Send this body to POST https://emem.dev/v1/field_actual_et:

{"geometry_geojson": {"bbox": [77.03, 32.57, 77.036, 32.573]}, "start": "2026-05-01", "end": "2026-06-30"}

Save the answer as et.json. Then print a summary:

jq -c '{verdict, et_mm, et_m3_per_ha, coverage, pixel_m,
  composites: [.composites[] | {composite_start, days_in_window, et_mm, fact_cid}]}' et.json

On 7 November 2026 this call gave verdict: "complete", et_mm: 148.04, et_m3_per_ha: 1480.38 and coverage: 1.0. It used eight 8-day composites, each with its fact_cid. The last composite counts 5 of its 8 days.

The value is MOD16A2 at one 463 m pixel over the field centre. A field smaller than the pixel shares it with its neighbours. The value is the water that the field evaporated and transpired. It is not the irrigation applied.

Step 4: look at the plot

No MCP tool returns this picture. Send a GET to this URL and save the answer as plot.png:

https://emem.dev/v1/scene.png?bbox=75.80,30.90,75.804,30.903&datetime=2025-10-01/2025-10-31&max_cloud=30

Read the response headers x-emem-scene-item-id, x-emem-scene-datetime and x-emem-scene-cloud-cover.

The PNG is a Sentinel-2 pass over the box at native 10 m. The x-emem-scene-item-id, x-emem-scene-datetime and x-emem-scene-cloud-cover headers name the scene. On 7 November 2026 this call gave a 39 x 34 px PNG from scene S2C_MSIL2A_20251028T053951_R005_T43REQ_20251028T084920, 1.96 % cloud.

Without datetime, at or max_cloud, the responder searches recent scenes and widens the search step by step. On 7 November 2026 that default search for this box failed with HTTP 502 scene_upstream_failed ("no valid red pixels"). If you get this error, set datetime and max_cloud.

If every search misses, the answer is HTTP 404 no_clear_scene with the searches tried. The picture is a view, not a signed artifact. For pixels that a third party can hash again, use `emem-field-tokens`.

Step 5: get an index for each scene

Send this body to POST https://emem.dev/v1/field_series:

{"bbox": [75.80, 30.90, 75.804, 30.903], "index": "ndvi", "start_date": "2025-10-01", "end_date": "2025-10-31"}

Save the answer as series.json. Then print one line for each scene:

jq -c '.rows[] | {date, mean, clear_fraction, quality, scene, scene_cloud_cover}' series.json

On 7 November 2026 this call gave 6 rows. The first row was 2025-10-08, mean NDVI 0.523, clear_fraction 1.0.

Radar rows have no clear_fraction. Their mean is the dB of the mean linear power, with se_db, pixel_enl, below_nesz_share and bright_rejected. On optical indices, a scene that both time neighbours refute gets quality: "suspect" and a scene_check. The trend does not use it.

Verify and cite

The burn, water and series answers carry a receipt over the fact cids that they used. Check it with `emem-verify-receipt`. Cite the per-cell or per-composite fact_cid values, not the verdict alone. POST /v1/memory_bundle {"fact_cids":[...]} collapses many cids into one token, but it stores a record on the responder. For an EUDR deforestation check on the same plot, see `emem-eudr-due-diligence`.