Skip to main content
Glama

Dereference a memory_token in one round-trip

emem_memory_token_resolve
Read-onlyIdempotent

Resolve a memory token citation into the cited fact, returning value, unit, band, kind, fact body, and fact URL—no token parsing or fetch chaining needed.

Instructions

Parse a emem:fact:<cell64>:<fact_cid> citation handle and return the reading it cites. value, unit, band and kind are on the response at the TOP level, alongside the full signed fact body they were lifted from. Saves the agent from string-splitting the token and chaining GET /v1/facts/<cid> manually. Memory algebra: the resolve operation (https://emem.dev/docs/model.html).

When to use: Call when an agent receives a memory_token from another agent (or out of a previous turn) and wants the value behind it. Read value for the reading and unit for what it is measured in; both are always present, and an explicit null means the fact genuinely has none (kind: "absence" has no value, and most index bands including NDVI are dimensionless) rather than that the field is missing. For a scalar, quote value_verbatim instead: it is the same number as the exact decimal string it was signed as, and re-typing a JSON number is where measured precision loss comes from. The response also carries the parsed cell + fact_cid, the full fact body, and the stable fact_url an agent can hand to any other peer. 404 with a typed code if the responder doesn't hold the cid; try /v1/fetch with the cid then, or paste the token at a mirror.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesA `emem:fact:<cell64>:<fact_cid>` citation handle to dereference.
Behavior5/5

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds substantial behavioral context: response top-level fields, the meaning of explicit null for value/unit, the precision nuance with value_verbatim, and the 404 behavior with a typed code. 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 long but every sentence earns its place. It is front-loaded with the core purpose, followed by structured use guidance, response details, error handling, and an example. The inclusion of the 'Memory algebra' link is optional but not wasteful.

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 lacking an output schema, the description fully covers the return shape, field semantics, error cases, and usage context. An agent has everything needed to invoke the tool correctly and interpret the result without additional lookups.

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?

The single parameter `token` has 100% schema coverage, but the description goes further by explaining the token format in the first line and providing a concrete example argument. It also clarifies what the tool returns in relation to the token, which is beyond the schema.

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: 'Parse a `emem:fact:<cell64>:<fact_cid>` citation handle and return the reading it cites.' It clearly distinguishes itself from siblings by explaining it saves the agent from string-splitting and chaining manual GET calls. The title and description align on the same unambiguous purpose.

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?

The 'When to use' section explicitly states when to call this tool: when an agent receives a memory_token from another agent or previous turn and wants the value behind it. It also provides clear alternatives for the failure case (try /v1/fetch or paste at a mirror), and guidance on which fields to read depending on the situation (value/unit vs. value_verbatim).

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