vortx-ai/emem/emem-recall-polygon

emem-recall-polygon

Network use. The commands in this skill send JSON to https://emem.dev and receive JSON from it. 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. The commands read no environment variable, key or credential. They read only local files that an earlier step saved from https://emem.dev.

One call samples cells inside an area and recalls the bands at each cell. It does the work of locate, a cell sample and recall_many together. The rollup (mean, minimum, maximum) is your job.

When to use this skill

• "What is the average NDVI inside this watershed?"
• "Show me the precipitation across the area bounded by ..."
• The user pastes a bounding box or a GeoJSON polygon.

Use a different path in these cases:

Step 1: give the area

Give the area in one of three fields:

A polygon alone sets the area. Its bounds become the box, and its boundary masks the sample. When you also send a bbox, the polygon only masks the sample.

Step 2: recall the area

Call emem_recall_polygon with this body:

{"polygon_bbox": {"min_lat": 12.95, "max_lat": 13.05, "min_lng": 77.55, "max_lng": 77.65},
 "bands": ["copdem30m.elevation_mean"],
 "max_cells": 16, "budget_ms": 20000}

emem_recall_polygon is not in the short tool list that the MCP server of the plugin shows. The server runs it by name through tools/call. If your host calls only listed tools, use the REST route.

An MCP result larger than about 24 KB comes back slimmed. _emem_truncation names what the server removed. For the full response, send the same body to the REST route, POST https://emem.dev/v1/recall_polygon. Save the answer as poly.json. Then print a summary:

jq '{cells_sampled, facts_returned, area_km2, converged, coverage_fraction,
     is_exhaustive, pending: (.pending | length), source: .polygon_bbox.source}' poly.json

On 6 and 7 November 2026 this call returned 200 with 16 cells sampled, 16 facts, area_km2 120.05, coverage_fraction 0.0000133, converged: true and no pending entries.

The two limits:

Step 3: read the coverage

A sample is not the area. Sixteen cells over 120 km² is a sample. Report it as a sample.

When you send a place, read polygon_bbox.source:

For centre_cell_bbox, tell the user that the answer is for one cell. Do not present a one-cell answer as a regional answer.

On 7 November 2026, "place": "Cubbon Park, Bengaluru" with max_cells 4 returned nominatim_boundingbox, area_km2 1.64 and 4 facts.

Step 4: handle a partial answer

When budget_ms runs out, the call returns a partial 200 with converged: false and a pending[] list. Each entry says why it is pending and what to do. The server does not stop the pending fetches. Thus the same request, sent again, can return more facts. The responder does not sign the entries in pending. They do not state that a cell has no data.

On 28 September 2026, the call in step 2 returned 200 with 0 facts, converged: false and 16 entries in pending (state: "materializing"). Nine retries of the same call over 30 minutes also returned 0 facts. The fetch path of the responder had no free capacity.

Retry a few times with a pause. If pending does not get shorter, tell the user that the upstream fetch has stopped. Do not loop. Never report an empty answer as "no data here".

A request with many cold cells and several bands can pass the 40 s transport budget of the responder. It then returns compute_timeout. Use fewer bands or fewer cells. Or retry after the first pass has filled the cache.

Step 5: make the rollup

The response gives facts for each cell. Skip absences: a null value is a signed statement that the upstream had no data. Guard the empty case:

jq '[.by_cell[].facts[] | select(.band == "copdem30m.elevation_mean" and .value != null) | .value]
    | if length == 0 then {count: 0}
      else {count: length, mean: (add / length), min: min, max: max} end' poly.json

On 6 and 7 November 2026 this filter gave 16 values, a mean of 906.7 m, a minimum of 885.1 m and a maximum of 940.7 m.

Each cell facts[] can hold several readings of one band, oldest first (fact_order: "tslot_ascending"). For the current value, take the last reading of each band. Or take the reading with the tslot that you mean.

Response shape (abridged)

{
  "by_cell": {
    "<cell64>": { "facts": [ ... ], "receipt": { ... }, "fact_order": "tslot_ascending",
                  "bands_already_attested_at_cell": [ ... ] }
  },
  "cells": [ ... ], "cells_sampled": 16, "facts_returned": 16,
  "area_km2": 120.05, "coverage_fraction": 0.0000133, "is_exhaustive": false,
  "converged": true, "pending": [], "polygon_bbox": { ..., "source": "..." },
  "merged_facts": [ ... ], "schema": "emem.recall_polygon.v1"
}

Step 6: cite and verify the cells

The rollup has no receipt of its own. Each cell receipt verifies that cell only. Say which cells and which statistic you used.

The facts in this response carry no memory_token field. Make the emem:fact:<cell64>:<fact_cid> tokens from each cell receipt:

jq -r '.by_cell | to_entries[] | .key as $c | .value.receipt.fact_cids[]
       | "emem:fact:\($c):\(.)"' poly.json

To check one cell receipt on the server, send it as {"receipt": ...}:

jq -c '{receipt: .by_cell | to_entries[0].value.receipt}' poly.json > verify_req.json

Send verify_req.json as the body of POST https://emem.dev/v1/verify_receipt. Read valid, signature_valid and merkle_proof_valid in the answer.

On 6 and 7 November 2026 both commands ran. The check returned true for all three fields. To check offline, use `emem-verify-receipt`.

To give many cells as one citation, send their fact_cid values to POST /v1/memory_bundle {"fact_cids":[...]}. It returns one emem:bundle: token. This call stores the bundle on the responder, so this skill did not run it. See `emem-multi-agent-handoff`.

Before you publish the rollup, see `emem-referential-drift` and `emem-verify-before-publish`.