Skip to main content
Glama
Vortx-AI

emem

by Vortx-AI
OverviewSchemaSourceRelated ServersDiscussions(2)Admin
Rust
Remote

Compose a memory_token citation handle

emem_memory_token
Read-onlyIdempotent

Mint a citation handle for a single attested fact, so another agent can resolve the same signed object byte-for-byte instead of a new description.

Instructions

Make a citation handle, emem:fact:<cell64>:<fact_cid> (or :<state_cid>). Any agent or LLM resolves it to the same signed object, byte for byte. Give this one string to another agent instead of a new description of the fact. The tool checks that both parts are not empty and do not contain the : separator. Memory algebra: the cite operation (https://emem.dev/docs/model.html).

When to use: Call this when you need one string that cites a place and an attested fact across messages, agents or tools. Use emem_echo_verify before you publish the value. FOR MANY FACTS, USE emem_memory_bundle. This is a measured result. A token is 83 to 84 characters and 51 LLM tokens. The value it cites is 11 characters and 5.4 tokens on average. Thus N tokens use about 9.5 times the context of the N numbers. A bundle is 38 characters for any N up to 256, and it resolves in one round trip. It costs less than tokens from N=1, and less than the plain values from N=5. Use one token to cite ONE fact that you must verify later.

Example arguments: {"cell":"defi.zb493.xoso.zcb6a","fact_cid":"cxjiu7l54ujzrpnekp24n4534yojpue4mprddbvevnqtti3lh5bq"}

Input Schema

NameRequiredDescriptionDefault
bandNoOptional 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 resolve round-trip.
cellYescell64, neither component may contain `:`.
fact_cidYes52-char base32-nopad-lowercase content-id of the fact (full 32-byte blake3).
observed_onNoThe fact's source capture date (YYYY-MM-DD) as `/v1/recall` reports it in `sources[].captured_at`. Supplied together with `band` it additionally mints the self-describing `descriptor_token`. A wrong date forges nothing: resolve binds the date to the signed fact and answers 409 on a mismatch.

Output Schema

NameRequiredDescriptionDefault
cellYes
docsNo
grammarNoThe token grammar, so the form can be parsed rather than pattern-matched.
fact_cidYes
cell_tokenNoThe address alone, when you mean the place rather than an observation of it.
memory_tokenYesThe citation to paste: emem:fact:<cell64>:<fact_cid>. Copy it verbatim; a hand-assembled token that is one character wrong still reads as a citation and resolves to nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.3.8
    • addedInput schema / properties / observed_on
      Added value: +{
+  "description": "The fact's source capture date (YYYY-MM-DD) as `/v1/recall` reports it in `sources[].captured_at`. Supplied together with `band` it additionally mints the self-describing `descriptor_token`. A wrong date forges nothing: resolve binds the date to the signed fact and answers 409 on a mismatch.",
+  "type": "string"
+}
  2. Changed1 schema field changedv1.3.4
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "cell": {
+      "type": "string"
+    },
+    "cell_token": {
+      "description": "The address alone, when you mean the place rather than an observation of it.",
+      "type": "string"
+    },
+    "docs": {
+      "type": "string"
+    },
+    "fact_cid": {
+      "type": "string"
+    },
+    "grammar": {
+      "description": "The token grammar, so the form can be parsed rather than pattern-matched.",
+      "type": "string"
+    },
+    "memory_token": {
+      "description": "The citation to paste: emem:fact:<cell64>:<fact_cid>. Copy it verbatim; a hand-assembled token that is one character wrong still reads as a citation and resolves to nothing.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "memory_token",
+    "cell",
+    "fact_cid"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changedv1.3.1
    • changedInput schema / properties / cell / description
      Previous value: -"cell64 — neither component may contain `:`."New value: +"cell64, neither component may contain `:`."
  4. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive. Description adds valuable context: byte-for-byte resolution, validation of non-empty parts and no `:` separator, and context-cost tradeoffs. Doesn't fully detail the band/observed_on provenance behavior but schema covers much of it.

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

Conciseness3/5

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

Format and example are well front-loaded, but the token-cost math (83-84 chars, 51 LLM tokens, 9.5x context) is lengthy and arguably belongs in the sibling bundle's description or docs; it dilutes the core call guidance.

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

Completeness4/5

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

Output schema and full param schema carry the detail burden; description gives enough context to call correctly. Minor gap: doesn't explain when to supply the optional band/observed_on together versus alone.

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 documents all four parameters in detail (band, observed_on, cell pattern, fact_cid format). Description adds the `:` separator constraint but little else beyond the schema; baseline 3 applies.

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?

States a specific verb (Make a citation handle) and gives the exact token format `emem:fact:<cell64>:<fact_cid>`. Clearly distinguishes itself from emem_echo_verify and emem_memory_bundle by naming both.

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?

Explicit when-to-use section, names emem_echo_verify before publishing, and routes multi-fact cases to emem_memory_bundle with concrete token-cost reasoning for when each applies.

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

Deploy Server

Other Tools