emem

Dereference a memory_token in one round-trip

emem_memory_token_resolve

Read-onlyIdempotent

Resolve a memory token citation handle to return the exact signed value and full fact body it cites without manual splitting or fetching.

Instructions

Read a emem:fact:<cell64>:<fact_cid> citation handle and return the reading that it cites. value, unit, band and kind are at the TOP level of the answer, beside the full signed fact body. You do not split the token or call GET /v1/facts/<cid> yourself. Memory algebra: the resolve operation (https://emem.dev/docs/model.html).

When to use: Call this when you have a memory_token from another agent or an earlier turn and need the value. For a scalar, quote value_verbatim, the exact decimal string that the responder signed. A null value or unit means the fact has none (an absence, or an index with no unit). It does not mean a missing field. A cid that this responder does not hold returns a typed 404. Then try /v1/fetch, or resolve at a mirror.

Example arguments: {"token":"emem:fact:defi.zb493.xoso.zcb6a:cxjiu7l54ujzrpnekp24n4534yojpue4mprddbvevnqtti3lh5bq"}

Input Schema

Name	Required	Description	Default
`token`	Yes	A `emem:fact:<cell64>:<fact_cid>` citation handle to dereference.

Output Schema

Name	Required	Description
`band`	Yes
`cell`	Yes
`kind`	Yes
`unit`	No
`value`	No	Scalars; a vector is in the text's fact.value.
`receipt`	Yes
`fact_cid`	Yes
`fact_url`	No
`value_verbatim`	No
`canonical_token`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.4.4Oct 19, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "band": {
+      "type": "string"
+    },
+    "canonical_token": {
+      "type": "string"
+    },
+    "cell": {
+      "type": "string"
+    },
+    "fact_cid": {
+      "type": "string"
+    },
+    "fact_url": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "receipt": {
+      "type": "object"
+    },
+    "unit": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "value": {
+      "description": "Scalars; a vector is in the text's fact.value.",
+      "type": [
+        "number",
+        "string",
+        "boolean",
+        "null"
+      ]
+    },
+    "value_verbatim": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "canonical_token",
+    "cell",
+    "fact_cid",
+    "band",
+    "kind",
+    "receipt"
+  ],
+  "type": "object"
+}

First observedv0.1.0Jul 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real behavioral context beyond that: null value/unit means an absence rather than a missing field, and a cid not held by this responder yields a typed 404 with a fallback path. It omits auth/permission and rate-limit behavior, so not a full 5.

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 output contract are front-loaded, then usage, then edge cases, then an example — a sensible order with a labeled 'When to use'. It is somewhat long for a one-parameter tool, with mild redundancy between the opening output description and the later null-semantics note, but nearly every sentence carries information.

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?

Given an output schema and full annotations exist, the description still supplies everything an agent needs: what the token is, the trigger for calling it, the shape of the answer, null semantics, and failure handling with a next step. Nothing material for correct invocation is missing.

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% for the single `token` parameter, so the schema already documents it and the baseline is 3. The description reinforces the token's format and supplies a concrete example argument, but adds little semantic meaning beyond what the schema states.

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 opening sentence states a specific verb (read/dereference) and a precise resource (an `emem:fact:<cell64>:<fact_cid>` citation handle) and states the return contract. It is clearly distinguishable from siblings like `emem_memory_token` (minting) and `emem_recall`, and the domain reference to memory algebra anchors it.

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

Usage Guidelines4/5

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

The 'When to use' clause gives a concrete trigger: you have a memory_token from another agent or earlier turn and need the value. It also names fallback alternatives for the 404 case (/v1/fetch, mirror resolution). It does not explicitly contrast with sibling tools such as emem_memory_token or emem_recall, so it stops short of a full routing guide.

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

Deploy Server