# emem, the verifiable memory protocol for the physical world (remote · emem.dev) Shared, verifiable memory for AI agents and robots: signed tokens that resolve and verify offline. - Trust score: 64/100 (medium) - Change this week: +1 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-08-03 ## Components - remote · `emem.dev`: 64/100 (this document), [markdown](https://verifymcp.io/servers/vortx-ai-emem/emem.md), [page](https://verifymcp.io/servers/vortx-ai-emem/emem) - oci · `ghcr.io/vortx-ai/emem:latest`: 9/100, [markdown](https://verifymcp.io/servers/vortx-ai-emem/ghcr-io-vortx-ai-emem-latest.md), [page](https://verifymcp.io/servers/vortx-ai-emem/ghcr-io-vortx-ai-emem-latest) ## Channel facts - Endpoint: `https://emem.dev/mcp` - Transports: `streamable-http` - Auth: `none` - Version: `1.4.0` ## Trust breakdown 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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-08-03. - **Endpoint Security**: 63/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (memory_create). - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 51/100 - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name). - AI-judged instruction clarity (poor). - 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. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 27/100 - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 97/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 91% of tool parameters carry a description. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### Claude ```bash claude mcp add --transport http vortx-ai-emem https://emem.dev/mcp ``` ### Codex ```toml [mcp_servers.vortx-ai-emem] url = "https://emem.dev/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "vortx-ai-emem": { "type": "remote", "url": "https://emem.dev/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add vortx-ai-emem --url https://emem.dev/mcp --transport streamable-http ``` ### Hermes ```yaml mcp_servers: vortx-ai-emem: url: "https://emem.dev/mcp" ``` ### Other ```json { "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. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-08-02 (score 64, +3) - [functional improvement] Schema quality: unverified → poor ### 2026-08-01 (score 61, 0) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-31 (score 61, 0) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-30 (score 61, +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. ### 2026-07-29 (score 60, −3) - [security] 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 - [functional] 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” - [cosmetic] “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 ### 2026-07-27 (score 63, 0) - [functional improvement] Stability: unverified → 0.03 - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-26 (score 63) First indexed and scored. ## MCP tools (105) ### `emem_tools` (~545 tokens) What tools exist here, and when to reach for each 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"} Input parameters: - `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. ### `emem_locate` (~416 tokens) Resolve place to cell64 + band inventory 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"} Input parameters: - `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`). ### `emem_ask` (~714 tokens) Ask a free-text question about a place Single-shot free-text answer about a real-world location, backed by signed satellite/elevation/water/built-up receipts. Forwards a place mention plus a question; runs the locate → recall → algorithm chain server-side; returns one packaged envelope. When to use: Use when the question concerns a specific real-world place and a packaged, citation-bearing answer is preferable to manual primitive composition. Forward the user's question verbatim as `q` plus the location as `place` (free text), `cell` (cell64), or `lat`+`lng`. The server resolves the location, classifies the question to a topic, recalls every relevant band (auto-materializing Sentinel-2 / Sentinel-1 / Cop-DEM / JRC GSW / Overture / weather on miss), surfaces the algorithm recipes that compose those bands into named scores, and returns a single envelope with `topic_routing`, `facts`, `algorithms_for_question`, an optional Sentinel-2 RGB scene URL, and a `caveats` block (grid resolution, revisit cadence). All facts are signed by the responder; the signed `receipt` (and its content-addressed `fact_cids`) is surfaced at the envelope ROOT, `response.receipt` / `response.fact_cids`, exactly like every other primitive, and is also mirrored under `facts_summary.receipt` for back-compat. Set `include_image: true` to bundle the latest cloud-free Sentinel-2 thumbnail. Out-of-scope questions return `topic_routing.matched_topic: null` plus the full inventory so the caller can route elsewhere. Example arguments: {"q":"is this neighbourhood flood-prone for a flat purchase","place":"Ashok Nagar, Ranchi"} Input parameters: - `cell` (string): cell64 string (alternative to `place`, use when you have one from a prior emem_locate / emem_recall response). Provide this OR `place` OR `lat`+`lng`. - `include` (array): Opt-in heavy response sections. Default response is slim (~5 KB): answer + algorithm key + fact_cids + caveats. Name specific sections to include them. Ignored when verbose=true (which includes every… - `include_image` (boolean): Bundle a Sentinel-2 RGB scene URL for the resolved cell. Adds ~1-2 s on first call. - `lat` (number): WGS-84 latitude (paired with `lng`; alternative to `place` / `cell`). - `lng` (number): WGS-84 longitude (paired with `lat`). - `place` (string): Free-text place name (e.g. "Mount Fuji", "Ashok Nagar, Ranchi"). REQUIRED unless `cell` or `lat`+`lng` is provided. Extract the noun phrase from the user's turn; the responder geocodes via OSM Nomina… - `q` (string, required): User's natural-language question about the place (e.g. "is this neighbourhood flood-prone"). - `verbose` (boolean): When true, return the full envelope: per-algorithm formula strings, temporal_recipe blocks, per-fact band_metadata duplicates, and the long _explanation prose. Default (since 2026-05-05) is false so… ### `emem_memory_token` (~466 tokens) Compose a memory_token citation handle Mint a citation handle, `emem:fact::` (or `:`), 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"} Input parameters: - `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, required): cell64, neither component may contain `:`. - `fact_cid` (string, required): 52-char base32-nopad-lowercase content-id of the fact (full 32-byte blake3). ### `emem_memory_token_resolve` (~243 tokens) Dereference a memory_token in one round-trip Parse a `emem:fact::` citation handle and return the signed fact body the cid binds. Saves the agent from string-splitting the token and chaining `GET /v1/facts/` 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"} Input parameters: - `token` (string, required): A `emem:fact::` citation handle to dereference. ### `emem_echo_verify` (~402 tokens) Check a value against the fact it cites, before you publish it Grade a value you are about to emit against the signed fact your citation points at. Returns `matches` and, when it does not, the `drift` between what you were about to say and what emem holds. This is the step that turns a transcription error into a caught event instead of a silent wrong number: a model that resolves a fact correctly can still retype `0.2411` for `0.241103`, and nothing else in the loop notices. Algebra: verify. When to use: Call immediately before publishing, logging, or handing on any value you took from an emem fact, and treat a false `matches` as a gate rather than a warning. Pair it with `value_verbatim` from resolve: quote that exact decimal string rather than reformatting the number, then echo-verify what you actually emitted. For a due-diligence or compliance record this is what lets you assert `every cited value was echo-verified` with a signed check per citation instead of a promise. Accepts a bare cid too, so a damaged citation still grades rather than failing closed. Example arguments: {"token":"emem:fact:defi.zb572.xoso.zb1ec:2p6sz3pv45ndkyqstir4nd6bjnzx63rrcb4pnhgahsnb2oczh5aq","claimed_value":"-0.0558"} Input parameters: - `claimed_value` (required): The value you are about to publish, as a string or a number. A string is compared verbatim first, which is what catches a retype a float comparison would forgive. - `strict` (boolean): Require BYTE-IDENTICAL equality. Default false, which also accepts a numerically equal value spelled differently (0.50 for 0.5). - `token` (string, required): The citation you used. Any form resolve accepts, including a bare cid (answers degraded). ### `emem_memory_bundle` (~409 tokens) Compose a signed multi-fact memory bundle 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:`, 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"} Input parameters: - `purpose` (string): Optional human-readable purpose string. Included in the bundle_cid preimage so the same triples + different purposes produce distinct CIDs. - `triples` (array, required): 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… ### `emem_entity` (~446 tokens) Mint or get a canonical object identity Give a real-world object (a bridge, a farm plot, a river, a named place) a single, shared, content-addressed identity that any agent resolves the same way. Returns an `entity_token` (`emem:entity:`) plus a signed receipt that attests how the reference resolved. Two agents that name the same object mint the SAME entity_cid; when a stable external id (Overture GERS / OSM) is known it dominates identity, so divergent labels for one real object still collapse to one id. This is the object-level antidote to referential drift: 'the damaged bridge near the river' becomes one canonical thing every model reasons about, not a phrase each model re-interprets. When to use: Call when a conversation refers to a THING and you want a stable handle to it that survives summarization and travels between agents/turns/LLMs, before it drifts into 'that infrastructure issue'. Anchor it with `place`, a `cell`, or `lat`+`lng`. Hand the returned `emem:entity:` token to any other agent; they dereference the identical object. Recall/ask at the entity's `cell64` for signed facts about it. Example arguments: {"label":"Golden Gate Bridge","kind":"bridge","place":"Golden Gate Bridge, San Francisco"} Input parameters: - `cell` (string): cell64 to anchor the object directly (no geocode). - `external_ids` (object): Stable ids that drive convergence. Caller-supplied values win over geocoder-derived ones. - `kind` (string): Object class: bridge, river, farm_plot, building, admin_division, place, custom, ... Defaults to "place". - `label` (string, required): Human name of the object, e.g. "Golden Gate Bridge", "the north dam". Required. - `lat` (number) - `lng` (number) - `parent` (string): Optional parent entity_cid (containment). - `place` (string): Free-text place to anchor the object (geocoded). Provide place OR cell OR lat+lng. ### `emem_entity_resolve` (~279 tokens) Resolve a phrase (or emem:entity: token) to a canonical object Converge a fuzzy phrasing onto the canonical object other agents already minted, so everyone co-refers to the same identity instead of re-minting divergent ones. Pass `text` (e.g. "the collapsed span at the ford") to get ranked existing candidates; pass `near` to narrow to a place; or pass an `emem:entity:` `token` to dereference it directly to the signed entity body. Read-only. When to use: Call BEFORE minting when another agent may already have registered the object, or when you receive a `emem:entity:` token and want the object behind it. This is how two agents avoid referential drift: resolve first, mint only if nothing matches. Example arguments: {"text":"the golden gate bridge","near":"San Francisco"} Input parameters: - `k` (integer): Max candidates (default 10). - `label` (string): Alias for `text`. - `near` (string): Optional place/cell to narrow to objects anchored nearby. - `text` (string): Fuzzy phrasing to resolve to an existing canonical object (e.g. "the damaged bridge near the river"). - `token` (string): A `emem:entity:` handle to dereference directly to its signed object (bypasses the text search). ### `emem_entity_link` (~239 tokens) Attest that a phrasing/id denotes an existing object Record a signed equivalence: bind an alternate label or a stable external id (GERS / OSM / Wikidata) to an existing canonical object so future `emem_entity_resolve` calls on that phrasing converge to the same entity_cid. Builds the shared reference graph that keeps different agents' vocabularies pointing at one identity. When to use: Call when you learn that two phrasings denote the same object ('the north dam' == an existing entity), or to attach an authoritative external id to an object minted from free text. Example arguments: {"entity_token":"emem:entity:0a1b2c3d4e5f60718293","alias":"the north dam"} Input parameters: - `alias` (string): An alternate label/phrasing that should resolve to this object. - `entity_cid` (string): The canonical object to attach an equivalence to. Provide entity_cid OR entity_token. - `entity_token` (string): A `emem:entity:` handle for the same. - `external_ids` (object): Stable ids to bind to this object. ### `emem_recall` (~1065 tokens) Recall facts at a cell (auto-materializes on miss) 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: []`. 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"]} Input parameters: - `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, required): 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) ### `emem_find_similar` (~464 tokens) k-NN over the corpus by embedding k-NN over the corpus by cell embedding or inline vector. When to use: Call when the user asks 'find places like X', 'where else looks like this', or hands an embedding to find neighbours. `key` is either a cell64 or `inline:[x,y,...]`. Default band is `geotessera` (128-D Tessera foundation embedding); pass `band: "geotessera.multi_year"` for the 1152-D 9-vintage (2017–2025) fusion. Example arguments: {"key":"damO.zb000.xUti.zde78","k":10} Input parameters: - `as_of_signed_at` (string): Bi-temporal transaction-time bound (RFC 3339). Also applied to candidates BEFORE cosine. Same Lance-bypass note as as_of_tslot. - `as_of_tslot` (integer): Bi-temporal valid-time bound. Applied to candidate cells BEFORE cosine scoring, a cell with no fact whose tslot ≤ as_of_tslot under the scoring band is dropped from the candidate pool (undecidable→dr… - `band` (string): vector band to scan (default: 128-D Tessera foundation embedding). For mode=hamming/hamming_then_rerank you can pass either the cosine band (e.g. 'geotessera') or its binary sibling ('geotessera.bin1… - `k` (integer) - `key` (string, required): cell64 (look up that cell's vector) or 'inline:[x,y,...]' literal vector - `mode` (string): Scoring mode. cosine = fp32 over full vector (precise, ~256 B/cell scan). hamming = sign-bit popcount over the binary sibling band (~16 B/cell, ~1000× faster, ~65% recall@10). hamming_then_rerank = t… ### `emem_memory_contradictions` (~465 tokens) Scan for multi-attester disagreement 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} Input parameters: - `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. ### `emem_verify_receipt` (~422 tokens) Server-side ed25519 receipt verifier 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]}} Input parameters: - `pubkey_b32` (string): Optional explicit responder pubkey (base32). When omitted, uses the receipt's embedded pubkey/responder fields. - `receipt` (object, required): 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… ### `emem_intent` (~160 tokens) Intent-routed planner Submit a typed Intent; receive a plan or executed result. When to use: Call when the user asks something like 'where is X' or 'is A like B' and you don't want to pick a primitive yourself, the planner maps Intent variants to the right tool call. Example arguments: {"type":"what_is_here","cell":"damO.zb000.xUti.zde78"} Input parameters: - `a` (string) - `b` (string) - `band` (string) - `cell` (string) - `claim` (object) - `description` (string) - `k` (integer) - `key` (string) - `type` (string, required) - `window` (array) ### `emem_hunt` (~633 tokens) Hunter mode, find event hotspots over a region Event-discovery sweep: pick an event keyword (algal_bloom, deforestation, flood_extent, wildfire, urban_heat_island, methane_plume, landslide, drought, soil_salinity, crop_stress, water_turbidity, oil_slick) plus a region (free-text name or polygon_bbox). The responder geocodes the region, fans out across up to 32 sampled cells, recalls each event's primary scalar input band, and returns the top 8 hotspots ranked by that scalar, each an attested entry in the shared memory carrying its cell64, lat/lng, the recalled value, a fact_cid for citation, and a scene.png URL. Bypass for free-text input is `emem_ask` (the classifier in /v1/ask routes "find X in Y" questions to the same hunter path). When to use: Call when the user asks an open-world discovery question ("find oil spills in the Persian Gulf", "where is deforestation happening in the Amazon", "show me algal blooms in Lake Erie", "hunt wildfires across California"). Surface 3–8 hotspots with their scene.png as image attachments and quote at least one fact_cid. For `oil_slick` the responder honestly reports `not_yet_implemented` and points at SAR-darkening + turbidity proxies, don't fabricate detections. The ranking uses the algorithm's primary scalar input only; for the full per-cell algorithm score, fetch the formula at /v1/algorithms/ and apply it client-side over the same recalled bands. Example arguments: {"event":"algal_bloom","region":"Lake Erie"} Input parameters: - `event` (string, required): Event keyword. Maps to one registered detection algorithm: algal_bloom → algal_bloom_chlorophyll_ndci@1, deforestation → deforestation_alert_ndvi_drop@1, flood_extent → flood_extent_sar_threshold@1,… - `polygon_bbox` (object): Explicit polygon bbox; alternative to `region`. Provide when you already have coordinates from a prior locate / recall_polygon call. - `region` (string): Free-text region (e.g. "Persian Gulf", "Sahel", "Lake Erie", "California"). Resolved through the same geocoder as /v1/locate. REQUIRED unless `polygon_bbox` is provided. ### `emem_eudr_dds` (~759 tokens) EUDR Due Diligence Statement, polygon-in, signed Annex II envelope out Produce a Due Diligence Statement per Regulation (EU) 2023/1115 for one or more plots. Each plot carries operator-supplied geometry (GeoJSON Polygon for >4 ha, Point for ≤4 ha non-cattle per Article 2(28)), country of production (ISO3), Combined Nomenclature code (HS-6+), and quantity in kg. The endpoint applies the regulation's 10 % canopy / 0.5 ha / 5 m height forest definition (Article 2(4)) using the EU Commission's expected JRC GFC2020 V3 baseline plus Hansen GFC v1.12 loss-year confirmation; Sims et al. 2025 driver attribution and RADD SAR fallback layer on when those connectors are wired (Absence today). The response is an Annex II-shaped envelope with per-plot verdict (pass/fail/not_in_scope/indeterminate/below_mmu), failing-cell fraction, and signed fact CIDs for every per-cell verdict, operators quote them in the company's Article 12 record. Article 9(1)(b) legality (land tenure, FPIC, country-of-origin laws) is structurally out of EO scope; the response carries an explicit `legality_disclaimer` for that reason. When to use: Call when a commodity supplier or EU importer needs to evidence due diligence under Regulation (EU) 2023/1115. Use the plot-level signed receipts as evidence inside the operator's company record; pair with a partner legality module before submitting the final DDS to the EU Information System (TRACES NT). For a single plot, pass one entry in `plots`. For batch supply-chain audits, pass up to a few dozen plots in one call, the endpoint fans out per plot. Surface the failing-cell fraction, the chosen forest baseline, and the legality disclaimer in the user-facing response so the operator understands what the engine claims (and does not). Example arguments: {"plots":[{"plot_id":"farm-001","geometry_geojson":{"type":"Polygon","coordinates":[[[-60.5,-3.5],[-60.4,-3.5],[-60.4,-3.4],[-60.5,-3.4],[-60.5,-3.5]]]},"country_of_production":"BRA","commodity_hs":"0901","commodity_name":"coffee","quantity_kg":12000}],"operator":{"name":"Acme Coffee… Input parameters: - `cut_off_date` (string): EUDR cut-off date in ISO 8601. The regulation's value is 2020-12-31; only loss after this date counts as failure. - `forest_baseline_override` (string): Optional baseline override. Default 'jrc_gfc2020_v3' is the EU Commission's expected (non-binding) baseline. Acceptable: 'jrc_gfc2020_v3', 'hansen_only', 'both'. - `legality_module` (string): Operator-chosen legality provider. Default null surfaces the explicit Article 9(1)(b) out-of-EO-scope disclaimer. - `max_cells_per_plot` (integer): Sample budget per POLYGON plot. Omit to auto-derive from polygon area (~110 cells/ha, clamped to 51,200) so the whole plot is evaluated; EUDR plots are typically large, so do not set a small value un… - `operator` (object) - `plots` (array, required): One or more plots to evaluate for EUDR compliance. ### `emem_spi` (~421 tokens) Standardized Precipitation Index (McKee 1993) drought metric 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} Input parameters: - `cell` (string, required): 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). ### `emem_burn_severity` (~356 tokens) Burn severity (dNBR, Key & Benson) from pre/post-fire NBR Compute the differenced Normalized Burn Ratio (dNBR = NBR_pre − NBR_post; Key & Benson 2006) and map it to the USGS burn-severity classes (unburned / low / moderate-low / moderate-high / high). Supply `nbr_pre` + `nbr_post` (pin the scenes bracketing the fire date) for a correct result, or omit both to use the two most-recent stored `indices.nbr` scenes (older=pre, newer=post) as a coarse estimate. The result is signed; the receipt cites the NBR fact_cids it read from the shared memory. When to use: Call after a wildfire to quantify how badly an area burned, or to triage post-fire severity across a region cell-by-cell. Best practice: explicitly pass `nbr_pre`/`nbr_post` from scenes that bracket the known fire date, the stored-trajectory fallback just takes the two most-recent scenes and may not bracket the fire. Surface `dnbr` and `severity_class`. For active-fire detection use `emem_hunt` with the wildfire event instead. Example arguments: {"cell":"defi.zb493.xoso.zcb6a","nbr_pre":0.62,"nbr_post":0.11} Input parameters: - `cell` (string, required): cell64 or place name. - `nbr_post` (number): Post-fire NBR. When both nbr_pre and nbr_post are omitted the endpoint uses the two most-recent stored indices.nbr scenes (older=pre, newer=post). - `nbr_pre` (number): Pre-fire NBR. Pin the scene just before the fire date for a correct result. ### `emem_rice_ch4` (~575 tokens) Rice-paddy methane (IPCC 2019 Tier 2, Eq 5.1) 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} Input parameters: - `cell` (string, required): cell64 or place name. - `cultivation_period_days` (number, required): 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, required): 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). ### `emem_deforestation_alert` (~382 tokens) Deforestation alert proxy (NDVI drop + embedding change) Composite deforestation-alert score: `alert_score = 0.5·clamp01(ndvi_drop/0.30) + 0.5·clamp01(embedding_change/0.20)`, where `ndvi_drop = max(0, ndvi_modis_baseline − ndvi_now)` and `embedding_change = 1 − cos(tessera_latest, tessera_prev)`. Each half degrades INDEPENDENTLY and honestly: if a band is missing, that half is dropped AND the output is renamed so a half-score can never be mistaken for the full composite. If NEITHER half is computable the response is a signed `inconclusive` carrying no number. Every response also carries a machine-readable `degraded` boolean plus `degraded_reason` (closed set: `embedding_half_unavailable`, `ndvi_half_unavailable`, `no_inputs`) and `degraded_message`, so a caller gates on the flag instead of parsing prose. When to use: Call to flag recent forest-loss-like change at a known cell when you want a single 0..1 alert score rather than a full ensemble. Gate on `degraded`/`degraded_reason`: a half-score (`degraded:true`) must NOT be thresholded against the 0.6 alert gate. Read the renamed score field and the present/absent halves, don't treat a half-score as the full composite. For multi-cell open-world discovery use `emem_hunt` (deforestation event); for the three-encoder change ensemble use `emem_triple_consensus`; for regulatory EUDR evidence use `emem_eudr_dds`. Example arguments: {"cell":"defi.zb493.xoso.zcb6a"} Input parameters: - `cell` (string, required): cell64 or place name. ### `emem_sar_forest_disturbance` (~382 tokens) Sentinel-1 SAR forest-disturbance scout (cloud-penetrating) 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} Input parameters: - `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, required): cell64 or place name. ### `emem_triple_consensus` (~620 tokens) Clay+Prithvi+Tessera change-consensus ensemble 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… Input parameters: - `cell` (string, required): cell64 or place name. - `consensus_threshold` (number): Override the registry consensus gate (default 0.15); clamped to (0,1). ### `emem_change_attribution` (~501 tokens) Change attribution ledger: why did this place's readout move The first runnable surface of the change decomposition Δz = Δ_env + Δ_sensor + Δ_geo + Δ_encoder + ε: a per-term evidence LEDGER for the readout change at a cell, with NO numeric split. `observed` carries the Tessera year-over-year embedding change. `terms.env` carries label-free index pairs (NDVI, NBR, NDWI) with raw deltas and both fact cids, evidence a future estimator would read. `terms.sensor` records what each visit was observed through (source scheme and scene id per band) and whether that path changed. `terms.geo` is declared not estimated (no registration-residual surface exists). `terms.encoder` is pinned by construction: both vintages are slices of one signed multi-year fact under one recipe, named by fn_key. `terms.noise` reports the S2 scene-classification class per visit, so a cloud flip is visible. `split` is null and `attribution_note` says why: splitting a delta numerically needs a calibrated cross-encoder, cross-sensor stability model this responder does not have, and inventing magnitudes would fabricate the exact confusion the decomposition exists to prevent. The ledger persists: each run stores itself as a derivative fact (band change_attribution.ledger, parents = every fact read) and the response returns its own emem:fact: token under ledger_fact, so an attribution is cited and dereferenced like any reading. The receipt binds every input fact cid plus the stored ledger cid. Bands read cold may materialize, so this signs and persists facts. When to use: Call when a change surface (emem_diff, emem_state_diff, emem_triple_consensus, did_change) reported that a place's readout moved and the question is WHY: world, instrument, pixels, model, or noise. Read the per-term evidence and cite its fact cids; do not expect a numeric split (`split` is null by design, see `attribution_note`). Bands with fewer than two distinct tslots at the cell appear under evidence_absent with a typed reason rather than a fabricated pair. For the raw delta itself use emem_… Input parameters: - `cell` (string, required): cell64 or place name. ### `emem_band_raster` (~862 tokens) Band raster: a field as a signed derivation Return a native-resolution Sentinel-2 window over a bounding box as a FIELD, not a set of points: the pixels become one content-addressed grid artifact (deterministic f32 encoding; fetch the bytes at the returned artifact url, Cache-Control immutable), and what the receipt attests is the DERIVATION, never a byte pipe. A persisted derivation record pins the chosen scene (id, asset, capture time, cloud cover), the recipe (band_raster@1), the grid georeferencing in the scene's UTM CRS, and best-effort per-cell anchors that bridge the artifact to existing signed facts; the receipt's FIELD preimage segment binds (aoi_cid, derivation_cid), reported by /v1/verify_receipt as field_bound. Bounds are refusals with the cap named: six raw S2 bands (B02/B03/B04/B08/B11/B12) and 512 px per side at native resolution (about 5.1 km at 10 m). Anchors never materialize a fact, so a cold AOI costs one scene read, nothing more. The artifact is evictable BY DESIGN: the record persists like any fact and pins everything needed to rebuild identical bytes, so eviction turns a dereference into a recompute, never a broken citation. Returns two tokens: emem:raster: (resolve with emem_raster_resolve) and the record's own emem:fact: handle. This signs and persists the derivation record. TERRAIN: pass band `copdem30m.elevation` (or `elevation` / `dem`) for a static Copernicus GLO-30 elevation field via the dem_raster@1 path, no scene selection, no cloud, EPSG:4326 grid; a bbox crossing a 1-degree DEM tile edge is refused (single-tile only) and open ocean has no tile. EMBEDDING (WB-5): pass an encoder band (geotessera etc.) for a MULTI-CHANNEL embedding field via embedding_raster@1, a signed N-D vector per cell (geotessera = 128-D) packed into one artifact, so a client-side per-cell embedding fan-out becomes one citeable token; every filled cell is anchored to its real signed encoder fact; grid capped at 256 cells at the 0.1-degree native step. When to use: Call when an agent needs an area's actu… Input parameters: - `band` (string, required): One of s2.B02, s2.B03, s2.B04, s2.B08, s2.B11, s2.B12 (Sentinel-2 scalar field); copdem30m.elevation (also elevation / dem) for a static GLO-30 DEM field via dem_raster@1; OR an encoder band (geotess… - `bbox` (object, required): WGS-84 bounding box of the area of interest. - `observed_on` (string): Optional target capture date YYYY-MM-DD (Sentinel-2 only; ignored for the static DEM band); the scene actually chosen is pinned in the derivation record either way. ### `emem_raster_resolve` (~465 tokens) Dereference an emem:raster: field token Resolve emem:raster:::: 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::s2.B04:20650:"} Input parameters: - `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, required): emem:raster:::: ### `emem_band_cube` (~590 tokens) Band cube: a field over time, as a signed manifest Mint an emem:cube: token: a Sentinel-2 field over an AOI ACROSS TIME. A world model is a field over an area across time, and emem:raster: names only one time-slice, so a 4D world's time scrub had no token to anchor. This mints one band_raster member per target date, each an independent, resolvable emem:raster: derivation, then signs a cube record binding the ordered set. It is NOT new pixels: lineage terminates in each member's pinned scene, so a stranger walks cube -> members -> scenes and re-derives every value from raw Sentinel-2 bytes. cube_cid content-addresses the ordered membership (blake3 of the member derivation cids), so the same slices always name the same cube. Two dates that resolve to the same scene collapse; a cube needs at least two distinct slices and caps at 24 per mint (refused with the cap named). Each member echoes `requested_dates` (the observed_on entries that mapped to it) and `requested_date_distance_days` (the nearest one's gap from the scene's own capture date), so a caller lines a requested date up with its slice directly rather than guessing by tslot proximity. The receipt's FIELD preimage segment binds (aoi_cid, derivation_cid), reported by /v1/verify_receipt as field_bound. Returns the emem:cube: token plus the member emem:raster: tokens. This signs and persists the cube record and its members. When to use: Call when a world model or change-over-time analysis needs a time series of fields over one AOI, not one snapshot: the 4D world token, a phenology stack, a before/during/after triptych. For one time-slice use emem_band_raster; for one cell's value over time use emem_trajectory; resolve a received cube with emem_cube_resolve. Example arguments: {"bbox":{"min_lat":32.5699,"min_lng":77.0328,"max_lat":32.5727,"max_lng":77.0362},"band":"s2.B08","observed_on":["2026-05-01","2026-06-01","2026-07-01"]} Input parameters: - `band` (string, required): One of s2.B02, s2.B03, s2.B04, s2.B08, s2.B11, s2.B12. - `bbox` (object, required): WGS-84 bounding box of the area of interest, shared by every slice. - `observed_on` (array, required): 2 to 24 target capture dates YYYY-MM-DD. Each names the nearest scene, pinned per member; two dates that resolve to the same scene collapse to one slice. ### `emem_band_composite` (~583 tokens) Band composite: a signed cloud-masked median over a window Mint a signed, cloud-masked median composite over a date window as a raster-shaped field: the clean, gap-filled texture a world model actually drapes, rather than one cloudy scene. It reads every Sentinel-2 scene in [start_date, end_date] over the bbox, masks each per pixel by its SCL scene-classification class (default reject {0,1,3,8,9,10}: no-data, saturated, cloud shadow, cloud, cirrus; snow 11 is KEPT because snow is surface, not occlusion, and a snow-rejected median would fabricate a bare winter scene; override with mask_policy), and takes the per-pixel lower-of-two median (never averaging two measurements into a value nobody took) with a pinned min_valid_count, below which a pixel is nodata. The mask policy, min_valid_count, and the exact member scene list are pinned in the signed derivation, so a stranger re-derives the composite pixel for pixel from the same scenes. Returns an emem:raster: token (resolve with emem_raster_resolve) plus the content-addressed artifact; the receipt binds (aoi_cid, derivation_cid). Needs at least two clear scenes at one CRS. This signs and persists the derivation. When to use: Call when a world model or an analyst needs the clean composite texture over an area across a season, not a single-date snapshot that may be cloudy: a scrub-frame base layer, a gap-filled band drape, a cloud-free mosaic. For one pinned scene use emem_band_raster; for the per-slice time series use emem_band_cube. Example arguments: {"bbox":{"min_lat":32.5699,"min_lng":77.0328,"max_lat":32.5727,"max_lng":77.0362},"band":"s2.B04","start_date":"2026-05-01","end_date":"2026-07-31"} Input parameters: - `band` (string, required): One of s2.B02, s2.B03, s2.B04, s2.B08, s2.B11, s2.B12. - `bbox` (object, required): WGS-84 bounding box of the area of interest. - `end_date` (string, required): Window end YYYY-MM-DD, inclusive. - `mask_policy` (array): SCL classes to reject per pixel. Default [0,1,3,8,9,10]; snow 11 is kept as surface. - `max_scenes` (integer): Cap on scenes read. Default 12. - `min_valid_count` (integer): Per-pixel minimum valid samples for a value, else nodata. Default 1. - `start_date` (string, required): Window start YYYY-MM-DD, inclusive. ### `emem_cube_resolve` (~356 tokens) Dereference an emem:cube: field-over-time token Resolve emem:cube:::..: back to its signed cube record and the ordered member emem:raster: tokens. Same fail-closed rule as emem_raster_resolve: the cid must be a band_cube@1 derivation, the token's aoi_cid, band, and tslot range must each match the signed record, and cube_cid is recomputed from the record's members so an altered membership is refused (typed 409), not silently served. Returns the full record plus a member_tokens list you resolve independently with emem_raster_resolve or batch through resolve_many; each member's artifact is at GET /v1/artifacts/{cid}, immutable. The receipt binds (aoi_cid, derivation_cid) through the FIELD preimage segment. When to use: Call when you receive an emem:cube: token from another agent and want the verified time series behind it: this returns the bound record and the member raster tokens, then resolve those (or resolve_many) and re-hash each artifact against its artifact_cid for the spot-check tier. For a single emem:raster: token use emem_raster_resolve; for emem:fact: use emem_memory_token_resolve. Example arguments: {"token":"emem:cube::s2.B08:20600..20651:"} Input parameters: - `token` (string, required): emem:cube:::..: ### `emem_raster_bundle` (~521 tokens) Raster bundle: bind N field tokens into one citeable manifest 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::s2.B04:20509:","emem:raster::s2.B03:20509:","emem:raster::s2.B02:20509:"],"purpose":"world_soubre RGB ground"} Input parameters: - `purpose` (string): Optional human-readable purpose, folded into bundle_cid so the same members under a different purpose get a distinct bundle. - `tokens` (array, required): 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. ### `emem_raster_bundle_resolve` (~254 tokens) Dereference an emem:rasterset: bundle token Resolve emem:rasterset:: 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::"} Input parameters: - `token` (string, required): emem:rasterset:: ### `emem_terrain` (~395 tokens) Terrain triad, slope + ruggedness + topographic position from DEM 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"} Input parameters: - `cell` (string, required): 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… ### `emem_region_similarity` (~281 tokens) Region similarity, cosine of two regions' mean GeoTessera embeddings 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"}} Input parameters: - `max_cells` (integer): Per-region cell cap. - `region_a` (object, required): First region: {place} | {polygon_bbox:{min_lat,max_lat,min_lng,max_lng}} | {cells:[cell64,...]}. - `region_b` (object, required): Second region, same shape as region_a. ### `emem_embedding_centroid` (~271 tokens) Embedding centroid, mean-pooled GeoTessera vector for a region Mean-pool the 128-D GeoTessera embedding over a region's cells: centroid = (1/N) Σ v_i, plus the L2-normalised centroid and a content-addressed centroid_cid. The building block region_similarity composes. Region is {place} | {polygon_bbox} | {cells}. NaN dims are averaged over their finite contributors. CPU-only. When to use: Call when you need one representative embedding vector for an area, to feed similarity search, clustering, or a linear probe over places rather than single cells. Returns a stable centroid_cid for citation. Signed `inconclusive` when no cell in the region carried a vector. Example arguments: {"place":"Serengeti National Park","max_cells":64} Input parameters: - `cells` (array): Explicit cell64 list (taken verbatim, capped by max_cells). Alternative to place/polygon_bbox. - `max_cells` (integer): Cap on cells sampled from the region; surfaced as coverage_capped. - `place` (string): Free-text place name; resolved through the layered geocoder to a polygon bbox, then sampled. One of place/polygon_bbox/cells required. - `polygon_bbox` (object): Explicit bbox; sampled on a grid. Alternative to place/cells. ### `emem_embedding_diversity` (~294 tokens) Embedding diversity, landscape heterogeneity over a region Quantify how varied a region's landscape is: diversity = (1/(N(N-1))) Σ_{i:`. EVERY one must resolve to a fact this responder already holds, or the call is refused naming the one that did not: lineage that cannot be walked i… - `op` (string, required): Operator: delta | mean | trend | rate | anomaly. - `provenance_class` (string, required): How the value was produced. `direct_sensor` and `deterministic_index` are refused as a DECLARATION: this responder did not compute your value and will not take your word that it is recomputable. It c… - `tslot_window` (array, required): Inclusive [start, end] tslot window the derivation spans. - `value` (required): The value you computed. Any JSON value. ### `emem_derive_list` (~296 tokens) List one attester's registered derivations List the derivations registered by one ed25519 key, optionally filtered to a cell (and then a band). The explicit opt-in read for caller-registered derivatives: they hold no canonical key, so no default read path returns them, and this is the only way to enumerate one rather than resolve it by token. When to use: Call to enumerate your own derivations (pass your pubkey_b32), or to inspect what a specific attester has claimed when you already have a reason to trust or audit that key. There is no all-attesters form: naming whose claims you want is the contract, not a filter you can omit. Example arguments: {"attester_pubkey_b32":"n2vqbtqx4dmz3xk6yqhkdmnjmfqvnqzq2qgz7ymkflgnvzptdcaa","cell":"defi.zb493.xoso.zcb6a"} Input parameters: - `attester_pubkey_b32` (string, required): The base32 pubkey whose derivations to list. Required: there is no query that returns every caller's derivations, because derivations are attester-scoped by design. - `band` (string): Optional band filter. Only narrows when `cell` is also set (the index is keyed cell-before-band). - `cell` (string): Optional cell64 filter. - `limit` (integer) ### `emem_memory_bundle_resolve` (~193 tokens) Dereference a memory_bundle token Parse a `emem:bundle:` 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"} Input parameters: - `token` (string, required): A `emem:bundle:` rebindable handle to dereference. ### `memory_view` (~457 tokens) memory_view, read file or directory listing Read the contents of a memory file at `/memories/` or list a directory when the path ends with `/`. Optional `view_range: [start, end]` slices a 1-indexed inclusive line range out of the file. Mirrors the `view` verb in Anthropic's context-management-2025-06-27 memory tool spec. Reads are public: no key, no account, and every stored memory on this responder is world-readable, including files other agents wrote. Do not put anything private here. When to use: Call when the model running with `betas: ['context-management-2025-06-27']` issues a `view` against its memory directory. Use `/memories/` (trailing slash) to enumerate files; `/memories/notes.md` to read one. Returns a 404 with typed code on missing path. Example arguments: {"path":"/memories/by_attester//"} Input parameters: - `kind` (string): Optional kind filter when listing a directory. Restricts entries to one memory type (episodic|semantic|procedural|resource). - `offset` (integer): Directory listings only: skip this many entries. A truncated listing reports where to resume as _emem_truncation.omitted_fields[].stub._next_offset; pass that value here for the next page. The respon… - `path` (string, required): `/memories/` for a file, or `/memories//` for a directory listing. Must stay under `/memories/`. - `vault_capability` (string): Optional Vault capability: an ed25519 signature (base32-nopad-lc) over blake3("emem.vault_open|"+path+"|"+nonce_bytes), verifiable under the responder pubkey that sealed the entry. When the path is a… - `view_range` (array): Optional [start_line, end_line] inclusive, 1-indexed. Lets the agent read part of a long file. ### `memory_create` (~681 tokens) memory_create, write a memory file (overwrite if exists) Write a memory file at `/memories/` 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|||"); an unattested write is refused with the exact digest to sign. Under `/memories/by_attester//...` 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//notes.md","file_text":"# Today\n- read the brief\n"} Input parameters: - `attester` (object): ed25519 caller binding: {pubkey_b32, sig_b32}, where sig signs blake3("emem.memory_write|create||") and body_hash = blake3(the file_text bytes you send). This responder refuses unatt… - `file_text` (string, required): 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, required): `/memories/` path. Overwrites if the file exists AND you own the path. Must stay under `/memories/`. ### `memory_str_replace` (~406 tokens) memory_str_replace, exact-string replacement in a memory file Replace `old_str` with `new_str` in the named memory file. Fails (no partial write) when `old_str` is absent or matches more than once. Writes a new content-addressed `file_cid` and signs the receipt. Mirrors the `str_replace` 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|||"); an unattested write is refused with the exact digest to sign. Under `/memories/by_attester//...` 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 `str_replace` against its memory file, typical for small targeted edits. The strict single-match contract is the contract Claude expects: an LLM that sees a single-match diff knows the change applied where it intended. Example arguments: {"path":"/memories/by_attester//notes.md","old_str":"read the brief","new_str":"finished the brief"} Input parameters: - `attester` (object): Optional ed25519 caller binding. See memory_create for the preimage shape (verb=str_replace). - `kind` (string): Optional memory typing override. If omitted the existing kind is preserved. - `new_str` (string, required): Replacement substring. - `old_str` (string, required): Exact substring to replace. The whole call fails (no partial write) when the old_str is absent or appears more than once. - `path` (string, required): `/memories/` path the replacement targets. ### `memory_insert` (~413 tokens) memory_insert, insert at a given line Insert `new_str` after the given 1-indexed line in the named memory file. `insert_line: 0` inserts at the top. Writes a new `file_cid` and signs the receipt. Mirrors the `insert` 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|||"); an unattested write is refused with the exact digest to sign. Under `/memories/by_attester//...` 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 wants to append a new line to a memory file without rewriting it. For top-of-file inserts, pass `insert_line: 0`; for end-of-file, pass the current line count (the responder rejects out-of-range with a typed error). Example arguments: {"path":"/memories/by_attester//notes.md","insert_line":0,"new_str":"draft 2026-05-28"} Input parameters: - `attester` (object): Optional ed25519 caller binding. See memory_create for the preimage shape (verb=insert). - `insert_line` (integer, required): 1-indexed line number AFTER which to insert. 0 inserts at the top of the file. - `kind` (string): Optional memory typing override. If omitted the existing kind is preserved. - `new_str` (string, required): Text to insert. A trailing newline is preserved if present; one is added otherwise. - `path` (string, required): `/memories/` path the insertion targets. ### `memory_delete` (~436 tokens) memory_delete, remove a memory file or directory Delete a memory file at `/memories/`. 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|||"); an unattested write is refused with the exact digest to sign. Under `/memories/by_attester//...` 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//notes.md"} Input parameters: - `attester` (object): Optional ed25519 caller binding. Required for `/memories/by_attester//...`. Body is empty for delete; sig signs blake3("emem.memory_write|delete|path|body_hash") where body_hash = blake3(""). - `path` (string, required): `/memories/` or `/memories//` to delete. Directories drop every file beneath them. ### `memory_rename` (~422 tokens) memory_rename, move a memory file Move (rename) a memory file from `old_path` to `new_path`. Both paths must stay under `/memories/`; `new_path` must not already exist. The file_cid is preserved (no re-sign) so the prior receipt still binds the bytes. Mirrors the `rename` 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|||"); an unattested write is refused with the exact digest to sign. Under `/memories/by_attester//...` 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 wants to rename or move a memory file. Failure modes: source missing, destination already exists, path escapes `/memories/`. Example arguments: {"old_path":"/memories/by_attester//notes.md","new_path":"/memories/by_attester//archive/notes-2026-05.md"} Input parameters: - `attester` (object): Optional ed25519 caller binding (verb=rename). Required when either path is under `/memories/by_attester//...`. One signature binds both ends of the move: sig signs blake3("emem.memory_write… - `new_path` (string, required): Destination `/memories/` path. Fails when the destination exists. - `old_path` (string, required): Existing `/memories/` path. ### `memory_list_by_kind` (~270 tokens) memory_list_by_kind, typed enumeration of memory files List memory files by their typed `kind` (episodic | semantic | procedural | resource). Optional path prefix narrows the scan; results are sorted by signed_at descending. The kind taxonomy follows the CoALA / LangMem / MIRIX agent-memory ontology: `episodic` = observations of events, `semantic` = durable learned facts, `procedural` = playbooks, `resource` = generic durable scratchpad (default for back-compat). Reads are public: no key, no account, and every stored memory on this responder is world-readable, including files other agents wrote. Do not put anything private here. When to use: Call when an agent wants only one slice of its memory (e.g. surface every semantic fact it has learned about a topic) without scanning the full directory tree. Pair with memory_view for read-back of a specific entry. Example arguments: {"kind":"semantic","prefix":"/memories/","limit":50} Input parameters: - `kind` (string, required): Memory type to enumerate. - `limit` (integer): Maximum entries to return (default 256, cap 2048). Results are sorted signed_at desc. - `prefix` (string): Optional path prefix filter, e.g. `/memories/by_attester/abcd1234/`. ### `emem_memory_search` (~743 tokens) emem_memory_search, semantic search over /memories/* files 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… Input parameters: - `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, required): Free-text query. Semantic, matches paraphrases not just substrings. ### `emem_corpus_state_stats` (~141 tokens) Signed snapshot of corpus liveness Signed snapshot of corpus liveness: distinct_cells, distinct_bands, facts_scanned, top per-band counts, manifest CIDs. Same payload that backs /v1/stream's corpus.state tick (signed). Use this for a one-shot poll instead of holding an SSE connection. When to use: Call when an agent needs a single liveness reading to surface in a dashboard, attach to a report, or decide whether to refresh local caches. Includes ed25519 signature over a deterministic preimage so the snapshot is verifiable. For a continuous feed, GET /v1/stream over Server-Sent Events instead. Example arguments: {} ### `emem_benchmark` (~142 tokens) Hand-verified eval items for agent grading Hand-verified evaluation items for grading an agent against the responder. Returns {items[], grader_url}. Submit answers (cell64 or fact_cid per item) to POST /v1/benchmark/grade for per-item scores. Items today: elevation recall, NDVI, find_similar neighbours. When to use: Call once at agent-onboarding time (or in CI) to fetch the canonical task list, then have the agent answer each item using its normal tool routing, and POST the answers map to /v1/benchmark/grade for a deterministic score. Lets an operator regression-check that an agent build still hits ground truth. Example arguments: {} ### `emem_recall_polygon` (~754 tokens) Recall facts across a place's polygon 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} Input parameters: - `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) ### `emem_field_boundaries` (~413 tokens) Per-field agricultural boundaries (Fields of The World) Per-field agricultural-boundary polygons from the Fields of The World global product (~3.17B fields, 241 countries, 10 m resolution, CC-BY-4.0). Returns a GeoJSON FeatureCollection with the polygon geometries, FIBOA-compatible properties, and a planar `area_m2` per field, plus provenance (source CID, provider URL, license, attribution). When to use: Call when the user asks about farms, fields, parcels, croplands, plots, or agricultural boundaries inside a region, anywhere the OSM/Nominatim boundary alone is too coarse (the OSM polygon for a farm is its estate envelope; this returns the individual field polygons inside). Pass `place` (free-text) or `polygon_bbox`. For farms wider than ~10 km², split the bbox: the fetcher caps each call at 16 covering tiles. The receipt quotes `license: CC-BY-4.0` and `attribution: Fields of The World / Taylor Geospatial Institute`, surface both with any rendered map. For a one-shot "facts at every cell inside the farm PLUS the field polygons", call `emem_recall_polygon` with `include: ["ftw_fields"]` instead. Example arguments: {"polygon_bbox":{"min_lat":36.70,"max_lat":36.74,"min_lng":-119.84,"max_lng":-119.80}} Input parameters: - `place` (string): Free-text place/farm/region name; resolved through the same layered geocoder as /v1/recall_polygon. REQUIRED unless `polygon_bbox` is provided. - `polygon_bbox` (object): Explicit bbox; alternative to `place`. - `zoom` (integer): Web-Mercator zoom level for the FTW PMTiles read. Default = library-picked min(14, archive.max_zoom). Higher zoom = sharper boundaries but more tiles per query (capped internally at 16, split very wi… ### `emem_query_region` (~374 tokens) Aggregate facts over a region 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"} Input parameters: - `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, required): cell64 string, or 'cells:c1,c2,c3' ### `emem_compare` (~139 tokens) Compare two cells (cosine + scalar deltas) Compare two cells: cosine similarity over shared vector bands + per-band scalar deltas. When to use: Call when the user asks 'how similar is X to Y', 'compare these two places', or wants a difference vector. Returns a single cosine score and per-band deltas. Example arguments: {"a":"damO.zb000.xUti.zde78","b":"damO.zb000.xUto.sisA"} Input parameters: - `a` (string, required): cell64 of cell A - `b` (string, required): cell64 of cell B - `family` (string): optional band-key prefix (e.g. 'indices.') ### `emem_compare_bands` (~488 tokens) Compare two bands at one cell Compare two bands at the same cell. Scalar pair → metric=delta, value=b-a. Vector pair (equal dim) → metric=cosine + per-dim delta. Returns a signed receipt naming both source fact CIDs. When to use: Call when the user wants cross-source consistency at one place ('does Cop-DEM agree with GMRT here?'), cross-vintage drift ('how did the embedding change between 2017 and 2024 at this cell?'), or any band-vs-band comparison within a single cell. `cell` + `a` + `b` are required. `tslot_a`/`tslot_b` are OPTIONAL: omit them to let the responder auto-pick each band's latest attested tslot, required for medium/fast-tempo bands (NDVI 30-day, MODIS 8-day, weather, CAMS) where there is no fact at tslot=0. The response carries `tslot_resolution` (echoes what was chosen and why) and `bands_with_no_history` (lists any band the cell has no attested fact for). Example arguments: {"cell":"damO.zb000.wapu.yAxe","a":"copdem30m.elevation_mean","b":"gmrt.topobathy_mean"} Input parameters: - `a` (string, required): band A key (e.g. 'copdem30m.elevation_mean') - `b` (string, required): band B key (e.g. 'gmrt.topobathy_mean') - `cell` (string, required): cell64 (`cell64` accepted as alias) - `predicate` (object): Optional consistency predicate. When set, the response carries a signed `verdict` (true|false|incomparable) over the comparison. - `tslot_a` (integer): tslot for band A. Omit to auto-pick the latest attested tslot for this band at this cell, required for medium/fast-tempo bands (NDVI 30-day, MODIS 8-day, weather, CAMS) which have NO fact at tslot=0.… - `tslot_b` (integer): tslot for band B. Same auto-pick semantics as `tslot_a` when omitted. ### `emem_trajectory` (~392 tokens) Time series for one (cell, band) 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]} Input parameters: - `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, required) - `cell` (string, required) - `window` (array, required): [start_tslot, end_tslot] inclusive ### `emem_diff` (~267 tokens) Signed delta between two tslots Compute a DerivativeFact (delta) between a band's values at two tslots. Algebra: diff. For a time-varying band the response also carries an unsigned `phenology` advisory: the day-of-year of each tslot, their gap, and a `caution` when the two dates sit at different points in the seasonal cycle, because that delta mixes phenology with real change (the '4 prospered / 0 stressed' trap). It surfaces the bias rather than rejecting the call; the advisory never enters the receipt. When to use: Call when the user asks 'what changed between t1 and t2', 'give me the delta'. Returns a signed DerivativeFact + receipt; the delta itself is content-addressed and citable. Read the `phenology` block before treating a seasonal-band delta as change: if `same_doy` is false, compare the same day-of-year across years instead. Example arguments: {"cell":"damO.zb000.xUti.zde78","band":"indices.ndvi","tslot_a":0,"tslot_b":12} Input parameters: - `band` (string, required) - `cell` (string, required) - `tslot_a` (integer, required) - `tslot_b` (integer, required) ### `emem_compare_same_doy` (~480 tokens) Compare a band at the same day-of-year across years Compare a band at the SAME day-of-year across several years, the honest way to measure year-over-year change on a seasonal band. For each year it finds the signed facts bracketing the target day-of-year and linearly interpolates to it, and EXCLUDES years that cannot be bracketed (with a typed reason) rather than extrapolating. This is the primitive the phenology advisory on emem_diff points at: comparing a seasonal band at two different days-of-year mixes phenology with real change (the '4 prospered / 0 stressed' trap), so comparing at one fixed DOY makes a year-over-year delta change rather than season. Interpolated values are model-derived, not directly signed; the bracketing fact_cids are recoverable via emem_trajectory. When to use: Call when the user wants a year-over-year comparison of a seasonal band (NDVI, LST, greenness) and cares that it is change, not season: 'is this field greener than last year', 'compare the July vegetation across 2022-2025'. Pass the day-of-year and the list of years. For a raw two-date delta use emem_diff (and read its phenology block); for the full series use emem_trajectory. BRACKET WIDTH MATTERS: a year is excluded unless the record holds a sample on EACH side of the target day-of-year within that year, so the natural first attempt (a tight window around the date you care about) usually excludes most years. Measured against this responder, plus or minus 21 days failed to bracket at three cells; plus or minus 60 days bracketed reliably. Backfill that wide before comparing, and read the typed exclusion reason rather than the year count. Example arguments: {"cell":"defi.zb572.xoso.zb1ec","band":"indices.ndvi","doy":196,"years":[2023,2024,2025,2026]} Input parameters: - `band` (string, required) - `cell` (string): cell64 or place name - `doy` (integer, required): target day-of-year - `lat` (number) - `lng` (number) - `place` (string) - `years` (array, required): years to compare at that day-of-year ### `emem_edges_recall` (~773 tokens) Recall temporal knowledge-graph edges Read temporal knowledge-graph edges (subj --pred--> obj, valid over [valid_from, valid_to)), bi-temporally filtered, in EITHER direction. Forward (`subj`, direction="out", the default): edges originating at a subject fact. Reverse (`obj`, direction="in"): edges pointing AT a fact, what disagrees-with / supersedes / relates-to it. Returns a signed list of edges plus the distinct neighbour fact CIDs (`objs` for out, `subjs` for in); the receipt commits the returned edge CIDs into its signature preimage. When to use: Call this to read the typed CONNECTIONS of a fact, what disagrees with it, what superseded it, what relates to it, as of a point in time. A plain recall gives you the fact; this gives you how that fact links to others in the memory graph. Ask it when the user says 'what is this related to', 'what replaced this observation', 'why is this value contested', or 'what did this place's relations look like as of date X'. Pick a direction: set `subj` (direction="out") to ask 'what does this fact point at'; set `obj` (direction="in") to ask the REVERSE, 'what disagrees-with / supersedes / points-at this fact'. Set exactly one of subj/obj, an ambiguous or empty request errors honestly rather than returning a silent empty. Pass `as_of_tslot` to get the latest edge per neighbour whose valid interval covers that moment (newer edges shadow older, nothing is deleted); pass `pred` (e.g. `disagrees_with`, `supersedes`) to filter, or omit it (empty string) for every predicate. Tip: a quicker way to get a fact + its outbound edges in one shot is `emem_recall` with include:["edges"]. Follow each edge's `obj`/`subj` with `emem_fetch` to resolve the related fact, or `emem_verify_receipt` to confirm the signature offline. Example arguments: {"subj":"qbq2dy7adyuvozs7s3gqg5jnpkcwq2duegltjyhbxsivuqbpjofq","pred":"replaced_by","as_of_tslot":1767225600} Input parameters: - `as_of_tslot` (integer): Valid-time bound. Returns the latest edge per neighbour whose [valid_from, valid_to) interval covers this tslot; supersession keeps the newest edge. Omit for all edges regardless of valid-time. - `direction` (string): Traversal direction. "out" (default) = subj→objs; "in" = obj→subjs. Inferred from which of subj/obj you set when omitted; an ambiguous (both set) or empty (neither set) request is rejected with an ho… - `limit` (integer): Max edges to return. - `obj` (string): Object fact CID (reverse, direction="in"): edges TERMINATING at this fact ("what points at this fact", what disagrees-with / supersedes / relates-to it) are returned. Set exactly one of `subj` or `ob… - `pred` (string): Predicate filter (e.g. `replaced_by`, `disagrees_with`, `supersedes`, `co_located_with`). Empty string (default) scans every predicate for the anchor fact. - `subj` (string): Subject fact CID (forward, direction="out"): edges ORIGINATING at this fact ("what does this fact point at") are returned. Set exactly one of `subj` or `obj`. ### `emem_fetch` (~276 tokens) Resolve a fact by content-address (CID) Fetch a fact by its content-address (CID). Returns the full signed Primary or Absence fact, the same body served by REST `/v1/facts/{cid}`. Closes the citation loop: any fact_cid surfaced by recall, materialize, attest, or verify can be re-resolved by another agent without REST. When to use: Call whenever you have a `fact_cid` (e.g. from `emem_recall`'s response, an `emem_attest` receipt, an `emem_materializers` outcome, or a citation in another agent's reply) and need the full fact body, its value, unit, sources, signer, signed_at, and derivation. Particularly useful for verifying that a citation a downstream agent gave you actually resolves on this responder. The response is byte-identical across responders for the same CID, the CID itself is the validator. Example arguments: {"cid":"qbq2dy7adyuvozs7s3gqg5jnpkcwq2duegltjyhbxsivuqbpjofq"} Input parameters: - `cid` (string, required): Content-address of any persisted fact (Primary or Absence). Returned by every recall, attest, materialize, and verify call as `fact_cid` / `fact_cids`. ### `emem_backfill` (~701 tokens) Materialize historical facts in a window Materialize and sign every per-tslot fact for one (cell, band) inside a [start_unix, end_unix] window. Returns a signed list of (tslot, fact_cid, status) for each step. Slow but possible, one upstream fetch per tslot, capped by `max_facts`. READ THE COUNT CAREFULLY: `steps[].tslot` is the REQUESTED slot, not the slot the fact landed in. A signed fact carries the SCENE's own tslot, so consecutive request slots routinely share one `fact_cid`, and `materialized_count` counts request slots rather than observations. Sizing a backfill by `materialized_count` will overestimate what the record actually gained: count DISTINCT `fact_cid`s instead. A 24-day window returning `materialized_count: 24` over 10 distinct cids means the sky answered on 10 days, and `emem_trajectory` over the requested tslots will look empty because the facts sit at their real scene dates. When to use: Call when the user wants HISTORY for a fast/medium-tempo band and `emem_trajectory` returned only the latest point. The responder iterates the tslot range derived from the band's tempo, calls the per-tslot historical materializer, signs each result, and persists. After completion `emem_trajectory` over the same window returns the full series. Bands without a historical materializer (e.g. `weather.*` from met.no's nowcast) return `status: "present_only"` for past tslots, check `emem_coverage_matrix.history_available_from`/`history_available_to` to see how far back each band can be backfilled. Prefer this over staking an attestation when the upstream is publicly fetchable. Example arguments: {"cell":"damO.zb000.xUti.zde78","band":"modis.ndvi_mean","start_unix":1640995200,"end_unix":1735689600,"max_facts":24} Input parameters: - `band` (string, required): Band key. Must be a band whose materializer supports historical fetch, see `emem_coverage_matrix` field `history_available_from`/`history_available_to`. - `budget_ms` (integer): Optional soft budget in ms for the preparer form. - `cell` (string, required): cell64 or place name (auto-resolved). - `cells` (array): The preparer form: up to 64 cells, each backfilled across the same band and window under the partial-results contract (budget_ms, pending[], converged). Warm an area before reasoning over it; the ide… - `end_unix` (integer): Window end as Unix epoch seconds (UTC). Defaults to now. - `max_facts` (integer): Cap on number of facts materialized in one call. - `refresh` (boolean): Force re-materialization even where a fact already exists, superseding it (the old fact stays resolvable by cid and as_of_signed_at). Use to pick up a materializer change on already-warmed cells, e.g… - `start_unix` (integer): Window start as Unix epoch seconds (UTC). Defaults to the band's `history_available_from`. ### `emem_heat_solve` (~353 tokens) 2-D heat-equation forecast (urban LST evolution) Forward-step 2-D explicit finite-difference solver for the heat equation ∂u/∂t = α∇²u over a 3×3 cell stencil centred on `cell`. Reads `modis.lst_day_8day` (Land Surface Temperature) at the centre and 8 cell64 neighbours, integrates N hours ahead under a CFL-stable timestep, returns a signed forecast. Real PDE rollout, not a decay-scoring heuristic. When to use: Use when the user wants a short-horizon LST forecast (urban heat island, surface-temperature evolution, heatwave onset modelling) at a specific cell. Default α=1e-6 m²/s matches urban surface diffusivity (Oke 2017); pass a smaller α for water bodies or higher for vegetated surfaces. The solver caps at one-week horizons because the 8-day MODIS composite stops being a representative initial condition past that. Each call materialises 9 MODIS facts (one per neighbour) on miss, first call ~5 s cold, ~30 ms warm. Receipt cites all 9 input fact CIDs. Example arguments: {"cell":"damO.zb000.xUti.zde78","hours_ahead":6} Input parameters: - `cell` (string, required): cell64 string. Forecast LST evolution at this cell. - `diffusivity_m2_per_s` (number): Thermal diffusivity α (m²/s). Default urban surface (Oke 2017 §2.3); use ~5e-7 for vegetation, ~1.4e-7 for water. - `hours_ahead` (number): Forecast horizon in hours; capped at 168 (one week). ### `emem_wave_solve` (~369 tokens) 1-D shallow-water swell propagation to coast 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} Input parameters: - `coastal_cell` (string, required): cell64 of the coastal destination. - `n_offshore_cells` (integer): Cells to sample seaward when building the bathymetric profile. - `offshore_height_m` (number, required): Offshore significant wave height H_s (m). - `period_s` (number, required): Wave period (s); typical wind-wave + swell envelope is 6-18 s. ### `emem_jepa_predict` (~365 tokens) Constrained JEPA-pattern next-month NDVI predictor Predict next-month NDVI at a cell using a constrained JEPA-pattern AR(2) seasonal predictor. Reads up to 24 past months of `indices.ndvi`, fits a closed-form predictor `y_{t+1} = α·(lag-12 NDVI or recent mean) + β·(last + slope) + γ·recent_mean`, returns the prediction clamped to NDVI's physical range. Coefficients (α=0.6, β=0.3, γ=0.1) are NOT learned, they're fixed from the agricultural-NDVI literature. For the learned multi-band dynamics head, see `emem_jepa_predict_v2` (jepa_temporal_predictor@2). When to use: Use when the user wants a one-month-ahead NDVI forecast at a specific cell (crop-stress monitoring, growing-season tracking, vegetation-anomaly anticipation). Lookback defaults to 6 months; if fewer monthly tslots are attested at this cell, the predictor uses what's there and surfaces the count in `lookback_months_used`. Returns 422 if no NDVI history exists at the cell, chain to `emem_backfill` first to seed history. Receipt cites every input NDVI fact CID. Example arguments: {"cell":"damO.zb000.xUti.zde78","lookback_months":6} Input parameters: - `band` (string): Band to forecast. v1 supports 'indices.ndvi' only. - `cell` (string, required): cell64 to forecast at. - `forecast_horizon_months` (integer): Horizon in months ahead. v1 supports 1 only. - `lookback_months` (integer): How many past months of history to read. ### `emem_jepa_predict_v2` (~451 tokens) Learned multi-band-scalar dynamics head (jepa_temporal_predictor@2) 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"} Input parameters: - `cell` (string, required): cell64 to forecast at, or a free-text place name (auto-resolved via /v1/locate). ### `emem_verify` (~140 tokens) Verify a structured claim against a cell 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}} Input parameters: - `cell` (string, required) - `claim` (object, required) - `mode` (string) ### `emem_bands` (~56 tokens) Active band ontology Active band ontology (offsets, dims, tempo, privacy). When to use: Call once at session start to learn the band registry, every other primitive's `band` argument MUST come from this list. Example arguments: {} ### `emem_functions` (~52 tokens) Active function registry Active function registry (derivation recipes). When to use: Call when you need to know which derivative ops are available for `emem_diff` or how a band is computed from upstream sources. Example arguments: {} ### `emem_sources` (~67 tokens) Active source-connector registry 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: {} ### `emem_schema` (~52 tokens) Active CDDL/JSON schema bundle 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: {} ### `emem_errors` (~45 tokens) Stable error code catalog Stable error code catalog. When to use: Call to enumerate the wire-stable error codes, useful when the LLM wants to programmatically branch on responses. Example arguments: {} ### `emem_manifests` (~56 tokens) Active manifest CIDs 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: {} ### `emem_capabilities` (~213 tokens) Cached upstream capability snapshot Live capability snapshot of the responder's GPU sidecar, extensions[] (e.g. gpu, clay-v1.5, prithvi-eo2), cuda_available, models_loaded[], healthy, last_polled_unix_s. Refreshed every 30 s by a background poller; reads are constant-time. When to use: Call before scheduling a GPU-heavy plan (Clay / Prithvi / Galileo embeddings, foundation-anchored algorithms) so the agent knows whether the GPU tier is up *right now* without per-request /health round-trips. Pair with `emem_topics` (its `algorithm_availability` map says which algorithm keys can run given the current capabilities) and `emem_explain_algorithm` (full inference-tier metadata per algorithm). When `extensions[]` is empty the sidecar is unreachable, only CPU/scalar/cached tiers will produce facts; foundation-anchored materializers will sign Absence with `gpu_unavailable` reason. Example arguments: {} ### `emem_grid_info` (~165 tokens) Active grid encoding Active grid encoding: cell64 ground resolution, lat/lng axis sizes, DGGS lineage. When to use: Call once at session start (or when the user asks about cell resolution / 'how big is a cell'). Returns the actual ground resolution today (~9.54 m × 9.55 m square at the equator (lat 21 bits × lng 22 bits, matching Sentinel-1/Sentinel-2 native pixel pitch). The cell64 bit layout reserves a resolution-tag field for future hierarchical refinement targeting H3-equivalent res-13 (~3.4 m) cells in v0.1.) and the spec target. Useful before you reason about whether one cell is enough or whether you need `emem_recall_polygon`. Example arguments: {} ### `emem_cells_in_bbox` (~364 tokens) Enumerate the cell64s in a bounding box, paged Enumerate every cell64 whose centre falls in a bounding box, paged, in stable row-major order (north row first, then west column first). Pure geometry: it reads no facts and signs no receipt, because the answer is a deterministic function of the bbox and the active grid that anyone can reproduce. It walks the integer lat/lng grid directly, so it never skips or double-counts a cell the way a float-stepped lattice does. Returns `cells`, the exact `total`, and `next_cursor` (null when exhausted). This is the paging loop as emem's job instead of every client reimplementing a lattice; a London-scale AOI is tens of thousands of cells, so page it. page_size defaults 1024, caps at 4096. When to use: Call when you need the actual cell list over an area rather than a sample: building a world, a dense recall over an AOI, or a deterministic sample frame. Feed each page's `cells` straight to emem_recall_many with a budget_ms to read them under the partial-results contract, and page with next_cursor until it is null. For a coarse sample (not every cell) emem_query_region or emem_recall_polygon subsample to max_cells instead. Example arguments: {"bbox":{"min_lat":32.5699,"min_lng":77.0328,"max_lat":32.5727,"max_lng":77.0362},"page_size":1024} Input parameters: - `bbox` (object, required): WGS-84 bounding box to enumerate. - `cursor` (integer): row-major offset to resume from; pass the previous response's next_cursor. - `page_size` (integer): cells per page. ### `emem_coverage_matrix` (~221 tokens) Per-band live status & history bounds Per-band live status, what data is alive AND auto-materializable, with history bounds, tempo cadence, and the responder pubkey that signs the band. When to use: Call BEFORE `emem_recall` when you don't know which bands answer at this responder. For each band returns `has_materializer` (true → an empty recall will auto-fetch+sign, no seeding needed), `facts_count` (how many cells already cached), `last_attested_unix_s` (freshness), `tempo_seconds` (slot duration), `history_available_from` / `history_available_to` (oldest/newest Unix epoch the materializer can fetch, use these to bound an `emem_backfill` request), and `responder_pubkey_b32` (the ed25519 key whose signature attests this band, use to detect federation / multi-responder setups). Bands with `has_materializer=false AND facts_count=0` are cube placeholders without a wired connector, don't bother recalling them. Example arguments: {} ### `emem_materializers` (~216 tokens) Auto-fetch registry (per-band materializers) 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: {} ### `emem_data_availability` (~195 tokens) Per-band temporal coverage catalog Temporal catalog: for every materializable band the upstream-of-record window the data genuinely covers, the temporal `kind` (static | annual_snapshot | annual_stack | time_series | now_only | per_release), tempo seconds, upstream wire path, and whether `emem_backfill` is meaningful. When to use: Call before `emem_backfill` or any historical recall to check whether a band has a meaningful past at the requested time. Each entry includes `history_available_from_unix` / `history_available_to_unix` (and ISO strings) plus `backfill_supported`. Use this to avoid trial-and-error 422s on now-only bands (`weather.*`) and to enumerate the per-year `geotessera.YYYY` vintages the responder ships. The catalog is driven by the same registry the recall path consults, so what it lists is exactly what materializes. Example arguments: {} ### `emem_algorithms` (~235 tokens) Composition recipes (algorithms) Content-addressed dictionary of composition recipes, formulas that fuse attested band facts (and embeddings) into derived scores, classifications, and similarity metrics. When to use: Call when the user's question is COMPOSITE (flood risk, urban density, water consensus, change-since-2020) rather than a single band readout. Each entry has `kind` (solo | combined | embedding), the input `bands` (assemble one `emem_recall` body from them), the `formula` in plain math, the `output` shape, and a `citation`. The agent applies the formula in-process and quotes the algorithm key + `algorithms_cid` (from `emem_manifests`) alongside the input fact_cids, that gives the receipt enough context for any other operator to replay the same composition deterministically. Embedding entries (cosine, novelty, change, neighborhood-consistency) operate on `geotessera`; for the most common k-NN pattern the protocol-native `emem_find_similar` is faster than fetching vectors and computing locally. Example arguments: {} ### `emem_explain_algorithm` (~193 tokens) One-algorithm drill-down (formula + inputs + citation) Per-key drill-down on a single composition recipe, full body (kind, inputs, formula, output, citation, references) for ONE algorithm key. Companion to `emem_algorithms` (which is the catalog). When to use: Call when you already know the algorithm key (from `emem_algorithms`'s catalog or the topic registry) and need its full math. Cheaper than fetching the full catalog when you only need one entry. Returns the same structure that `/v1/algorithms/{key}` does. 404s with `cid_not_found` if the key isn't registered, call `emem_algorithms` for the live key list. Example arguments: {"key":"walkability_score@1"} Input parameters: - `key` (string, required): Algorithm key including version suffix, e.g. `walkability_score@1`. Get the live key list from `emem_algorithms`. ### `emem_topics` (~214 tokens) Topic-grouped band + algorithm registry 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: {} ### `emem_coverage_map` (~192 tokens) Coverage map (SVG image) Live SVG render of the responder's corpus density, returned as a proper MCP EmbeddedResource content block (image/svg+xml), multimodal MCP agents can render it natively. When to use: Call when the user asks 'where do you have data?', 'show me the coverage', or wants a visual brief of the responder's corpus footprint. Returns a 1440×720 Plate-Carrée SVG (1° × 1° bins, log-scale colour, continent envelopes for orientation) plus a structuredContent summary (cell_count, total_facts, responder pubkey, REST URL). Multi-content-block reply: an EmbeddedResource (mimeType `image/svg+xml`, with text + uri) followed by a one-line text summary so text-only clients still see the cell / fact counts. For the bare image bytes, fetch `/v1/coverage_map.svg` over plain REST. Example arguments: {} ### `emem_cell_scene_rgb` (~367 tokens) Sentinel-2 true-colour thumbnail (PNG) True-colour Sentinel-2 L2A RGB thumbnail centred on a cell. PNG returned as a native MCP ImageContent block (mimeType image/png). Pure-Rust pipeline: STAC search + HTTP-Range COG reads + 2-98 percentile stretch + PNG encode. When to use: Call when the user wants a VISUAL of a place, 'show me what this looks like', 'before/after the flood', 'is there a forest here', 'is this developed'. Returns a 256×256 px RGB image (~2.56 km × ~2.56 km at S2's 10 m native resolution), centred on the cell. Pass `cell` as a cell64 string OR a place name (auto-resolved). `max_cloud` filters scenes by `eo:cloud_cover` (default 20 %); raise it (60–80 %) for cloud-prone tropics if you keep getting 'no scene' errors. `datetime` is an RFC 3339 interval like `"2024-01-01T00:00:00Z/2024-12-31T00:00:00Z"` for a temporal slice (defaults to last 90 days). `structuredContent` carries the STAC item id, capture time, cloud_cover, EPSG, and per-channel reflectance percentile stretch values used, quote those alongside the image so the receipt is reproducible. Example arguments: {"cell":"damO.zb000.waro.zcb89","max_cloud":20} Input parameters: - `cell` (string, required): cell64 or place name - `datetime` (string): RFC 3339 interval; defaults to last 90 days - `max_cloud` (number): max eo:cloud_cover percent ### `emem_cell_geojson` (~193 tokens) Cell polygon as GeoJSON Cell polygon as a native MCP EmbeddedResource (mimeType application/geo+json). Properties carry centre lat/lng, bbox, approx size in metres, and the 8-cell neighbourhood, drop straight into Mapbox / Leaflet / Deck.gl / QGIS without a GIS pipeline. When to use: Call when the agent (or a downstream renderer) needs the cell as geographic geometry, for map overlays, polygon-clipping ops, or feeding a styling pipeline. Pass `cell` as cell64 or place name. The result is a GeoJSON Feature with Polygon geometry; for a FeatureCollection that includes every recalled fact's value as a property, fetch /v1/cells/{cell64}/recall_geojson?bands=... over plain REST instead. Example arguments: {"cell":"damO.zb000.waro.zcb89"} Input parameters: - `cell` (string, required): cell64 or place name ### `emem_recall_many` (~380 tokens) Bulk recall across up to 256 cells 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.`. NOT one signed envelope: there is no aggregate receipt, and each cell carries its own under `by_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"]} Input parameters: - `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, required): 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. ### `emem_elevation` (~274 tokens) Coherent elevation across Cop-DEM + GMRT + WorldCover One-shot elevation answer that fuses Cop-DEM 30 m (land), GMRT (ocean topobathy), and ESA WorldCover (water mask) into a single signed scalar at a place or coordinate. Returns `elevation_m`, the source actually used, and a `coherence_note` when the two surfaces disagree at the coast. When to use: Use when the user asks 'how high is X' or 'what's the elevation at this lat/lng' and you want the correct answer regardless of whether the cell is land, water, or coastline, the handler picks Cop-DEM for land and GMRT for water and surfaces the choice. Pass `place` (free text), `lat`+`lng`, OR `cell`. Otherwise, prefer emem_recall with `copdem30m.elevation_mean` / `gmrt.topobathy_mean` individually. Example arguments: {"place":"Mount Everest"} Input parameters: - `cell` (string): cell64 string, skip geocoding entirely. - `lat` (number): WGS-84 latitude. - `lng` (number): WGS-84 longitude. - `place` (string): Free-text place name. Resolved through the standard locate cascade. Provide this OR `lat`+`lng` OR `cell`. ### `emem_fleet` (~134 tokens) Satellite / sensor lineage per band Per-band satellite-and-sensor fleet inventory, names the upstream platform (e.g. Sentinel-2A/B, MODIS Aqua/Terra, Landsat-8/9), revisit cadence, native resolution, and license for every materialized band. Lets an agent attribute imagery products correctly and pick the right band when revisit cadence matters. When to use: Call when the user asks 'which satellite is this from', 'what's the revisit time', or needs source attribution for a derived answer. Pair with emem_materializers for the wire path and emem_sources for the connector-level metadata. Example arguments: {} ### `emem_substrates` (~170 tokens) Substrate profile registry 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: {} ### `emem_trace_verify` (~308 tokens) Verify a device's OS execution trace 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"}} Input parameters: - `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, required): Substrate profile ID to verify against (e.g. robot.fleet.v1, orbital.satellite.v1). GET /v1/substrates lists the registry. - `trace` (object, required): The emem.os_trace.v1 record: device identity, chained trace segments, emitted output digests, trace_root, and the device's ed25519 signature. ### `emem_temporal_route` (~341 tokens) Plan a temporal recall recipe for a cell 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"} Input parameters: - `bands` (array): Optional band filter to scope the planner. - `cell` (string, required): 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. ### `emem_at` (~440 tokens) Multi-band snapshot at a place One-shot recall of the signed facts at a place's cell64 (or lat/lng); each band carries a citeable fact_cid. Defaults to emem's standard at-a-glance band set; pass `band` / `bands` to override. Polygon-resolved places stay at the centroid by default (`n_cells: 1`) to keep multi-band calls cheap; pass `n_cells: 2..=64` to fan out. When to use: Use when the user names a place and wants the standard situational readout (vegetation + elevation + landcover + recent weather) without picking bands. Polygon-aware: `place` that resolves to a polygon (park, lake, district) lands at the centroid unless `n_cells` widens it. For a single band, use the domain-specific shortcuts (emem_ndvi, emem_air, …) or emem_recall directly. Example arguments: {"place":"Yellowstone National Park"} Input parameters: - `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). ### `emem_ndvi` (~380 tokens) NDVI at a place (one-shot, polygon-aware) 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"} Input parameters: - `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). ### `emem_air` (~373 tokens) Air-quality snapshot (CAMS PM2.5 / NO2 / O3) Recall the signed Copernicus CAMS air-quality facts (PM2.5 + NO2 + O3) at a place's cell64, attesting on a miss. Composes locate → recall → aggregate; each band carries a citeable fact_cid. When to use: Use when the user names a place and asks about air quality, pollution, or emissions exposure. CAMS is the European reanalysis, global coverage, ~0.4° native (resampled). For finer-grained urban PM2.5, pair with /v1/at-style stations data when available. Example arguments: {"place":"Delhi, India"} Input parameters: - `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). ### `emem_lst` (~341 tokens) Land surface temperature (MODIS day + night) 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"} Input parameters: - `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). ### `emem_soil` (~350 tokens) Soil profile (SoilGrids 0–30 cm: SOC, pH, texture) 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"} Input parameters: - `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). ### `emem_water` (~352 tokens) Surface water (JRC GSW recurrence + S1 backscatter) 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"} Input parameters: - `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). ### `emem_forest` (~357 tokens) Forest signals (Hansen GFC + ESA WorldCover) Recall the signed forest facts at a place's cell64: Hansen Global Forest Change (tree cover 2000 baseline + year-of-loss) + ESA WorldCover 2021 land class, attested on a miss; each carries a citeable fact_cid. When to use: Use when the user asks about deforestation, canopy cover, forest loss, or wants a forest-vs-not classification. Hansen gives year-of-loss for any cell with disturbance since 2001; WorldCover gives the current land class. Example arguments: {"place":"Amazon, Brazil"} Input parameters: - `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). ### `emem_weather` (~348 tokens) Current weather snapshot (temperature, cloud, precip, wind) 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"} Input parameters: - `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). ### `emem_log_sth` (~126 tokens) Transparency log signed tree head 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: {} ### `emem_log_inclusion` (~167 tokens) Transparency log inclusion proof 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} Input parameters: - `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. ### `emem_log_consistency` (~154 tokens) Transparency log consistency proof 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} Input parameters: - `first` (integer, required): Earlier tree size (the STH you pinned). - `second` (integer): Later tree size. Defaults to the current tree size. ### `emem_log_witnesses` (~172 tokens) Transparency log witness co-signatures 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: {} Input parameters: - `tree_size` (integer): Optional filter: only co-signatures recorded at this tree size. ### `emem_reason` (~252 tokens) Compose a prose answer over signed facts (LLM, labelled) 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?"} Input parameters: - `q` (string, required): The plain-language question to reason about. ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/vortx-ai-emem/emem#diagnostics ## Score history - 2026-08-03: 64 - 2026-08-02: 64 - 2026-08-01: 61 - 2026-07-31: 61 - 2026-07-30: 61 - 2026-07-29: 60 - 2026-07-27: 63 - 2026-07-26: 63 ## Links - Remote endpoint: https://emem.dev/mcp - Repository: https://github.com/Vortx-AI/emem - Website: https://emem.dev/ - Changelog RSS feed: https://verifymcp.io/servers/vortx-ai-emem/emem/changelog.xml - Changelog JSON feed: https://verifymcp.io/servers/vortx-ai-emem/emem/changelog.json - HTML version of this page: https://verifymcp.io/servers/vortx-ai-emem/emem