emem

Compose a signed multi-fact memory bundle

emem_memory_bundle

Idempotent

Combine up to 256 cell, band, and date triples into one signed bundle token that cites every resulting fact as a single handle. Use it when several facts must be verified together offline instead of one call per fact.

Instructions

Combine N (cell, band, tslot?) triples into ONE signed envelope. Each triple goes through the standard recall path, which materializes on a miss. The tool puts the resulting fact_cids in a content-addressed envelope, and the responder signs the full receipt. The bundle_token is emem:bundle:<bundle_cid>: one string that cites the full set. Memory algebra: the merge operation (https://emem.dev/docs/model.html).

When to use: Call this when you must cite several (place, band, date) facts as one handle. You can verify the bundle offline with /v1/verify_receipt. The receipt covers all the cited fact_cids and cells. Use this instead of N calls to emem_memory_token when the citation is one thing. An example is "the EUDR baseline for these 8 plots at 2020-12-31". The limit is 256 triples for each call. The answer gives members and resolved, so you can see a bundle that resolved only in part.

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 Schema

Name	Required	Description
`scope`	No	Multi-tenant scope `{user_id, agent_id, run_id, org_id}`, applied to EVERY triple's underlying recall so the whole bundle cites only facts written under that four-tuple.
`purpose`	No	Optional human-readable purpose string. Included in the bundle_cid preimage so the same triples + different purposes produce distinct CIDs.
`triples`	No	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: the token is O(1) in size for any N, but covering N facts costs ceil(N/256) calls, so plan round trips rather than meeting the cap mid-run.
`fact_cids`	No	Instead of triples: the exact facts to bind, by cid. A triple is resolved through recall and can bind a newer fact than the one you showed; a cid binds that fact and no other. Pass triples or fact_cids, not both.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.4.4Oct 19, 2026

addedInput schema / properties / fact_cids

Added value: +{
+  "description": "Instead of triples: the exact facts to bind, by cid. A triple is resolved through recall and can bind a newer fact than the one you showed; a cid binds that fact and no other. Pass triples or fact_cids, not both.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 256,
+  "minItems": 1,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "triples"
-]
```

Changed1 schema field changedv1.3.8Aug 11, 2026

addedInput schema / properties / scope

Added value: +{
+  "description": "Multi-tenant scope `{user_id, agent_id, run_id, org_id}`, applied to EVERY triple's underlying recall so the whole bundle cites only facts written under that four-tuple.",
+  "type": "object"
+}

Changed2 schema fields changedv1.3.0Jul 27, 2026

changedInput schema / properties / triples / description

Previous value: -"One or more (cell, band, tslot?) triples to bundle. Each entry is recalled through the standard auto-materialize path; the bundle envelope cites every resulting fact_cid."New value: +"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: the token is O(1) in size for any N, but covering N facts costs ceil(N/256) calls, so plan round trips rather than meeting the cap mid-run."

addedInput schema / properties / triples / maxItems
```
Added value: +256
```

First observedv0.1.0Jul 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false; the description's note that each triple goes through recall and 'materializes on a miss' usefully explains the non-read-only side effect. It also discloses the 256-triple cap and that partial resolution is surfaced via `members`/`resolved`, going beyond the annotations, though it does not spell out permission or authorization requirements.

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 and handle format are front-loaded, followed by when-to-use, limits, and an example — a sensible order. It is dense with domain jargon (cell/band/tslot, bundle_cid preimage, memory algebra), which costs a little readability, but no sentence is pure filler.

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?

Despite no output schema, the description covers the return shape ('members' and 'resolved' for partially resolved bundles), the bundle_token format, the 256 cap with a note on round-trip planning, and the offline verification path. For a nested-object, multi-mode tool this is complete enough that an agent can invoke and interpret it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it distinguishes that a triple 'is resolved through recall and can bind a newer fact than the one you showed' while a cid 'binds that fact and no other' (triples vs fact_cids), and supplies worked example arguments. The mutually exclusive triples/fact_cids contract is reinforced rather than merely repeated.

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 first sentence gives a specific verb and resource ('Combine N (cell, band, tslot?) triples into ONE signed envelope'), and the later text explicitly differentiates from the sibling emem_memory_token ('Use this instead of N calls to emem_memory_token when the citation is one thing'). An agent can select this tool over its siblings without opening any 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?

A dedicated 'When to use' block states the trigger condition ('when you must cite several (place, band, date) facts as one handle'), names the alternative it replaces, and gives a concrete example ('the EUDR baseline for these 8 plots at 2020-12-31'). It also points to /v1/verify_receipt for follow-up verification, so the decision path is complete.

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

Deploy Server

Compose a signed multi-fact memory bundle

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools