emem, the verifiable memory protocol for the physical world
REMOTE · EMEM.DEV · 2 COMPONENTS · SCANNED AUG 3
Shared, verifiable memory for AI agents and robots: signed tokens that resolve and verify offline.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (memory_create). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability51
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (poor).Fail
- Context-footprint check failed: tool/resource definitions use about 40357 tokens (~328/item across 123 items; 105 tools + 18 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage97
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 91% of tool parameters carry a description.Partial
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · emem.dev
claude mcp add --transport http vortx-ai-emem https://emem.dev/mcp
[mcp_servers.vortx-ai-emem] url = "https://emem.dev/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"vortx-ai-emem": {
"type": "remote",
"url": "https://emem.dev/mcp",
"enabled": true
}
}
} openclaw mcp add vortx-ai-emem --url https://emem.dev/mcp --transport streamable-http
mcp_servers:
vortx-ai-emem:
url: "https://emem.dev/mcp" {
"mcpServers": {
"vortx-ai-emem": {
"type": "http",
"url": "https://emem.dev/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 2 Aug 26 +3
- Schema quality: unverified → poor ▲ functional
- 1 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.
- 29 Jul 26 −3
- The server rewrote its instructions, which are the text every model session reads security
- Tool “emem_band_raster” rewrote its description, which is the text the model reads security
- Tool “emem_bands” rewrote its description, which is the text the model reads security
- Tool “emem_burn_severity” rewrote its description, which is the text the model reads security
- Tool “emem_capabilities” rewrote its description, which is the text the model reads security
- Tool “emem_cell_geojson” rewrote its description, which is the text the model reads security
- Tool “emem_cell_scene_rgb” rewrote its description, which is the text the model reads security
- Tool “emem_compare_bands” rewrote its description, which is the text the model reads security
- Tool “emem_coverage_map” rewrote its description, which is the text the model reads security
- Tool “emem_coverage_matrix” rewrote its description, which is the text the model reads security
- Tool “emem_data_availability” rewrote its description, which is the text the model reads security
- Tool “emem_deforestation_alert” rewrote its description, which is the text the model reads security
- Tool “emem_edges_recall” rewrote its description, which is the text the model reads security
- Tool “emem_elevation” rewrote its description, which is the text the model reads security
- Tool “emem_embedding_centroid” rewrote its description, which is the text the model reads security
- Tool “emem_errors” rewrote its description, which is the text the model reads security
- Tool “emem_eudr_dds” rewrote its description, which is the text the model reads security
- Tool “emem_explain_algorithm” rewrote its description, which is the text the model reads security
- Tool “emem_fetch” rewrote its description, which is the text the model reads security
- Tool “emem_field_boundaries” rewrote its description, which is the text the model reads security
- Tool “emem_fleet” rewrote its description, which is the text the model reads security
- Tool “emem_heat_solve” rewrote its description, which is the text the model reads security
- Tool “emem_hunt” rewrote its description, which is the text the model reads security
- Tool “emem_intent” rewrote its description, which is the text the model reads security
- Tool “emem_jepa_predict” rewrote its description, which is the text the model reads security
- Tool “emem_jepa_predict_v2” rewrote its description, which is the text the model reads security
- Tool “emem_log_sth” rewrote its description, which is the text the model reads security
- Tool “emem_log_witnesses” rewrote its description, which is the text the model reads security
- Tool “emem_memory_contradictions” rewrote its description, which is the text the model reads security
- Tool “emem_memory_search” rewrote its description, which is the text the model reads security
- Tool “emem_neighborhood_consistency” rewrote its description, which is the text the model reads security
- Tool “emem_recall_many” rewrote its description, which is the text the model reads security
- Tool “emem_recall_polygon” rewrote its description, which is the text the model reads security
- Tool “emem_region_similarity” rewrote its description, which is the text the model reads security
- Tool “emem_rice_ch4” rewrote its description, which is the text the model reads security
- Tool “emem_sar_forest_disturbance” rewrote its description, which is the text the model reads security
- Tool “emem_sources” rewrote its description, which is the text the model reads security
- Tool “emem_state” rewrote its description, which is the text the model reads security
- Tool “emem_state_multi” rewrote its description, which is the text the model reads security
- Tool “emem_temporal_route” rewrote its description, which is the text the model reads security
- Tool “emem_topics” rewrote its description, which is the text the model reads security
- Tool “emem_trajectory” rewrote its description, which is the text the model reads security
- Tool “emem_verify_receipt” rewrote its description, which is the text the model reads security
- Tool “memory_delete” rewrote its description, which is the text the model reads security
- Tool “memory_str_replace” rewrote its description, which is the text the model reads security
- Tool “emem_terrain” rewrote its description, which is the text the model reads security
- Tool “emem_air” rewrote its description, which is the text the model reads security
- Tool “emem_triple_consensus” rewrote its description, which is the text the model reads security
- Tool “emem_algorithms” rewrote its description, which is the text the model reads security
- Tool “emem_ask” rewrote its description, which is the text the model reads security
- Tool “emem_backfill” rewrote its description, which is the text the model reads security
- Schema quality: good → poor functional
- Server version: 1.2.1 → 1.3.0 functional
- New tool “emem_reason” functional
- New tool “emem_substrates” functional
- New tool “emem_trace_verify” functional
- “emem_backfill” reworded the description of “band” cosmetic
- “emem_compare_bands” reworded the description of “tslot_a” cosmetic
- “emem_derive” reworded the description of “code_cid” cosmetic
- “emem_derive” reworded the description of “provenance_class” cosmetic
- “emem_edges_recall” reworded the description of “obj” cosmetic
- “emem_elevation” reworded the description of “cell” cosmetic
- “emem_field_boundaries” reworded the description of “zoom” cosmetic
- “emem_find_similar” reworded the description of “as_of_tslot” cosmetic
- “emem_find_similar” reworded the description of “band” cosmetic
- “emem_find_similar” reworded the description of “mode” cosmetic
- “emem_forest” reworded the description of “band” cosmetic
- “emem_forest” reworded the description of “bands” cosmetic
- “emem_hunt” reworded the description of “event” cosmetic
- “emem_locate” reworded the description of “q” cosmetic
- “emem_lst” reworded the description of “band” cosmetic
- “emem_lst” reworded the description of “bands” cosmetic
- “emem_memory_contradictions” reworded the description of “window_unix_s” cosmetic
- “emem_memory_search” reworded the description of “q” cosmetic
- “emem_memory_token” reworded the description of “cell” cosmetic
- “emem_ndvi” reworded the description of “band” cosmetic
- “emem_ndvi” reworded the description of “bands” cosmetic
- “emem_query_region” reworded the description of “as_of_tslot” cosmetic
- “emem_raster_resolve” reworded the description of “spot_check” cosmetic
- “emem_recall” reworded the description of “as_of_signed_at” cosmetic
- “emem_recall” reworded the description of “as_of_tslot” cosmetic
- “emem_recall” reworded the description of “band” cosmetic
- “emem_recall” reworded the description of “deterministic” cosmetic
- “emem_recall” reworded the description of “provenance” cosmetic
- “emem_recall_many” reworded the description of “bands” cosmetic
- “emem_recall_polygon” reworded the description of “as_of_tslot” cosmetic
- “emem_recall_polygon” reworded the description of “include” cosmetic
- “emem_recall_polygon” reworded the description of “projection” cosmetic
- “emem_rice_ch4” reworded the description of “cultivation_period_days” cosmetic
- “emem_rice_ch4” reworded the description of “efc_kg_ch4_ha_day” cosmetic
- “emem_soil” reworded the description of “band” cosmetic
- “emem_soil” reworded the description of “bands” cosmetic
- “emem_state” reworded the description of “as_of_tslot” cosmetic
- “emem_state_multi” reworded the description of “as_of_tslot” cosmetic
- “emem_temporal_route” reworded the description of “intent” cosmetic
- “emem_trajectory” reworded the description of “as_of_tslot” cosmetic
- “emem_water” reworded the description of “band” cosmetic
- “emem_water” reworded the description of “bands” cosmetic
- “emem_weather” reworded the description of “band” cosmetic
- “emem_weather” reworded the description of “bands” cosmetic
- “emem_air” reworded the description of “band” cosmetic
- “emem_air” reworded the description of “bands” cosmetic
- “emem_ask” reworded the description of “cell” cosmetic
- “emem_at” reworded the description of “band” cosmetic
- “emem_at” reworded the description of “bands” cosmetic
- Tool “emem_embedding_centroid” changed its title: Embedding centroid — mean-pooled GeoTessera vector for a region → Embedding centroid, mean-pooled GeoTessera vector for a region cosmetic
- Tool “emem_embedding_diversity” changed its title: Embedding diversity — landscape heterogeneity over a region → Embedding diversity, landscape heterogeneity over a region cosmetic
- Tool “emem_eudr_dds” changed its title: EUDR Due Diligence Statement — polygon-in, signed Annex II envelope out → EUDR Due Diligence Statement, polygon-in, signed Annex II envelope out cosmetic
- Tool “emem_hunt” changed its title: Hunter mode — find event hotspots over a region → Hunter mode, find event hotspots over a region cosmetic
- Tool “emem_memory_search” changed its title: emem_memory_search — semantic search over /memories/* files → emem_memory_search, semantic search over /memories/* files cosmetic
- Tool “emem_region_similarity” changed its title: Region similarity — cosine of two regions' mean GeoTessera embeddings → Region similarity, cosine of two regions' mean GeoTessera embeddings cosmetic
- Tool “emem_terrain” changed its title: Terrain triad — slope + ruggedness + topographic position from DEM → Terrain triad, slope + ruggedness + topographic position from DEM cosmetic
- Tool “memory_create” changed its title: memory_create — write a memory file (overwrite if exists) → memory_create, write a memory file (overwrite if exists) cosmetic
- Tool “memory_delete” changed its title: memory_delete — remove a memory file or directory → memory_delete, remove a memory file or directory cosmetic
- Tool “memory_insert” changed its title: memory_insert — insert at a given line → memory_insert, insert at a given line cosmetic
- Tool “memory_list_by_kind” changed its title: memory_list_by_kind — typed enumeration of memory files → memory_list_by_kind, typed enumeration of memory files cosmetic
- Tool “memory_rename” changed its title: memory_rename — move a memory file → memory_rename, move a memory file cosmetic
- Tool “memory_str_replace” changed its title: memory_str_replace — exact-string replacement in a memory file → memory_str_replace, exact-string replacement in a memory file cosmetic
- Tool “memory_view” changed its title: memory_view — read file or directory listing → memory_view, read file or directory listing cosmetic
- 27 Jul 26 0
- Stability: unverified → 0.03 ▲ functional
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 63
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Probed https://emem.dev/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=emem.dev | CN=YE1,O=Let's Encrypt,C=US | 25 Jun 2026 | 23 Sept 2026 | ECDSA 256 | ECDSA-SHA384 | 585b40324d02015c7ffa469b0dc392dd4a8 |
| SANs: emem.dev, www.emem.dev | ||||||
| CN=YE1,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 5ddd70dd31f801c85c186a7a04b80afe |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
DNSSEC insecure
Validation of emem.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| emem.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains; preload |
| content-security-policy | default-src 'self'; script-src 'self' https://www.googletagmanager.com https://esm.sh https://cdn.redocly.com 'sha256-1LQb9Vhps9539K8WtLY4YJCvLqfXXHHrFKFU9lO7yDo=' 'sha256-3vokV7ulOzXmEDPT8jHerCF3DotZc5zDsH+ktR8/bQg=' 'sha256-5drXHcFDsHyX/M9ryszbgZHB7YSCe55jIHn/02mKXPw=' 'sha256-8vnQX7+vHcAt3ELB02aOu4MJIM+256eIdW2+xkLr5ac=' 'sha256-BC3kmFRQjI7i3nY+wYMTbt65j6ljlx+ZN433t/kignI=' 'sha256-BCnJeyXiJpn+/3NNsV51yA064CoZ8FJsey8VGQBHnM8=' 'sha256-BuChz52GVMz8nc76A+SoFZTTc+l8J0PvArPG3PF9GAE=' 'sha256-BwiUvoXcoNy0+qgJzFyEd7Q/AC9W8wpF6jwhJqdAXC4=' 'sha256-CHjGNtQ7K1LwQzVfsQaI5HpMPnT/QUFevTLL+ir1EE0=' 'sha256-D18y043mO+yptyU9fUFvoFL8ZhV2+JbGm/GzXbHoER8=' 'sha256-ESM3y/M07WghKtExySfU1rCnornbOI7uIwzL3Ngu+ok=' 'sha256-GKaIUE1muvRIoxngaNj1LRkSVR2DROt1XVsNzhyI2js=' 'sha256-JncTJLIIYKBmqB4e18NO64h1JN22U2SsMTZXAeD5db8=' 'sha256-MM8UG+X+sxn1SSO3vbj0Q/JHl9Ekn4SS1eg4MOnAIeU=' 'sha256-Nt0FXER1PgT47bnh3eP4amurWD7ly8tLVRAmcCvhk+w=' 'sha256-OgLVXQgwqGXNUbOLG2XzC/cqA1NCgR635CscyVTF6Kg=' 'sha256-RtmdiUQ8ytLlWLjL0uoPLD2w1CqKFVw9iF5YrcdnCI |
| x-content-type-options | nosniff |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | geolocation=(), microphone=(), camera=() |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://emem.dev/mcp | Verified | 200 | |
| http (plaintext) | http://emem.dev/mcp | HTTPS enforced | 308 | https://emem.dev/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
emem_jepa_predict_v2 Learned multi-band-scalar dynamics head (jepa_temporal_predictor@2) ~451
Predict the next-step value of 4 environmental scalars at a cell (`indices.ndvi`, `modis.lst_day_8day`, `modis.lst_night_8day`, `cams.pm25`) using a small learned dynamics MLP. Reads up to K=6 most-recent attested lags per band, runs them through an ONNX dynamics head (~200k params, CPU-fast), and returns a per-band {value, confidence, n_real_lags, via}. The receipt's `model` block carries `model_id`, `version`, `blake2b_hex` (model_cid), training/validation provenance, a top-level `skill_vs_persistence` block, and `honesty_warnings`, flagging `untrained_baseline` when the artifact is the zero-init sentinel and `NEGATIVE_SKILL` when the learned model is worse than persistence on real held-out NDVI. When the model does not beat persistence, bands with a real lag are returned from that lag tagged `via:persistence_fallback_negative_skill` (bands with no real lag fall back to labelled climatology). Distinct from v1 (`emem_jepa_predict`) which returns a single NDVI scalar via closed-form coefficients. When to use: Use when you want a short-horizon forecast of NDVI / land-surface temperature / PM2.5 at a cell grounded in its attested history. Returns 422 with a `/v1/backfill` hint when the cell lacks enough cached lags. Always read the receipt's `model.honesty_warnings`, `untrained_baseline` means the trivial 'predict last vintage' baseline (treat as no-op), and `NEGATIVE_SKILL` means the served values are the persistence fallback, not a learned improvement. Check each band's `via` field to see whether its value came from the learned model, persistence, or climatology. Example arguments: {"cell":"damO.zb000.xUti.zde78"}
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | cell64 to forecast at, or a free-text place name (auto-resolved via /v1/locate). |
No output schema declared.
No examples provided.
emem_locate Resolve place to cell64 + band inventory ~416
Mint the canonical, vendor-neutral address (cell64) for a real-world place: the shared spatial identity every agent resolves to identically, so two models refer to the same ground instead of two descriptions of it. Also returns the topic-grouped inventory of bands and algorithms recallable there. For a first-class OBJECT identity (a bridge, a plot, a named place) rather than a raw cell, use emem_entity. When to use: Use whenever the input refers to a real-world location and the next step needs the cell64 identifier or wants to know which bands are available before recalling. The response carries `data_at_this_cell` with three sub-fields: `live_bands_by_topic` (every band recallable here, grouped by topic such as flood_water_event_window, vegetation_condition, built_up_human_geography), `algorithms_for_topic` (composition recipes that fuse those bands into named scores), and `declared_but_no_materializer_at_this_responder` (cube slots reserved without a live connector). For the single-shot path that runs the full chain server-side and returns one packaged answer, use `emem_ask` instead. Example arguments: {"place":"Mount Everest"}
| Name | Type | Req | Description |
|---|---|---|---|
| lat | number | — | WGS-84 latitude in degrees, paired with `lng`. REQUIRED with `lng` unless `place`/`q` is provided. |
| lng | number | — | WGS-84 longitude in degrees, paired with `lat`. REQUIRED with `lat` unless `place`/`q` is provided. |
| place | string | — | Free-text place name (e.g. 'Mount Everest', 'Tokyo'). REQUIRED unless `lat`+`lng` is provided. Aliases also accepted: `q`, `query`, `name`. |
| q | string | — | Alias for `place`, accepted because OSM/Mapbox/Google Geocoding all use `q`. Provide either this or `place` (or `lat`+`lng`). |
No output schema declared.
No examples provided.
emem_log_consistency Transparency log consistency proof ~154
Return an RFC 6962 consistency proof that the tree of size `first` is an append-only prefix of size `second` (defaults to the current size). This is the append-only guarantee: it catches a responder that rewrites or forks history. When to use: Call with `first` = the tree_size of an STH you pinned earlier. Verify the returned proof offline against that STH's root; if the first_root does not match what you pinned, the log rewrote history. Example arguments: {"first":1000}
| Name | Type | Req | Description |
|---|---|---|---|
| first | integer | yes | Earlier tree size (the STH you pinned). |
| second | integer | — | Later tree size. Defaults to the current tree size. |
No output schema declared.
No examples provided.
emem_log_inclusion Transparency log inclusion proof ~167
Return an RFC 6962 inclusion (audit) proof that a log entry is committed under the current signed tree head. Verify offline: the audit path re-derives the STH root from the entry's leaf hash. When to use: Call to prove a specific log entry is in the log. Pass `leaf_index` (0-based position) or `entry_hash` (base32 of the record's blake3). Returns the audit path plus the STH to check it against. Example arguments: {"leaf_index":0}
| Name | Type | Req | Description |
|---|---|---|---|
| entry_hash | string | — | Alternative to leaf_index: base32-nopad of the record's 32-byte blake3. |
| leaf_index | integer | — | Zero-based position of the entry in the append-only log. |
No output schema declared.
No examples provided.
emem_log_sth Transparency log signed tree head ~126
Fetch the responder-signed tree head (STH) over the whole append-only attestation log: {tree_size, root_b32, signed_at, responder_pubkey_b32, signature_b32}. The signature is ed25519 over a domain-separated preimage, verifiable offline. When to use: Call to pin a cryptographic commitment to the log's current state. Save the STH, then later call emem_log_consistency to prove the log only grew (append-only), a mismatch means the responder rewrote history. No arguments. Example arguments: {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
emem_log_witnesses Transparency log witness co-signatures ~172
List witness co-signatures recorded for tree heads, independent parties that counter-signed a (tree_size, root) claim under their own ed25519 key. Co-signatures let a client detect split-view equivocation. Empty until witnesses submit (submission is a signed write, done off-MCP via POST /v1/log/witness). When to use: Call to see who has independently vouched for the log's history. For each co-signature, verify it offline, then call emem_log_consistency from that witness's tree_size to the current size to confirm the log the witness saw is a prefix of the log you see. Optional `tree_size` filter. Example arguments: {}
| Name | Type | Req | Description |
|---|---|---|---|
| tree_size | integer | — | Optional filter: only co-signatures recorded at this tree size. |
No output schema declared.
No examples provided.
emem_lst Land surface temperature (MODIS day + night) ~341
Recall the signed MODIS land surface temperature facts (day-8day + night-8day composites, 1 km native) at a place's cell64, attesting on a miss; each carries a citeable fact_cid. When to use: Use when the user asks about surface heat, urban heat island, thermal anomalies, or wants day/night LST. Returns both fluxes so the agent can derive day–night spread. Example arguments: {"place":"Phoenix, AZ"}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Optional single band override, replaces the endpoint's default band set with this one. |
| bands | string | — | Optional CSV of band keys, replaces the endpoint's default band set. |
| include | array | — | Opt-in heavy response sections. Default response omits per-cell arrays to stay under MCP's 25 KB cap. Name specific sections to include them. |
| lat | number | — | WGS-84 latitude. Paired with `lng`. Use when you already have coordinates. |
| lng | number | — | WGS-84 longitude. Paired with `lat`. |
| n_cells | integer | — | Polygon fan-out width. `n_cells: 1` = point at centroid. Defaults vary per endpoint (1 for /v1/at, 16 for single-band endpoints). |
| place | string | — | Free-text place name. Resolved through the standard /v1/locate cascade (wide-bbox → embedded → GeoNames → cache → Photon → Nominatim). Provide this OR `lat`+`lng`. |
| tslot | integer | — | Optional tslot offset (band-tempo-relative). |
No output schema declared.
No examples provided.
emem_manifests Active manifest CIDs ~56
Active manifest CIDs (bands / functions / sources / schema). When to use: Call to learn which exact registry versions a responder is serving. Cite these CIDs alongside any answer where reproducibility matters. Example arguments: {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
emem_materializers Auto-fetch registry (per-band materializers) ~216
Auto-fetch registry: which bands the responder will materialize on a recall miss, the upstream provider, license, value shape, and history bounds. When to use: Call once at session start (alongside `emem_bands` and `emem_coverage_matrix`) to learn which bands answer for ANY cell on Earth without seeding. Each entry declares `upstream_scheme`, `upstream_endpoint`, `derivation_fn_key`, `value_kind` (primary | absence | primary_or_absence), `coverage` (where the upstream has data), `unit`, `tempo`, `confidence`, and `history_available_from` / `history_available_to` (when the upstream supports historical fetch via `emem_backfill`). Use this when the user asks 'do you have flood data here', 'what providers feed this', or you need license attribution. The response also carries an `agent_hint` block explaining the trust model (responder signs, not upstream) and the absence-fact contract. Example arguments: {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
emem_memory_bundle Compose a signed multi-fact memory bundle ~409
Compose N (cell, band, tslot?) triples into ONE signed envelope. Each triple runs through the standard auto-materialize recall path; the resulting fact_cids are bundled into a content-addressed envelope and the responder signs over the full receipt. The composed `bundle_token` is `emem:bundle:<bundle_cid>`, a single rebindable string that cites the whole set. Algebra: merge. When to use: Call when the agent wants to cite multiple (place, band, vintage) facts as one handle. The bundle stays verifiable offline via /v1/verify_receipt (the receipt covers all cited fact_cids and cells). Use this instead of N separate `emem_memory_token` composers when the citation is conceptually one thing (e.g. "the EUDR-relevant baseline for these 8 plots at 2020-12-31"). Caps at 256 triples per call, and the response reports `members` and `resolved` so a bundle that only partly resolved is visible without walking every citation. Example arguments: {"triples":[{"cell":"defi.zb4d9.pefa.zf619","band":"copdem30m.elevation_mean"},{"cell":"defi.zb493.xoso.zcb6a","band":"indices.ndvi"}],"purpose":"audit baseline 2026"}
| Name | Type | Req | Description |
|---|---|---|---|
| purpose | string | — | Optional human-readable purpose string. Included in the bundle_cid preimage so the same triples + different purposes produce distinct CIDs. |
| triples | array | yes | One to 256 (cell, band, tslot?) triples to bundle. Each entry is recalled through the standard auto-materialize path; the bundle envelope cites every resulting fact_cid. 257 or more is a typed 400: t… |
No output schema declared.
No examples provided.
emem_memory_bundle_resolve Dereference a memory_bundle token ~193
Parse a `emem:bundle:<bundle_cid>` token and return the signed bundle envelope: every citation (cell, band, resolved_tslot, fact_cid, memory_token), the receipt, the responder pubkey, and the deduped flat cells[] / fact_cids[] arrays. Returns 404 with a typed code when the responder does not hold the bundle. When to use: Call when an agent receives an `emem:bundle:` token from another agent (or earlier turn) and wants the underlying signed citation set. The response is byte-identical to what `emem_memory_bundle` returned at the original responder. Example arguments: {"token":"emem:bundle:wbqyxljmeewr7z4cav7g"}
| Name | Type | Req | Description |
|---|---|---|---|
| token | string | yes | A `emem:bundle:<bundle_cid>` rebindable handle to dereference. |
No output schema declared.
No examples provided.
emem_memory_contradictions Scan for multi-attester disagreement ~465
Surface where the corpus DISAGREES with itself (algebra: competing evidence). When two or more independent sources signed different values for the same place + band + time, this returns that disagreement with a 0–1 severity score and citations to every disputed fact, instead of silently picking one value and hiding the conflict. The opposite of a confident single answer: it tells you when not to trust one. When to use: Call this when trust matters before you rely on a number, 'is there disagreement about X', 'do the sources corroborate this', 'audit this claim', or 'find contradictory observations in region Y'. Use it to decide whether a fact is well-corroborated or contested. Narrow with `cell_prefix` (e.g. "defi.zb5") for a region and `band` for one family; `min_severity` filters out trivial differences. Severity is per band kind: scalar = spread over the band's range, vector = 1 − mean cosine, categorical = 1 − mode share. The receipt cites every disputed CID, follow up with `emem_diff` to quantify a pair, or (with the refinement loop on) read the emitted `disagrees_with` edge via `emem_edges_recall`. Example arguments: {"cell_prefix":"damO","band":"indices.ndvi","min_severity":0.2}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Band key filter (e.g. `indices.ndvi`). Omit to include all bands. |
| cell_prefix | string | — | Bytewise prefix on cell64 (e.g. `defi.zb5f9`). Omit to scan the whole corpus up to the scan cap. |
| limit | integer | — | Max contradictions to return. |
| min_severity | number | — | Severity floor in [0, 1]. 0 = report every disagreement, 1 = only flagrant. Severity scoring is per band kind: scalar (max-min over band range), vector (1 - mean cosine), categorical (1 - mode share). |
| window_unix_s | array | — | [lo, hi] inclusive Unix-seconds filter on attestations' signed_at, all disagreeing attestations must fall in the window. |
No output schema declared.
No examples provided.
emem_memory_search emem_memory_search, semantic search over /memories/* files ~743
Semantic search over /memories/* file contents using BGE-base-en-v1.5 (768-D, L2-normalised) backed by a Lance partition (`memory_text_index_d768.lance`). Matches paraphrases, "rainfall in March" finds "precipitation observed in spring" without an exact substring match. Returns ranked hits with similarity in [0,1], 200-char snippets around the best-matching chunk, and the signing receipt's path / file_cid / signed_at / attester_pubkey_b32 fields. Filters: `kind`, `path_prefix`, `attester_pubkey_b32`. SCOPE: this searches EVERY caller's files, not just your own, because memory on this responder is a shared world-readable commons; narrow with `attester_pubkey_b32` or `path_prefix` if you want only your own. Entries written with `kind: vault` are AEAD-sealed and are never indexed, so they never appear in results. Falls back to a brute-force scan (slower but correct) when the index is empty or `EMEM_DISABLE_LANCE=1` is set; the `via` field of the response reports which path was taken. When to use: Call instead of paging through `memory_view` whenever the agent knows roughly what it wants (a topic, a name, a paraphrase) but not the exact file path. Pair with `memory_view` for the full body once you've narrowed down the candidate, `emem_memory_search` returns a 200-char snippet, not the whole file. The polling indexer hydrates once per minute (configurable via `EMEM_MEMORY_SEARCH_POLL_SECS`), so a file created in the same turn may briefly miss the fast-path, the brute-force fallback still catches it. KNOWN LIMIT, measured rather than assumed: this is dense embedding similarity, and it FAILS on corpora whose entries differ only in numbers or coordinates. In a benchmark over such a corpus dense retrieval recovered the right entry 0-16.7% of the time while lexical BM25 over the identical text recovered it 100% of the time, because a coordinate is a rare literal string that cosine similarity flattens and token overlap keys on. If your memories are numeric or near-identical…
| Name | Type | Req | Description |
|---|---|---|---|
| attester_pubkey_b32 | string | — | Optional filter: only files attested by this signer (base32-nopad-lowercase pubkey). |
| k | integer | — | Number of hits to return. |
| kind | string | — | Optional filter: only files whose typing taxonomy entry matches (defaults to `resource` until Agent W's typing lands). |
| mode | string | — | Retriever. `dense` (default) is BGE embedding similarity. `lexical` is BM25 over the same corpus: it needs NO model, so it answers where the embedder is not installed, and it is the correct choice wh… |
| path_prefix | string | — | Optional filter: only files whose path starts with this prefix (e.g. `/memories/journal/`). |
| q | string | yes | Free-text query. Semantic, matches paraphrases not just substrings. |
No output schema declared.
No examples provided.
emem_memory_token Compose a memory_token citation handle ~466
Mint a citation handle, `emem:fact:<cell64>:<fact_cid>` (or `:<state_cid>`), that any agent or LLM resolves to the byte-identical signed object. The antidote to referential drift on the value side: hand this one string to another agent instead of re-describing the fact. Validates both components are non-empty and free of the `:` separator. Algebra: cite. When to use: Call when the agent wants a single rebindable string to cite a place plus an attested fact across messages, threads, agents, or tools, without re-fetching or re-describing it. Pair with `emem_verify_receipt` on the receiving end to check the signed payload. To cite an OBJECT rather than a single reading, use emem_entity's `emem:entity:` token. FOR MANY FACTS, USE emem_memory_bundle INSTEAD, and this is a measured cost rather than a style preference: a token is ~104 characters while the signed value it points at averages ~18, so N individual tokens cost roughly 5.8x the context of simply pasting the N numbers, and an N-token prompt hits the context wall SOONER than the plain values would. A bundle is 38 characters at ANY N up to 256 and resolves in one round trip. Individual tokens are for citing ONE fact you must be able to verify later; they are the wrong tool for carrying a set. Example arguments: {"cell":"defi.zb493.xoso.zcb6a","fact_cid":"cxjiu7l54ujzrpnekp24n4534yojpue4mprddbvevnqtti3lh5bq"}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Optional band key. When set, the minted citation carries the band's tamper-provenance block (class, deterministic, tamper_evidence, trust_rank) so the receiving agent sees the trust class without a r… |
| cell | string | yes | cell64, neither component may contain `:`. |
| fact_cid | string | yes | 52-char base32-nopad-lowercase content-id of the fact (full 32-byte blake3). |
No output schema declared.
No examples provided.
emem_memory_token_resolve Dereference a memory_token in one round-trip ~243
Parse a `emem:fact:<cell64>:<fact_cid>` citation handle and return the signed fact body the cid binds. Saves the agent from string-splitting the token and chaining `GET /v1/facts/<cid>` manually. Algebra: resolve. When to use: Call when an agent receives a memory_token from another agent (or out of a previous turn) and wants the underlying signed bytes. The response carries the parsed cell + fact_cid, the full fact body, and the stable `fact_url` an agent can hand to any other peer. 404 with a typed code if the responder doesn't hold the cid; try /v1/fetch with the cid then, or paste the token at a mirror. Example arguments: {"token":"emem:fact:defi.zb493.xoso.zcb6a:cxjiu7l54ujzrpnekp24n4534yojpue4mprddbvevnqtti3lh5bq"}
| Name | Type | Req | Description |
|---|---|---|---|
| token | string | yes | A `emem:fact:<cell64>:<fact_cid>` citation handle to dereference. |
No output schema declared.
No examples provided.
emem_ndvi NDVI at a place (one-shot, polygon-aware) ~380
Recall the signed Sentinel-2 NDVI fact (indices.ndvi, 10 m native) at a place's canonical cell64, attesting it into the shared memory on a miss. Composes locate → cell64 → recall in one call; the value returns with its citeable fact_cid. When to use: Use when the user names a place (or lat/lng) and just wants the NDVI number. Polygon-resolved places default to a 16-cell fan-out aggregated as mean/median. Set `n_cells: 1` for point behaviour. For multi-band batches use emem_recall. Example arguments: {"place":"Yellowstone National Park"}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Optional single band override, replaces the endpoint's default band set with this one. |
| bands | string | — | Optional CSV of band keys, replaces the endpoint's default band set. |
| include | array | — | Opt-in heavy response sections. Default response omits per-cell arrays to stay under MCP's 25 KB cap. Name specific sections to include them. |
| lat | number | — | WGS-84 latitude. Paired with `lng`. Use when you already have coordinates. |
| lng | number | — | WGS-84 longitude. Paired with `lat`. |
| n_cells | integer | — | Polygon fan-out width. `n_cells: 1` = point at centroid. Defaults vary per endpoint (1 for /v1/at, 16 for single-band endpoints). |
| place | string | — | Free-text place name. Resolved through the standard /v1/locate cascade (wide-bbox → embedded → GeoNames → cache → Photon → Nominatim). Provide this OR `lat`+`lng`. |
| tslot | integer | — | Optional tslot offset (band-tempo-relative). |
No output schema declared.
No examples provided.
emem_neighborhood_consistency Neighbourhood consistency / spatial outlier (GeoTessera vs 8 neighbours) ~220
Score how much a cell looks like its surroundings: consistency = (1/8) Σ cosine(centre, neighbour_i) over the 8 immediate cell64 neighbours, plus outlier_score = 1 − consistency. High consistency = the cell blends in (Tobler's First Law); high outlier_score = it stands out, an edge, a fresh clearing, a built patch in farmland. CPU-only GeoTessera embeddings. When to use: Call to flag a cell that is anomalous versus its local neighbourhood (change/edge detection, QA of a homogeneous expectation, scouting for the odd-one-out). Signed `inconclusive` when neither the centre nor any neighbour carried an embedding. For year-over-year change at one cell use `emem_state_diff` or `emem_triple_consensus`. Example arguments: {"cell":"defi.zb493.xoso.zcb6a"}
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | Target cell64 or place name. Scored against its 8 immediate cell64 neighbours. |
No output schema declared.
No examples provided.
emem_query_region Aggregate facts over a region ~374
Query facts over a region (single cell or list of cells), optionally aggregated per band. A bbox is SAMPLED, not enumerated: the sampler walks addresses inside the box and returns only the ones already materialized, so at any human-sized region (a district, a city) it commonly returns an empty aggregate even when a warm cell sits inside the box. That is the sampler being honest, not a miss. Measured: a 0.30 x 0.25 degree bbox containing a cell with 14 signed NDVI facts returned zero; a 0.0009 degree bbox around the same centre returned 100 cells sampled and 5 fact_cids. Read `n_cells_queried` against `n_cells_returned` to tell "nothing is there" from "the sample missed it", and tighten the box or pass an explicit cell list when you need coverage rather than a sample. When to use: Call when the user asks 'how does region X look', 'what's the average NDVI here', or wants a region-level summary. Use `agg=mean|median|p90|vector_centroid` to fold per-band values. Example arguments: {"geometry":"cells:damO.zb000.xUti.zde78,damO.zb000.xUto.sisA","agg":"mean"}
| Name | Type | Req | Description |
|---|---|---|---|
| agg | string | — | optional per-band aggregation |
| as_of_signed_at | string | — | Bi-temporal transaction-time bound (RFC 3339). |
| as_of_tslot | integer | — | Bi-temporal valid-time bound, applied per cell across the region. See emem_recall for semantics. |
| bands | array | — | — |
| geometry | string | yes | cell64 string, or 'cells:c1,c2,c3' |
No output schema declared.
No examples provided.
emem_raster_bundle Raster bundle: bind N field tokens into one citeable manifest ~521
Mint an emem:rasterset: token: a signed manifest binding 2..64 already-minted emem:raster: field tokens (any mix of band_raster / s2_median_composite / dem_raster / embedding_raster) into ONE citeable thing. The composition primitive a world model or a compliance report needs when it must cite one token that points at every signed layer at once - the RGB ground composites, the DEM geometry, the encoder embedding field - so the report points at the world and the world points back at each signed layer. Unlike emem_band_cube (which MINTS members by fanning one band across dates), this BUNDLES existing tokens across bands and types: it is the raster analogue of a memory bundle and the cross-band analogue of a cube. It mints no new pixels - each member resolves and re-derives on its own, and the bundle's lineage terminates in each member's own derivation. bundle_cid = blake3 of the ordered member derivation cids (plus purpose), so the same ordered set always names the same bundle; resolve recomputes it and refuses an altered or forged membership. A member that is not a live raster-shaped derivation fails the whole mint by name. This signs and persists the manifest. When to use: Call when you have several minted emem:raster: tokens (a world's ground, geometry, and embedding layers) and want ONE token the report or world card cites. For one field use emem_band_raster; for one band over time use emem_band_cube; to bundle per-cell FACTS (not fields) use emem_memory_bundle. Resolve a received bundle with emem_raster_bundle_resolve. Example arguments: {"tokens":["emem:raster:<aoi>:s2.B04:20509:<dcid1>","emem:raster:<aoi>:s2.B03:20509:<dcid2>","emem:raster:<aoi>:s2.B02:20509:<dcid3>"],"purpose":"world_soubre RGB ground"}
| Name | Type | Req | Description |
|---|---|---|---|
| purpose | string | — | Optional human-readable purpose, folded into bundle_cid so the same members under a different purpose get a distinct bundle. |
| tokens | array | yes | 2 to 64 already-minted emem:raster: field tokens (any mix of band_raster / s2_median_composite / dem_raster / embedding_raster), bound in the order given. |
No output schema declared.
No examples provided.
emem_raster_bundle_resolve Dereference an emem:rasterset: bundle token ~254
Resolve emem:rasterset:<bundle_cid>:<derivation_cid> back to its signed manifest and verify it. Fail-closed like every field-token resolve: the cid must be a raster_bundle@1 derivation, bundle_cid is recomputed from the record's ordered members and matched against BOTH the token and the record (any mismatch is a typed 409, refusing an altered or forged membership), and every member emem:raster: token is re-verified as a live raster derivation. Returns the member list with a per-member resolves flag, so a stranger confirms the whole set is intact before trusting the world it names. When to use: Call when you receive an emem:rasterset: token (a world's or DDS's bundle of field layers) and want to verify the membership is intact and every layer still resolves, before you trust or render it. For a single emem:raster: token use emem_raster_resolve. Example arguments: {"token":"emem:rasterset:<bundle_cid>:<derivation_cid>"}
| Name | Type | Req | Description |
|---|---|---|---|
| token | string | yes | emem:rasterset:<bundle_cid>:<derivation_cid> |
No output schema declared.
No examples provided.
emem_raster_resolve Dereference an emem:raster: field token ~465
Resolve emem:raster:<aoi_cid>:<band>:<tslot>:<derivation_cid> back to its signed derivation record and the artifact's status. Every claim in the token binds to the signed record before anything dereferences, the same rule fact tokens follow: the cid must be a band_raster@1 derivation and the token's aoi_cid, band, and tslot must each match the record's own body, so a real derivation_cid cannot be passed off under a false area, band, or date (mismatch is a typed 409). The response carries the full record (scene pin, grid georeferencing, anchors) and the artifact url; bytes come from GET /v1/artifacts/{cid}, immutable. An evicted artifact is not an error: the record pins the rebuild, and calling emem_band_raster with the record's own bbox, band, and capture date re-derives identical bytes. The receipt binds (aoi_cid, derivation_cid) through the FIELD preimage segment. When to use: Call when you receive an emem:raster: token from another agent and want the verified field behind it: first this, to get the bound record and artifact url, then fetch the bytes and re-hash them against artifact_cid for the spot-check tier of verification. For emem:fact: tokens use emem_memory_token_resolve. Example arguments: {"token":"emem:raster:<aoi_cid>:s2.B04:20650:<derivation_cid>"}
| Name | Type | Req | Description |
|---|---|---|---|
| spot_check | boolean | — | Opt-in anchors spot-check (the field-token verification tier). When true, decode the artifact grid, read each anchor's value back out at its (row,col), and cross-check it against the independently-si… |
| token | string | yes | emem:raster:<aoi_cid>:<band>:<tslot>:<derivation_cid> |
No output schema declared.
No examples provided.
emem_reason Compose a prose answer over signed facts (LLM, labelled) ~252
The opt-in reasoning tier: grounds your question through emem_ask (deterministic, signed), then has the responder's local model compose a prose answer over that envelope. The prose is model_output and signed:false by construction, it is never evidence; the grounding block beside it (fact_cids + receipt) is. Runs the model greedily (temperature 0) with a single-flight lock, so a cold load never fans out. For anything a signed envelope already answers, use emem_ask instead and skip the model entirely. When to use: Reach for this only when the question needs prose composition across several facts and the caller explicitly wants a model in the loop, an A2A peer sending metadata.mode="reasoning", or a human asking for a narrative. Everything it says is bounded by the signed grounding it returns beside the prose; if the envelope cannot support an answer the model must abstain. Prefer emem_ask (no language model, signed) for every factual readout. Example arguments: {"q":"how has vegetation around Nashik changed this season, and what should a grower do?"}
| Name | Type | Req | Description |
|---|---|---|---|
| q | string | yes | The plain-language question to reason about. |
No output schema declared.
No examples provided.
emem_recall Recall facts at a cell (auto-materializes on miss) ~1,065
Read the signed facts at a canonical address (cell64); auto-materializes on a miss for any band with a registered materializer. A fact_cid names one signed attestation, so a recalled fact is citeable and re-verifiable rather than a paraphrase: resolving it anywhere returns those exact bytes. It is NOT a fingerprint of the observation. The digest covers the responder's key and the moment it signed, so two responders that measure the same thing mint different fact_cids and a cid resolves only at the responder that signed it; use emem_entity for identity that crosses responders. Pass `deterministic:true` (or a `provenance` class list) to keep only facts recomputable from the cited raw source, with no model or human in the loop. In the memory algebra this is ensure(cell, bands), not get: state what must exist and the responder reuses or materializes. When to use: Call after `emem_locate` (or with a known cell64). Returns every Primary fact stored at that (cell, band, tslot). IMPORTANT: if the cell has no fact yet for a requested band AND that band has `has_materializer=true` (per `emem_coverage_matrix` / `emem_materializers`), the responder fetches the upstream value, signs it under its identity, persists it, and returns it in the same response (slower on the first call while the upstream is fetched; fast once cached). So for any wired band you can recall ANY cell on Earth without seeding, just pass `bands: [<band>]`. The response carries `materialize_notes` listing what was just fetched. Empty result with no notes means the band has no materializer at this responder. Example arguments: {"cell":"damO.zb000.xUti.zde78","bands":["weather.temperature_2m","copdem30m.elevation_mean"]}
| Name | Type | Req | Description |
|---|---|---|---|
| as_of_signed_at | string | — | Bi-temporal transaction-time bound. RFC 3339 string. Returns only facts whose `signed_at` ≤ as_of_signed_at, answers `what did emem KNOW as of system-date Y`. Malformed strings are rejected with code… |
| as_of_tslot | integer | — | Bi-temporal valid-time bound. Returns the latest fact per (cell,band) whose tslot ≤ as_of_tslot, answers `what did this place look like AS OF date X`. Conflicts with an explicit `tslot` when as_of_ts… |
| band | string | — | optional single band key, convenience alias for bands:[band]. Use when you want exactly one band (e.g. 'geotessera.2020', 'modis.ndvi_mean') and would otherwise have to wrap it in an array. Both `ban… |
| bands | array | — | optional band keys to filter, e.g. ['indices.ndvi','geotessera'] |
| cell | string | yes | cell64 string, e.g. 'damO.zb000.xUti.zde78' |
| deterministic | boolean | — | Sugar over `provenance`: true keeps only facts any third party can recompute from the cited raw source (direct_sensor + deterministic_index); false keeps the rest (attested_execution + model_output +… |
| include | array | — | Opt-in response expansion. include:['freshness'] attaches an advisory per-fact freshness block: a Q(Δt) staleness score from the band's physics decay kernel (the same one /v1/temporal_route ranks ban… |
| provenance | array | — | Tamper-provenance filter: return only facts whose band's provenance class is in this list. `attested_execution` is a device reading trusted through its verified OS execution trace and platform attest… |
| scope | object | — | Optional multi-tenant scope {user_id, agent_id, run_id, org_id}. When at least one field is set, the recall is FILTERED to facts written under the same four-tuple (a recall scoped to {user_id:'u1'} s… |
| tslot | integer | — | optional time slot (band-tempo-relative integer offset from emem epoch) |
No output schema declared.
No examples provided.
emem_recall_many Bulk recall across up to 256 cells ~380
Recall facts across a list of up to 256 cell64 strings in one round-trip. Server fans out per-cell recalls in parallel and returns them under `by_cell.<cell64>`. NOT one signed envelope: there is no aggregate receipt, and each cell carries its own under `by_cell.<cell>.receipt`, so verifying one cell verifies that cell only. Audit a bulk call by verifying each cell's receipt independently. When to use: Use after emem_find_similar (give it the neighbour cells), after emem_recall_polygon (when you want a deterministic cell list rather than a polygon), or whenever you have a precomputed set of cells (e.g. an admin-2 sample frame) and want one round-trip. Pass `cells: [c1, c2, ...]` plus the same `bands` shape as emem_recall. For more than 256 cells, batch the call. Example arguments: {"cells":["damO.zb000.xUti.zde78","damO.zb000.xUto.sisA"],"bands":["indices.ndvi","copdem30m.elevation_mean"]}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Optional single band override (alias for bands:[band]). |
| bands | array | — | Optional band filter, same shape as emem_recall.bands. |
| budget_ms | integer | — | Optional soft materialization budget in ms; on expiry the response is a partial 200 with converged false, a typed pending[] and a retry hint. The identical call retried returns strictly more from cac… |
| cells | array | yes | List of cell64 strings, max 256. Each cell is recalled in parallel and the responses are merged into a single signed envelope. |
| tslot | integer | — | Optional tslot offset. |
No output schema declared.
No examples provided.
emem_recall_polygon Recall facts across a place's polygon ~754
Recall facts across every cell inside a place's polygon (single signed envelope). Closes the place-name-drift gap for wide features (parks, lakes, regions). When to use: Call when the user names a wide feature (national park, river basin, country, large urban area) where one cell is too small. Pass `place` and the geocoder will fan out across the polygon, or pass `polygon_bbox` directly if you have coordinates. Returns `merged_facts`, `by_cell`, and a `polygon_bbox.source` indicator (`nominatim_boundingbox` = real polygon, `centre_cell_bbox` = fallback to one cell because the geocoder had no polygon). For *farm* queries the OSM polygon is the whole estate envelope; pass `include: ["ftw_fields"]` to additionally attach per-field agricultural-boundary polygons from Fields of The World (CC-BY-4.0), or call the dedicated `emem_field_boundaries` for the pure-fetch shape. Example arguments: {"place":"Yellowstone National Park","bands":["copdem30m.elevation_mean"],"max_cells":8}
| Name | Type | Req | Description |
|---|---|---|---|
| as_of_signed_at | string | — | Bi-temporal transaction-time bound (RFC 3339). |
| as_of_tslot | integer | — | Bi-temporal valid-time bound, forwarded to every per-cell recall in the fan-out. |
| bands | array | — | Bands to recall at each fan-out cell. |
| budget_ms | integer | — | Optional soft materialization budget in ms. On expiry the response is a partial 200: converged false, a typed pending[] naming each cell and its remedy, and a retry hint; the identical call retried r… |
| compact_offset | integer | — | Pagination offset into cells_compact (compact projection only). Start at 0, then pass the response's compact_page.next_offset until it is null to read every cell in budget-fitting pages. |
| include | array | — | Optional supplements attached to the response. `ftw_fields` adds per-field agricultural-boundary polygons from Fields of The World (https://fieldsofthe.world, CC-BY-4.0) for the resolved polygon bbox… |
| max_cells | integer | — | Cap on cells sampled from the polygon (hard max 1024, raised May 2026; default 64). With projection:compact a full page of that many cells fits the MCP wire budget. |
| place | string | — | Free-text place name; resolved through the layered geocoder. REQUIRED unless `polygon_bbox` is provided. |
| polygon_bbox | object | — | Explicit polygon bbox; alternative to `place` when caller already has coordinates. REQUIRED unless `place` is provided. |
| projection | string | — | Response shape. `full` (default) returns by_cell + merged_facts with per-fact prose. `compact` returns instead a lean cells_compact array, one row per (cell,band) primary fact {cell,lat(5dp),lng(5dp)… |
| tslot | integer | — | — |
No output schema declared.
No examples provided.
emem_region_similarity Region similarity, cosine of two regions' mean GeoTessera embeddings ~281
Answer 'how alike are these two places?' Mean-pool the 128-D GeoTessera embedding across each region's cells to get a centroid, then return the cosine similarity in [-1,1] (+1 = identical landscape, 0 = unrelated). Each region is {place} | {polygon_bbox} | {cells}. CPU-fetched embeddings, no GPU sidecar needed. Surfaces how many cells in each region actually carried a vector (coverage). When to use: Call to compare two areas at the level of overall land character (e.g. 'is this valley like that one?', 'find me somewhere that looks like X'). Degrades to a signed `inconclusive` (no number) when a region has no embedding-covered cells. For a single cell-to-cell vector cosine use `emem_compare`; for k-NN retrieval use `emem_find_similar`. Example arguments: {"region_a":{"place":"Napa Valley"},"region_b":{"place":"Barossa Valley"}}
| Name | Type | Req | Description |
|---|---|---|---|
| max_cells | integer | — | Per-region cell cap. |
| region_a | object | yes | First region: {place} | {polygon_bbox:{min_lat,max_lat,min_lng,max_lng}} | {cells:[cell64,...]}. |
| region_b | object | yes | Second region, same shape as region_a. |
No output schema declared.
No examples provided.
emem_rice_ch4 Rice-paddy methane (IPCC 2019 Tier 2, Eq 5.1) ~575
Estimate seasonal CH4 emissions from rice cultivation per IPCC 2019 Refinement Eq 5.1: integrate the daily emission factor over the cultivation period with water-regime scaling (SFp pre-season, SFo organic amendment) and an optional Yan-2005 Q10 temperature modifier. `cultivation_period_days` and the regional `efc_kg_ch4_ha_day` (Table 5.11) are REQUIRED, the endpoint refuses to guess a global default because the regional EFc drives the magnitude (~30% bias if wrong). An NDWI series (supplied or read from stored `indices.ndwi`) informs the flooding-regime context. When to use: Call for paddy-rice GHG inventory / MRV work where the user needs kg CH4 per hectare for a cultivation season. The caller MUST pick the IPCC region's EFc row (Table 5.11) and the cultivation-period length; pass SFp/SFo when the water regime or organic amendment is known. Surface the seasonal emission, the EFc used, and the scaling factors so the inventory is auditable. For enteric/fertilizer pathways use the dedicated sustainability endpoints. Example arguments: {"cell":"defi.zb493.xoso.zcb6a","cultivation_period_days":120,"efc_kg_ch4_ha_day":1.22}
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | cell64 or place name. |
| cultivation_period_days | number | yes | Cultivation-period length in days (typically 110–150). REQUIRED, IPCC Eq 5.1 integrates the daily EF over this period; no defensible global default. |
| efc_kg_ch4_ha_day | number | yes | Regional baseline EFc (kg CH4/ha/day) from IPCC 2019 Table 5.11. REQUIRED, pick the row for the cell's IPCC region (Asia.S 0.85, Asia.SE 1.22, Europe 1.56, …); the global 1.19 default would bias inve… |
| ndwi_series | array | — | Optional explicit NDWI series across the cultivation period. When omitted the endpoint reads the stored indices.ndwi trajectory. |
| sfo | number | — | Organic-amendment scaling factor SFo (Table 5.14); default 1.00 (no amendment). |
| sfp | number | — | Pre-season water-regime scaling factor SFp (Table 5.13); default 0.68 (non-flooded pre-season > 180 d). |
| t_paddy_c | number | — | Mean paddy-water temperature (°C) for the Yan-2005 Q10 modifier; omit to disable the temperature correction (T_mod = 1). |
No output schema declared.
No examples provided.
emem_sar_forest_disturbance Sentinel-1 SAR forest-disturbance scout (cloud-penetrating) ~382
Cloud- and night-independent Sentinel-1 C-band confirmation of forest disturbance. Intact forest scatters VV strongly + stably (canopy volume scattering); clearing collapses that term so VV backscatter DROPS ~3-5 dB. Samples VV at a baseline-year July-1 anchor and the latest scene, reports `vv_drop_db = baseline − recent` and a `disturbed` flag when the drop ≥ 3 dB (Reiche et al. 2018, RSE 204:147). Both VV reads are signed Primary facts; the response cites both fact_cids. Honest `inconclusive` when either S1 vintage is unavailable. Source: Microsoft Planetary Computer sentinel-1-rtc (anonymous SAS, no requester-pays, no API key). When to use: Call to corroborate or scout forest clearing where cloud blocks the optical products, radar sees through cloud and at night, catching wet-season clearing the annual Hansen/JRC-TMF layers and a single cloudy Sentinel-2 pass miss (the gap RADD was meant to fill). This is an ADDITIVE scout signal, NOT a standalone legal verdict: a VV drop can also be transient (soil moisture, harvest, flood recession), so confirm with the optical consensus (`emem_eudr_dds` or `emem_deforestation_alert`) before crediting a decision. Example arguments: {"cell":"defi.zb493.xoso.zcb6a","baseline_year":2020}
| Name | Type | Req | Description |
|---|---|---|---|
| baseline_year | integer | — | Baseline calendar year the VV drop is measured against (default 2020, the EUDR cut-off year). Baseline VV is sampled at a July-1 anchor of this year; the recent VV is the latest scene. |
| cell | string | yes | cell64 or place name. |
No output schema declared.
No examples provided.
emem_schema Active CDDL/JSON schema bundle ~52
Active CDDL/JSON schema bundle by CID. When to use: Rarely needed at chat time. Useful for offline verification of receipts / attestations against the exact schema version a responder used. Example arguments: {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
emem_soil Soil profile (SoilGrids 0–30 cm: SOC, pH, texture) ~350
Recall the signed SoilGrids 250 m profile at a place's cell64 (SOC, pH, clay/sand/silt fractions, bulk density, nitrogen, all at 0–30 cm depth), attesting on a miss; each band carries a citeable fact_cid. When to use: Use when the user asks about soil quality, agricultural suitability, or carbon stocks at a location. Six bands returned in one envelope. Example arguments: {"place":"Bhanu Pratappur, Chhattisgarh"}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Optional single band override, replaces the endpoint's default band set with this one. |
| bands | string | — | Optional CSV of band keys, replaces the endpoint's default band set. |
| include | array | — | Opt-in heavy response sections. Default response omits per-cell arrays to stay under MCP's 25 KB cap. Name specific sections to include them. |
| lat | number | — | WGS-84 latitude. Paired with `lng`. Use when you already have coordinates. |
| lng | number | — | WGS-84 longitude. Paired with `lat`. |
| n_cells | integer | — | Polygon fan-out width. `n_cells: 1` = point at centroid. Defaults vary per endpoint (1 for /v1/at, 16 for single-band endpoints). |
| place | string | — | Free-text place name. Resolved through the standard /v1/locate cascade (wide-bbox → embedded → GeoNames → cache → Photon → Nominatim). Provide this OR `lat`+`lng`. |
| tslot | integer | — | Optional tslot offset (band-tempo-relative). |
No output schema declared.
No examples provided.
emem_sources Active source-connector registry ~67
Active source-connector registry (URL templates, providers, licenses). When to use: Call when you need to inspect which upstream EO providers are wired (Copernicus DEM, JRC GSW, ESA WorldCover, etc.), useful for license attribution in agent answers. Example arguments: {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
emem_spi Standardized Precipitation Index (McKee 1993) drought metric ~421
Compute the Standardized Precipitation Index (McKee et al. 1993) at a cell: fit a gamma distribution to the same-window precipitation-accumulation history, then standardize the current accumulation to a z-score and map it to a drought class (extreme/severe/moderate drought … normal … wet). Supply `precip_history_mm` + `current_accumulation_mm` directly, or omit them to read the stored `weather.precipitation_mm` trajectory and build the window accumulations server-side. `window_days` selects SPI-1 (30 d), SPI-3 (90 d, default), SPI-12 (360 d), etc. The result is signed; the receipt cites the precipitation fact_cids it read from the shared memory. When to use: Call when the user asks 'is this place in drought', 'how dry is it relative to normal', or wants a precipitation-anomaly z-score. The response is honest: when fewer than the WMO-recommended minimum samples exist it returns verdict=`inconclusive` with `spi:null` and a `honest_note` rather than fabricating a z-score from a handful of points. Quote the `spi`, `spi_class`, and `n_samples`. For raw precipitation use `emem_weather`; SPI is the standardized anomaly. Example arguments: {"cell":"defi.zb493.xoso.zcb6a","window_days":90}
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | cell64 or place name. |
| current_accumulation_mm | number | — | Current-window accumulation (mm); required when precip_history_mm is supplied, else taken as the most-recent window from the stored series. |
| precip_history_mm | array | — | Optional explicit same-window precipitation accumulations (mm). When omitted the endpoint reads the stored weather.precipitation_mm trajectory. |
| window_days | integer | — | Accumulation window (SPI-3 = 90 d default; SPI-1 = 30 d; SPI-12 = 360 d). |
No output schema declared.
No examples provided.
emem_state Read the place's state vector (single encoder OR full 1792-D cube) ~598
Get one dense numeric fingerprint that summarises everything known about a place, ready to feed into similarity search, a classifier, or clustering. Two views: `encoder` returns a single AI-model embedding (128-D Tessera, 1024-D Clay, 1024-D Prithvi); `cube` returns the full 1792-D vector concatenated across every band, with a per-band coverage manifest. When to use: Call this when the user wants a machine-usable summary of a place rather than individual band readings, e.g. 'give me a feature vector for this location', 'how do I represent this place for ML', or before running similarity / linear-probe / clustering downstream. Also use it to get one rebindable handle (`memory_token` / `state_cid`) that cites the whole place. Default `view=encoder` is the cheap single-recall path; pass `view=cube` for the full attested view (its `coverage[]` lets you tell signed-zero from not-yet-materialised). Then hand the vector to `emem_find_similar` (k-NN), `emem_compare` (two-place cosine), or `emem_verify_receipt` (audit the signature). Example arguments: {"cell":"defi.zb493.xoso.zcb6a","view":"cube"}
| Name | Type | Req | Description |
|---|---|---|---|
| as_of_signed_at | string | — | Bi-temporal transaction-time bound (RFC 3339). |
| as_of_tslot | integer | — | Bi-temporal valid-time bound, forwarded to the underlying recall. Lets `/v1/state` answer `what did this place look like as of date X` for both encoder and cube views. |
| cell | string | yes | cell64 OR free-text place name. |
| encoder | string | — | For `view=encoder`: which vector band to read. Defaults to `geotessera`. |
| families | array | — | `view=cube` only. Limit the cube to a subset of band families (e.g. ["foundation","vegetation"]). Slots from other families report `status:"filtered_out"`. |
| include_reserved | boolean | — | `view=cube` only. Include declared-but-inert placeholder slots (`_reserved_128`, `reserved`) in the coverage manifest. Default false. |
| materialize | boolean | — | `view=cube` only. Opt in to FULL auto-materialisation. Default false. The cube view auto-warms geotessera on a cold cell regardless of this flag, so view=cube is never less informative than view=enco… |
| tslot | integer | — | Optional tslot bucket; omit for natural per-band vintages. |
| view | string | — | Default `encoder` (single-band native vector). Pass `cube` for the full 1792-D voxel with coverage manifest, full-fidelity extras, and a humanised `scalars` map. |
No output schema declared.
No examples provided.
emem_state_diff Between-tslot state vector delta (residual + cosine) ~234
Vector delta between the same cell at two tslots: returns the per-element residual, its L2 norm (scalar change-magnitude), the cosine between the two source vectors (orientation drift), and both source fact CIDs so the agent can quote both attestations as evidence. When to use: Call when the user asks 'how much did X change between A and B' for a foundation embedding at one place. Pass `tslot_a` and `tslot_b` (must differ); default `encoder=geotessera`. For per-band scalar change (NDVI delta, elevation delta) use `emem_diff` instead. Example arguments: {"cell":"defi.zb493.xoso.zcb6a","encoder":"geotessera","tslot_a":1672531200,"tslot_b":1704067200}
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | — |
| encoder | string | — | Default `geotessera`. |
| tslot_a | integer | yes | First tslot. |
| tslot_b | integer | yes | Second tslot; must differ from `tslot_a`. |
No output schema declared.
No examples provided.
emem_state_multi Multi-encoder state at one cell (foundation fan-out) ~296
Get the place's fingerprint from several AI models at once (`geotessera`, `clay_v1`, `prithvi_eo2`, `galileo`) in one call, returned as a per-model map. Each model is tried independently; any that can't produce a vector here show up under `missing` with a reason instead of failing the whole request. When to use: Call this when the user wants a second (or third) opinion on what a place looks like, 'do the different models agree this is forest / urban / water?', 'which model has the freshest read here?', or when you want all the embeddings concatenated for a stronger downstream classifier. Use the single-model `emem_state` instead when one embedding is enough. Pass `encoders: [...]` to narrow the set. Example arguments: {"cell":"defi.zb493.xoso.zcb6a"}
| Name | Type | Req | Description |
|---|---|---|---|
| as_of_signed_at | string | — | Bi-temporal transaction-time bound (RFC 3339). |
| as_of_tslot | integer | — | Bi-temporal valid-time bound, forwarded to every per-encoder recall. |
| cell | string | yes | — |
| encoders | array | — | Optional explicit list; defaults to all wired foundation encoders (`geotessera`, `clay_v1`, `prithvi_eo2`, `galileo`). |
| tslot | integer | — | — |
No output schema declared.
No examples provided.
emem_substrates Substrate profile registry ~170
The written admission contract per contributor class (satellite archive, operator constellation, telescope, microscope, CCTV, mobile, drone, robot, industrial machine, fixed sensor): which admission rule applies (recomputable public archive, or complete OS execution trace), which trace layers a device of that class must capture, the measurement grain range, and which profile is the drift anchor. Content-addressed: the response carries the manifest CID every enrollment pins. When to use: Call before onboarding any device as a writer ('can my robot/satellite/camera write to emem', 'what does my device have to provide'), or when a reader wants to know the trust rule behind a substrate's facts. Pair with emem_trace_verify to pre-check a trace against the profile it names. Example arguments: {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
emem_temporal_route Plan a temporal recall recipe for a cell ~341
Turn a time-shaped question into a ready-to-run recall plan: it figures out WHICH bands to pull at WHICH past time windows (e.g. 'the year before the flood', 'last growing season', 'two vintages to compare') so you don't have to compute tslot offsets by hand. Returns the band + lookback + a `purpose` tag for each step. Algebra: valid(M, a): per-band validity from the physics decay kernel, cite_now versus fetch_for_intent. When to use: Call this first when the user's question is about CHANGE OVER TIME or a PAST EVENT and you're not sure which bands/dates to recall, 'was this flooded last year', 'what was the NDVI baseline before the fire', 'compare this place across vintages'. It hands you the recipe; then run those steps with `emem_recall`. Skip it when the user wants a single current reading. Pass `cell` plus an optional free-text `intent` hint. The plan is deterministic and the receipt cites which algorithm supplied each step. Example arguments: {"cell":"damO.zb000.xUti.zde78","intent":"flood_window"}
| Name | Type | Req | Description |
|---|---|---|---|
| bands | array | — | Optional band filter to scope the planner. |
| cell | string | yes | cell64 to plan a temporal recall over. |
| intent | string | — | Optional intent hint, drives recipe selection (e.g. 'flood_window', 'crop_season', 'change_year'). |
| limit | integer | — | Optional cap on recipe entries returned. |
| query_time | integer | — | Optional anchor time (Unix epoch seconds). Defaults to now. |
No output schema declared.
No examples provided.
emem_terrain Terrain triad, slope + ruggedness + topographic position from DEM ~395
Compute three standard DEM terrain indices from one 3×3 Copernicus-DEM (copdem30m.elevation_mean) neighbourhood at a cell: Horn (1981) slope in degrees, Riley (1999) Terrain Ruggedness Index (TRI = sqrt(Σ(Z_centre−Z_i)²)), and Weiss (2001) Topographic Position Index (TPI = Z_centre − mean(neighbours); positive = ridge, negative = valley). The 8 neighbour cell64s are derived by perturbing the cell's lat/lng one cell pitch per axis; the east-west ground spacing is cos(lat)-corrected. Each result is signed; the receipt cites the elevation fact_cids read from the shared memory. When to use: Call when the user asks how steep / how rugged / ridge-or-valley a place is, for siting (solar, construction, agriculture), erosion/landslide screening, or habitat-heterogeneity inputs. Slope and TRI need the full 8-neighbour ring; TPI degrades to ≥1 neighbour. Copernicus DEM is bathymetry-free, so ocean cells return a signed `inconclusive` rather than a fabricated slope, read each index's own `verdict`. For raw elevation use `emem_elevation`. Example arguments: {"cell":"defi.zb493.xoso.zcb6a"}
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | cell64 or place name. The 8 neighbour cell64s are derived by perturbing the decoded lat/lng step_cells pitches per axis. |
| step_cells | integer | — | Stencil step in cell64 pitches (default 3 ≈ 28.7 m, matching the ~30 m Copernicus DEM native resolution). step_cells=1 samples below the DEM resolution and reads flat inside one source pixel; raise i… |
No output schema declared.
No examples provided.
emem_tools What tools exist here, and when to reach for each ~545
The map of emem's tool surface, and the only tool you need to find the rest. Returns the working loop in the order you walk it (name a thing, ground it, cite it, resolve it, verify it, check for drift), then every other tool grouped by the question it answers, each with its one-line trigger. Pass `name` to get one tool's full input schema and a runnable example, so you can use a tool without loading all of the descriptors into context. This endpoint advertises the core loop only; the Earth-observation, search, embedding and log tools are catalogued here and remain callable by name. When to use: Call this FIRST when you do not know which emem tool answers the question, or when you need a capability you cannot see in your tool list. This responder advertises a small core loop by default rather than its full catalog, so a tool being absent from your list does not mean it is absent from the server. Pass `q` to search by topic (`ndvi`, `cloud`, `flood`, `verify`), `name` for one tool's exact schema, or no arguments for the whole map. If you want the full catalog registered as callable tools instead, reconnect to the /mcp/full endpoint; for a one-shot answer without picking a primitive at all, use emem_ask. Example arguments: {"q":"ndvi"}
| Name | Type | Req | Description |
|---|---|---|---|
| bundle | string | — | Filter by the job you are doing. Call with no arguments first to see each bundle and its size. |
| category | string | — | Filter to one category. |
| name | string | — | Return the full descriptor for exactly this tool (input schema, runnable example, annotations), e.g. `emem_ndvi`. Use this when you already know the name and want its schema without loading the whole… |
| q | string | — | Free-text filter over tool names, titles and trigger text, e.g. `ndvi`, `cloud`, `flood`, `verify`, `token`. |
| shape | string | — | Filter by what the answer looks like, which is usually the real question. `scalar` is one number at one address; `raster` is a gridded field over an area; `timeseries` is a value per timestep; `vecto… |
| tier | string | — | Which slice to list. Defaults to `all`, so this tool shows the whole surface even when the endpoint advertises only the core loop. |
No output schema declared.
No examples provided.
emem_topics Topic-grouped band + algorithm registry ~214
Topic-grouped registry of every band and algorithm at this responder, plus visual surfaces and the `declared_but_no_materializer_at_this_responder` block (cube slots reserved without a live connector). Single source of truth shared with `/v1/locate`'s `data_at_this_cell` block. When to use: Call when the user's question lives in a topic but they haven't named a specific band, e.g. 'is this place flood-prone' (→ flood_history_long_term + flood_water_event_window) or 'how walkable is this' (→ urban_livability). Returns three blocks: `live_bands_by_topic` (every band you can recall right now), `algorithms_for_topic` (named recipes that compose those bands into derived answers, pair with `emem_algorithms` for the formulas), and `declared_but_no_materializer_at_this_responder` (honest gaps). Browse here BEFORE inventing your own synthesis formula. Example arguments: {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
emem_trace_verify Verify a device's OS execution trace ~308
Stateless verification of an emem.os_trace.v1 record against a substrate profile: schema, device identity, capture window, per-layer coverage, segment digest chain, merkle trace_root, emitted-output binding, and the device's ed25519 signature. Returns the full verdict with every failed check named (chain_broken, missing_layer, output_unbound, signature_invalid, ...), never just a boolean, so a device maker can debug an enrollment offline before writing. When to use: Call while building a device integration ('why was my trace rejected', 'is this trace admissible under robot.fleet.v1'), or to audit the execution evidence behind a fact by resolving its emem:trace: token and re-verifying. Pass `claimed_payload_digest` to additionally check that a specific output is bound inside the trace. Example arguments: {"profile":"robot.fleet.v1","trace":{"schema":"emem.os_trace.v1"}}
| Name | Type | Req | Description |
|---|---|---|---|
| claimed_payload_digest | string | — | Optional payload digest the caller intends to attest; verification additionally checks it is bound among the trace's emitted outputs. |
| profile | string | yes | Substrate profile ID to verify against (e.g. robot.fleet.v1, orbital.satellite.v1). GET /v1/substrates lists the registry. |
| trace | object | yes | The emem.os_trace.v1 record: device identity, chained trace segments, emitted output digests, trace_root, and the device's ed25519 signature. |
No output schema declared.
No examples provided.
emem_trajectory Time series for one (cell, band) ~392
Time series for one (cell, band) over an inclusive [start, end] tslot window. Returns only what's already attested; it does NOT trigger materialization. For historical backfill use `emem_backfill`. When to use: Call when the user asks 'how did X change over time' for a band that already has multiple historical tslots seeded. IMPORTANT differences from `emem_recall`: (1) trajectory does NOT auto-materialize past tslots, it returns only facts that have already been attested at this responder, so for fast-tempo bands like `indices.ndwi` you'll typically see ONE point at the latest tslot until an attester seeds history. (2) tslots are non-negative `u64`; there's no negative-offset 'last 2 years' shorthand. For LONG-TERM history questions ('flooded in last 2 years', 'forest loss since 2020') prefer either (a) a static-tempo summary band that one fact answers, `surface_water.recurrence` covers 1984-2021 in a single signed value, no trajectory needed, or (b) `emem_backfill` to materialize and sign the missing tslots in one call. Example arguments: {"cell":"damO.zb000.xUti.zde78","band":"indices.ndvi","window":[0,12]}
| Name | Type | Req | Description |
|---|---|---|---|
| as_of_signed_at | string | — | Bi-temporal transaction-time bound (RFC 3339). Restricts the series to facts signed at or before this instant. |
| as_of_tslot | integer | — | Bi-temporal valid-time bound. Skips points with tslot > as_of_tslot, effectively clips the window's upper edge. |
| band | string | yes | — |
| cell | string | yes | — |
| window | array | yes | [start_tslot, end_tslot] inclusive |
No output schema declared.
No examples provided.
emem_triple_consensus Clay+Prithvi+Tessera change-consensus ensemble ~620
Three-encoder change ensemble: compute the cosine change between the two most-recent DISTINCT vintages for each of the Clay, Prithvi, and Tessera embeddings at the cell, then vote each encoder's change against `consensus_threshold` (registry default 0.15). Returns each encoder's change magnitude, its vote, and the consensus verdict (how many of the three agree change happened). Two caveats ride every response. First, the gate is NOT calibrated per encoder: 0.15 is a threshold for spectral change, applied unchanged to cosine distances in three embedding spaces with different scales, and the deployed Prithvi checkpoint's change tops out near 0.1155, under the gate. Prithvi therefore never votes, `all_three` is arithmetically unreachable, and `two_of_three` means Clay plus Tessera; read `encoders_used[].change` per encoder instead of the vote, and see the `gate_calibration` field. Second, this tool MATERIALIZES a missing prior vintage, so despite its Read category it signs and persists facts and spends GPU time. Degrades to a signed `inconclusive` when the GPU sidecar is unreachable or a cell lacks two distinct vintages for the encoders. The response carries a machine-readable `degraded` boolean, a `degraded_reason` (closed set: `gpu_sidecar_unavailable`, `single_vintage`, `outside_coverage`, `no_finite_overlap`, `recall_failed`, `partial_consensus_N_of_3`, `insufficient_encoders`), and `degraded_message`; each `encoders_absent[]` entry also carries its own `reason_code`. A 2-of-3 result reports `degraded:true` even though it still carries a real ensemble number. This is an experiment over model outputs: each leg carries a `model_output` caution (learned representation, not a measurement), so corroborate with a deterministic band before load-bearing use. When to use: Call when the user wants a robust, model-agnostic 'did this place change' answer backed by three independent foundation encoders rather than one, e.g. cross-checking a single-encoder alert, or auditing c…
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | cell64 or place name. |
| consensus_threshold | number | — | Override the registry consensus gate (default 0.15); clamped to (0,1). |
No output schema declared.
No examples provided.
emem_verify Verify a structured claim against a cell ~140
Verify a structured claim against a cell's facts. Returns verdict + evidence CIDs + signed receipt. When to use: Call when the user asks a yes/no question about a cell ('is the NDVI > 0.7 here', 'has this been deforested'), or when downstream code wants citable evidence for a logical predicate. Example arguments: {"cell":"damO.zb000.xUti.zde78","claim":{"band":"indices.ndvi","op":"gt","value":0.5,"tslot":0}}
| Name | Type | Req | Description |
|---|---|---|---|
| cell | string | yes | — |
| claim | object | yes | — |
| mode | string | — | — |
No output schema declared.
No examples provided.
emem_verify_receipt Server-side ed25519 receipt verifier ~422
Verify a signed receipt envelope server-side: recomputes the canonical preimage (preimage v1: tagged, length-prefixed segments; receipts without `preimage_version` verify under the legacy `request_id | served_at | primitive | cells, | fact_cids,` concatenation), runs ed25519 over the embedded pubkey + signature, and returns `{valid, reason, pubkey_b32}`. Use when the in-browser /verify path is blocked (CDN offline, agent runtime has no crypto) or when you want a server-side audit of a third-party receipt. Algebra: verify. When to use: Pass a receipt object exactly as returned by any read primitive (signature can be byte[] or sig_b32; pubkey can be byte[] or responder_pubkey_b32, the verifier tolerates both shapes). Optionally override `pubkey_b32` to assert verification against a specific signer. Returns 200 with `valid: false` when the signature fails, never 4xx for a structurally-well-formed bad signature. Example arguments: {"receipt":{"primitive":"recall","served_at":"2026-05-14T12:00:00Z","request_id":"req-1","cells":["damO.zb000.xUti.zde78"],"fact_cids":["qbq2dy7adyuvozs7s3gqg5jnpkcwq2duegltjyhbxsivuqbpjofq"],"signature":[1,2,3],"responder_pubkey":[4,5,6]}}
| Name | Type | Req | Description |
|---|---|---|---|
| pubkey_b32 | string | — | Optional explicit responder pubkey (base32). When omitted, uses the receipt's embedded pubkey/responder fields. |
| receipt | object | yes | The signed receipt envelope (as returned by any read primitive). Must carry primitive/served_at/request_id/cells/fact_cids and either `signature` byte[] + `responder_pubkey` byte[] or their b32 strin… |
No output schema declared.
No examples provided.
emem_water Surface water (JRC GSW recurrence + S1 backscatter) ~352
Recall the signed surface-water facts at a place's cell64: JRC Global Surface Water recurrence (1984–2021) + Sentinel-1 SAR backscatter (current), attested on a miss and citeable by fact_cid. The pair detects standing water through clouds. When to use: Use when the user asks about flooding, wetlands, surface-water dynamics, or wants a robust water-presence check. JRC alone gives historical baseline; Sentinel-1 gives current flood detection. Example arguments: {"place":"Sundarbans"}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Optional single band override, replaces the endpoint's default band set with this one. |
| bands | string | — | Optional CSV of band keys, replaces the endpoint's default band set. |
| include | array | — | Opt-in heavy response sections. Default response omits per-cell arrays to stay under MCP's 25 KB cap. Name specific sections to include them. |
| lat | number | — | WGS-84 latitude. Paired with `lng`. Use when you already have coordinates. |
| lng | number | — | WGS-84 longitude. Paired with `lat`. |
| n_cells | integer | — | Polygon fan-out width. `n_cells: 1` = point at centroid. Defaults vary per endpoint (1 for /v1/at, 16 for single-band endpoints). |
| place | string | — | Free-text place name. Resolved through the standard /v1/locate cascade (wide-bbox → embedded → GeoNames → cache → Photon → Nominatim). Provide this OR `lat`+`lng`. |
| tslot | integer | — | Optional tslot offset (band-tempo-relative). |
No output schema declared.
No examples provided.
emem_wave_solve 1-D shallow-water swell propagation to coast ~369
Forward-step 1-D explicit finite-difference solver for the shallow-water wave equation ∂²u/∂t² = c²∂²u/∂x² with c² = g·h, where depth h comes from `gmrt.topobathy_mean` along the seaward gradient. Models how an offshore swell of height H_s and period T propagates toward `coastal_cell`. Returns a signed forecast of arrival height + time + depth + phase-speed profiles, all under a CFL-stable timestep; the receipt cites the depth facts read from the shared memory. When to use: Use when the user wants to predict swell arrival at a coast (storm-surge planning, shoreline-impact assessment, surf forecasting). The solver walks `n_offshore_cells` cells seaward from `coastal_cell` along the bathymetric gradient (default 8 cells = 80 m of profile at the active 10 m grid), samples GMRT depth at each, and integrates the wave equation forward until the wavefront reaches the coast plus one period. Receipt cites every depth fact CID along the profile. Returns 422 with a clear message if `coastal_cell` is land-locked. Example arguments: {"coastal_cell":"damO.zb000.xUti.zde78","offshore_height_m":2.0,"period_s":8.0}
| Name | Type | Req | Description |
|---|---|---|---|
| coastal_cell | string | yes | cell64 of the coastal destination. |
| n_offshore_cells | integer | — | Cells to sample seaward when building the bathymetric profile. |
| offshore_height_m | number | yes | Offshore significant wave height H_s (m). |
| period_s | number | yes | Wave period (s); typical wind-wave + swell envelope is 6-18 s. |
No output schema declared.
No examples provided.
emem_weather Current weather snapshot (temperature, cloud, precip, wind) ~348
Recall the signed met.no/CAMS weather facts at a place's cell64 (2 m temperature + total cloud cover + precipitation + 10 m wind speed), attesting on a miss; each value carries a citeable fact_cid. When to use: Use when the user names a place and asks 'what's the weather' or wants a now-cast snapshot. weather.* bands are now-only (no backfill); for climatology use terraclimate.*. Example arguments: {"place":"Reykjavik"}
| Name | Type | Req | Description |
|---|---|---|---|
| band | string | — | Optional single band override, replaces the endpoint's default band set with this one. |
| bands | string | — | Optional CSV of band keys, replaces the endpoint's default band set. |
| include | array | — | Opt-in heavy response sections. Default response omits per-cell arrays to stay under MCP's 25 KB cap. Name specific sections to include them. |
| lat | number | — | WGS-84 latitude. Paired with `lng`. Use when you already have coordinates. |
| lng | number | — | WGS-84 longitude. Paired with `lat`. |
| n_cells | integer | — | Polygon fan-out width. `n_cells: 1` = point at centroid. Defaults vary per endpoint (1 for /v1/at, 16 for single-band endpoints). |
| place | string | — | Free-text place name. Resolved through the standard /v1/locate cascade (wide-bbox → embedded → GeoNames → cache → Photon → Nominatim). Provide this OR `lat`+`lng`. |
| tslot | integer | — | Optional tslot offset (band-tempo-relative). |
No output schema declared.
No examples provided.
memory_create memory_create, write a memory file (overwrite if exists) ~681
Write a memory file at `/memories/<path>` with the supplied `file_text`. Overwrites if the file exists AND your key owns the path; a write over someone else's file is refused, not merged. Persists to sled, content-addresses the bytes (`file_cid`), and signs the write so the operation carries a verifiable receipt. Mirrors the `create` verb in Anthropic's context-management-2025-06-27 memory tool spec. WRITES ARE SIGNED, NOT ANONYMOUS: supply `attester: {pubkey_b32, sig_b32}`, an ed25519 signature over blake3("emem.memory_write|<verb>|<path>|<body_hash>"); an unattested write is refused with the exact digest to sign. Under `/memories/by_attester/<pubkey8>/...` only the matching key may write. Elsewhere the first attester to create a path owns it and only that key may change it. Stored content is world-readable by design: this is a shared commons, not private storage. When to use: Call when the LLM issues a `create` against its memory directory (initial scratchpad write, refresh of a notes file, etc.). The response carries the new `file_cid` and a signed receipt the agent can quote in audits. Example arguments: {"path":"/memories/by_attester/<your-pubkey8>/notes.md","file_text":"# Today\n- read the brief\n"}
| Name | Type | Req | Description |
|---|---|---|---|
| attester | object | — | ed25519 caller binding: {pubkey_b32, sig_b32}, where sig signs blake3("emem.memory_write|create|<path>|<body_hash>") and body_hash = blake3(the file_text bytes you send). This responder refuses unatt… |
| file_text | string | yes | Full file contents. |
| kind | string | — | Optional memory typing tag. Default `resource`. `episodic` = observation; `semantic` = learned fact; `procedural` = playbook; `resource` = generic scratchpad; `vault` = AEAD-sealed secret (stored enc… |
| path | string | yes | `/memories/<file>` path. Overwrites if the file exists AND you own the path. Must stay under `/memories/`. |
No output schema declared.
No examples provided.
memory_delete memory_delete, remove a memory file or directory ~436
Delete a memory file at `/memories/<path>`. When the path ends with `/`, every file beneath the directory is removed. Updates the path index but leaves prior content-addressed blobs in place (the audit history is append-only). Mirrors the `delete` verb in Anthropic's context-management-2025-06-27 memory tool spec. WRITES ARE SIGNED, NOT ANONYMOUS: supply `attester: {pubkey_b32, sig_b32}`, an ed25519 signature over blake3("emem.memory_write|<verb>|<path>|<body_hash>"); an unattested write is refused with the exact digest to sign. Under `/memories/by_attester/<pubkey8>/...` only the matching key may write. Elsewhere the first attester to create a path owns it and only that key may change it. Stored content is world-readable by design: this is a shared commons, not private storage. Deletion removes the path from the index; the content-addressed blob and its prior versions remain, because the write history is append-only and a receipt already issued must stay verifiable. Treat this as unpublish, not erasure. Operator erasure is a separate request (see PRIVACY.md). When to use: Call when the LLM issues a `delete` against a memory file or subdirectory it no longer needs. Existing receipts citing the old file_cid stay verifiable, the blob is content-addressed, only the path → file_cid index forgets. Example arguments: {"path":"/memories/by_attester/<your-pubkey8>/notes.md"}
| Name | Type | Req | Description |
|---|---|---|---|
| attester | object | — | Optional ed25519 caller binding. Required for `/memories/by_attester/<pubkey8>/...`. Body is empty for delete; sig signs blake3("emem.memory_write|delete|path|body_hash") where body_hash = blake3(""). |
| path | string | yes | `/memories/<file>` or `/memories/<subdir>/` to delete. Directories drop every file beneath them. |
No output schema declared.
No examples provided.