Skip to main content
Glama

Recall facts at a cell (auto-materializes on miss)

emem_recall
Idempotent

Retrieve signed facts for a cell64 and band, fetching and signing missing values via registered materializers; returns verifiable fact CIDs you can cite and re-verify.

Instructions

Read the signed facts at a canonical address (cell64). When a band has no fact yet but has a registered materializer, the responder fetches it. A fact_cid names one signed attestation, so you can cite a fact and verify it again. Resolve the cid anywhere and you get the same bytes. A fact_cid is NOT a fingerprint of the observation. The digest includes the responder's key and the time it signed. Thus two responders that measure the same thing make different fact_cids, and a cid resolves only at the responder that signed it. For identity across responders, use emem_entity. Send deterministic:true (or a provenance class list) to keep only facts that you can compute from the cited raw source. In the memory algebra this is ensure(cell, bands), not get: you state what must exist.

When to use: Call this after emem_locate, or with a cell64 or a place name. It returns every Primary fact at that (cell, band, tslot). A band can have no fact but have a materializer. Then the responder fetches the upstream value, signs it, stores it and returns it in the same call. The first call is slow; later calls use the cache. Thus any wired band recalls at any cell on Earth: send bands: [<band>]. materialize_notes lists what the call fetched. Empty notes mean no materializer here.

Example arguments: {"cell":"defi.zb64a.cAzU.zfa27","bands":["weather.temperature_2m","copdem30m.elevation_mean"]}

Input Schema

NameRequiredDescriptionDefault
latNoExplicit latitude, an alternative to `cell`; paired with `lng`.
lngNoExplicit longitude, paired with `lat`.
bandNooptional 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 `band` and `bands` are accepted; if both are given they are merged.
cellYescell64 string, e.g. 'defi.zb64a.cAzU.zfa27'
bandsNooptional band keys to filter, e.g. ['indices.ndvi','geotessera']
placeNoFree-text place name, an alternative to `cell`.
scopeNoOptional 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'} sees only u1's facts, never another tenant's and never globally-written facts) AND the signed receipt binds the scope. Omit (or send {}) for the global, pre-v0.0.8 recall.
tslotNooptional time slot (band-tempo-relative integer offset from emem epoch)
cell64NoAlias for `cell`.
includeNoOpt-in response expansion. include:['provenance'] attaches each fact's tamper-provenance class, which is what `deterministic` and the `provenance` filter select ON: without it you can filter by class and never be told which class a returned fact is. 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 bands with), so an agent learns how stale each reading is in the call that returns it. Advisory only; it does NOT enter the receipt. include:['edges'] attaches each fact's typed temporal edges and threads their CIDs into the receipt. Absent leaves the response byte-identical to the pre-v0.0.9 recall.
provenanceNoTamper-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 attestation (not recomputable). Applied BEFORE the receipt is signed, so the receipt covers exactly the returned facts; `bands_already_attested_at_cell` stays unfiltered so you still see what else exists at the cell.
as_of_tslotNoBi-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_tslot < tslot (rejected with code:`invalid_temporal_bound`).
deterministicNoSugar 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 + human_curated + unclassified). Composable with `provenance` (intersection).
as_of_signed_atNoBi-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:`invalid_signed_at_format`.

Output Schema

NameRequiredDescriptionDefault
factsYesSigned facts at the cell, ordered per fact_order.
receiptYesed25519 receipt over the returned fact_cids. Verify offline; select the rule from its preimage_version. Store and forward it byte-for-byte: preimage_version 2 binds every field it covers, including merkle_proof, so a reshaped receipt reports signature_valid:false on data nobody tampered with.
fact_orderYesThe ordering contract for facts, e.g. tslot_ascending. Stated rather than implied so nothing depends on position by accident.
current_by_bandNoPer band, the fact_cid with the highest tslot: the current reading. Unslotted facts are excluded, since tslot 0 means undated rather than oldest.
materialize_notesNo
bands_already_attested_at_cellNoWhat else is readable here without materialising, so an empty result can be told apart from a wrong band name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.4.4
    • changedInput schema / properties / cell / description
      Previous value: -"cell64 string, e.g. 'damO.zb000.xUti.zde78'"New value: +"cell64 string, e.g. 'defi.zb64a.cAzU.zfa27'"
  2. Changed1 schema field changedv2.2.1
    • changedInput schema / properties / provenance / items / enum
      Previous value: -[
      -  "direct_sensor",
      -  "deterministic_index",
      -  "attested_execution",
      -  "model_output",
      -  "human_curated",
      -  "unclassified"
      -]New value: +[
      +  "direct_sensor",
      +  "deterministic_index",
      +  "estimator",
      +  "attested_execution",
      +  "model_output",
      +  "human_curated",
      +  "unclassified"
      +]
  3. Changed1 schema field changedv1.3.10
    • changedOutput schema / properties / receipt / description
      Previous value: -"ed25519 receipt over the returned fact_cids. Verify offline; select the rule from its preimage_version."New value: +"ed25519 receipt over the returned fact_cids. Verify offline; select the rule from its preimage_version. Store and forward it byte-for-byte: preimage_version 2 binds every field it covers, including merkle_proof, so a reshaped receipt reports signature_valid:false on data nobody tampered with."
  4. Changed4 schema fields changedv1.3.8
    • addedInput schema / properties / cell64
      Added value: +{
      +  "description": "Alias for `cell`.",
      +  "type": "string"
      +}
    • addedInput schema / properties / lat
      Added value: +{
      +  "description": "Explicit latitude, an alternative to `cell`; paired with `lng`.",
      +  "type": "number"
      +}
    • addedInput schema / properties / lng
      Added value: +{
      +  "description": "Explicit longitude, paired with `lat`.",
      +  "type": "number"
      +}
    • addedInput schema / properties / place
      Added value: +{
      +  "description": "Free-text place name, an alternative to `cell`.",
      +  "type": "string"
      +}
  5. Changed3 schema fields changedv1.3.3
    • changedInput schema / properties / include / description
      Previous value: -"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 bands with), so an agent learns how stale each reading is in the call that returns it. Advisory only; it does NOT enter the receipt. include:['edges'] attaches each fact's typed temporal edges and threads their CIDs into the receipt. Absent leaves the response byte-identical to the pre-v0.0.9 recall."New value: +"Opt-in response expansion. include:['provenance'] attaches each fact's tamper-provenance class, which is what `deterministic` and the `provenance` filter select ON: without it you can filter by class and never be told which class a returned fact is. 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 bands with), so an agent learns how stale each reading is in the call that returns it. Advisory only; it does NOT enter the receipt. include:['edges'] attaches each fact's typed temporal edges and threads their CIDs into the receipt. Absent leaves the response byte-identical to the pre-v0.0.9 recall."
    • changedInput schema / properties / include / items / enum
      Previous value: -[
      -  "freshness",
      -  "edges"
      -]New value: +[
      +  "freshness",
      +  "edges",
      +  "provenance"
      +]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "bands_already_attested_at_cell": {
      +      "description": "What else is readable here without materialising, so an empty result can be told apart from a wrong band name.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "current_by_band": {
      +      "description": "Per band, the fact_cid with the highest tslot: the current reading. Unslotted facts are excluded, since tslot 0 means undated rather than oldest.",
      +      "type": "object"
      +    },
      +    "fact_order": {
      +      "description": "The ordering contract for facts, e.g. tslot_ascending. Stated rather than implied so nothing depends on position by accident.",
      +      "type": "string"
      +    },
      +    "facts": {
      +      "description": "Signed facts at the cell, ordered per fact_order.",
      +      "items": {
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "materialize_notes": {
      +      "items": {
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "receipt": {
      +      "description": "ed25519 receipt over the returned fact_cids. Verify offline; select the rule from its preimage_version.",
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "facts",
      +    "receipt",
      +    "fact_order"
      +  ],
      +  "type": "object"
      +}
  6. Changed6 schema fields changedv1.3.1
    • changedInput schema / properties / as_of_signed_at / description
      Previous value: -"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:`invalid_signed_at_format`."New value: +"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:`invalid_signed_at_format`."
    • changedInput schema / properties / as_of_tslot / description
      Previous value: -"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_tslot < tslot (rejected with code:`invalid_temporal_bound`)."New value: +"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_tslot < tslot (rejected with code:`invalid_temporal_bound`)."
    • changedInput schema / properties / band / description
      Previous value: -"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 `band` and `bands` are accepted; if both are given they are merged."New value: +"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 `band` and `bands` are accepted; if both are given they are merged."
    • changedInput schema / properties / deterministic / description
      Previous value: -"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 (model_output + human_curated + unclassified). Composable with `provenance` (intersection)."New value: +"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 + human_curated + unclassified). Composable with `provenance` (intersection)."
    • changedInput schema / properties / provenance / description
      Previous value: -"Tamper-provenance filter: return only facts whose band's provenance class is in this list. Applied BEFORE the receipt is signed, so the receipt covers exactly the returned facts; `bands_already_attested_at_cell` stays unfiltered so you still see what else exists at the cell."New value: +"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 attestation (not recomputable). Applied BEFORE the receipt is signed, so the receipt covers exactly the returned facts; `bands_already_attested_at_cell` stays unfiltered so you still see what else exists at the cell."
    • changedInput schema / properties / provenance / items / enum
      Previous value: -[
      -  "direct_sensor",
      -  "deterministic_index",
      -  "model_output",
      -  "human_curated",
      -  "unclassified"
      -]New value: +[
      +  "direct_sensor",
      +  "deterministic_index",
      +  "attested_execution",
      +  "model_output",
      +  "human_curated",
      +  "unclassified"
      +]
  7. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, idempotentHint=true, openWorldHint=true — and the description supplies the missing 'why': a miss triggers an upstream fetch that is signed and stored, explaining both the write behavior and the first-call latency, while later calls hit cache. It also discloses that materialize_notes reports what was fetched and that empty notes mean no materializer. Remaining gap is modest: it doesn't spell out auth/permission requirements for materialization or failure modes on unfetchable bands.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in sentence one, followed by a labeled 'When to use:' section and a concrete example call, which is strong structure. It is long and dense, with the fact_cid digression ('A fact_cid is NOT a fingerprint of the observation...') sitting between purpose and usage, but that length is largely justified by a 14-parameter, bi-temporal tools surface.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, and it correctly focuses on selection semantics: cell vs. aliases, scope filtering behavior, materialization-on-miss, and the provenance/deterministic interaction. For a 14-parameter tool with nested scope and bi-temporal bounds, the description gives the agent enough to choose inputs and anticipate side effects in a single call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already carries the parameter burden and the baseline is 3. The description does add cross-parameter meaning the schema states only in fragments — that deterministic is sugar over provenance (direct_sensor + deterministic_index), that the two compose as an intersection, and that a fact_cid is responder-key-bound rather than a fingerprint of the observation — but it does not walk the parameter set or clarify the cell/lat/lng/place/cell64 alias precedence beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a precise verb+resource: 'Read the signed facts at a canonical address (cell64)', and immediately pins the semantics as 'ensure(cell, bands), not get'. It distinguishes itself from siblings by name — emem_locate as the upstream step and emem_entity for cross-responder identity — so an agent can tell it apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It has an explicit 'When to use:' block ('Call this after emem_locate, or with a cell64 or a place name'), and it routes the agent away when the intent is different ('For identity across responders, use emem_entity'). It also explains the miss path (materializer fetches, signs, stores, returns in the same call) so the agent knows to expect the slow first call rather than retrying.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.