Skip to main content
Glama

Compose a signed multi-fact memory bundle

emem_memory_bundle

Bundle multiple (cell, band, time) memory triples into one signed envelope, producing a single content-addressed citation handle that covers all facts and verifies offline.

Instructions

Compose N (cell, band, tslot?) triples into ONE signed envelope. Each triple runs through the standard auto-materialize recall path; the resulting fact_cids are bundled into a content-addressed envelope and the responder signs over the full receipt. The composed bundle_token is emem:bundle:<bundle_cid>, a single rebindable string that cites the whole set. Memory algebra: the merge operation (https://emem.dev/docs/model.html).

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoMulti-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.
purposeNoOptional human-readable purpose string. Included in the bundle_cid preimage so the same triples + different purposes produce distinct CIDs.
triplesYesOne 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.
Behavior5/5

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

The description discloses mutating behavior (readOnlyHint=false) and adds context: the auto-materialize recall path, content-addressed envelope, responder signature over the full receipt, offline verification via /v1/verify_receipt, the 256-triple cap, and the `members`/`resolved` response fields for partial resolution. No contradiction with annotations.

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

Conciseness5/5

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

The description is dense but well-structured, with a leading definition, a 'When to use' subsection, an example, and operational caveats. No word is wasted; even the cap is explained with a rationale. It earns its length.

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?

For a complex tool with nested triples, a 256 limit, partial resolution behavior, and no output schema, the description fully covers purpose, usage, verification, and response characteristics. It even addresses error behavior (typed 400) and round-trip planning, making it self-sufficient for an agent.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains that each triple runs through auto-materialize recall, that bundle_token is `emem:bundle:<bundle_cid>`, and importantly the operational cost model ('token is O(1) in size for any N, but covering N facts costs ceil(N/256) calls'). The example also clarifies the triples array structure.

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 opens with a specific verb+resource: 'Compose N (cell, band, tslot?) triples into ONE signed envelope.' This clearly distinguishes from sibling tools like `emem_memory_token` (singular) and `emem_memory_token_resolve`, as it bundles multiple facts rather than composing or resolving one.

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?

Provides an explicit 'When to use' section: 'Call when the agent wants to cite multiple (place, band, vintage) facts as one handle.' It names the alternative (`emem_memory_token`) and states 'Use this instead of N separate composers when the citation is conceptually one thing,' plus the 256-cap planning advice.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vortx-AI/emem'

If you have feedback or need assistance with the MCP directory API, please join our Discord server