Skip to main content
Glama

emem, the verifiable memory protocol for the physical world

by io.github.Vortx-AI

Dereference a memory_token in one round-trip

emem_memory_token_resolve
Read-onlyIdempotent

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.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds substantial context: response fields at TOP level, explicit null semantics for absence/dimensionless values, the precision caveat for value_verbatim, typed 404 behavior, and the stable fact_url. This is far beyond the 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?

Although the description is long, it is densely informative and well-structured: purpose, response semantics, when-to-use, edge cases (null, precision), error handling, and an example. No filler; every sentence earns its place.

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 simple one-parameter tool with no output schema, the description covers the full context: response shape, null handling, precision loss, error codes, fallback routes, and a worked example. It leaves no important gap for an agent selecting or invoking this tool.

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?

The schema describes the single token parameter with 100% coverage, so baseline is 3. The description adds a concrete example argument, explains the token format components (cell64, fact_cid), and details how the parameter is parsed and what response semantics follow, enriching the schema description meaningfully.

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 clearly states the tool 'Parse a emem:fact:... citation handle and return the reading it cites' with a specific verb and resource. It also contrasts with manually chaining GET /v1/facts/<cid>, distinguishing it from sibling tools like emem_memory_token.

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 description provides an explicit 'When to use' section: 'Call when an agent receives a memory_token from another agent... and wants the value behind it.' It also gives fallback advice for 404s (try /v1/fetch or a mirror). However, it does not explicitly name sibling alternatives for when not to use, so it falls just short of a 5.

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

All emem, the verifiable memory protocol for the physical world toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools are sharply distinct, with the entity_* family (mint/resolve/link) and memory_* family (token/bundle/contradictions) explicitly cross-referenced to prevent confusion. The only mild overlap is the verify cluster — emem_echo_verify, emem_verify_receipt, and emem_guard_verdict all touch verification but are well-delineated (value drift vs. cryptographic envelope vs. policy gate) — and emem_intent's type:'ask' row duplicating emem_ask.

Naming Consistency4/5

All tools share the emem_ prefix and snake_case, with systematic sub-families (emem_entity*, emem_memory_token*, emem_verify*) that make relationships predictable. However, the pattern is not uniformly verb_noun: bare nouns (emem_entity, emem_intent, emem_tools, emem_recall) and mixed constructions like emem_echo_verify and emem_find_similar deviate from a single convention.

Tool Count4/5

16 tools is just over the ideal 3-15 range, but the count is deliberate: the server curates a small core loop and provides emem_tools as a discovery meta-tool to reach the broader 108-tool catalog. Each listed tool earns its place in the locate → recall → cite → resolve → verify workflow, so the slight overage feels justified rather than bloated.

Completeness4/5

The full consumption lifecycle is covered: locate (emem_locate), recall (emem_recall), ask (emem_ask), cite (emem_memory_token/bundle), resolve (emem_memory_token_resolve), verify (emem_verify_receipt/echo_verify), with entity identity, contradiction detection, similarity search, and policy guard as extras. Minor gaps exist — emem_diff for pair quantification and emem_recall_polygon for regions are referenced but not in the core list, and there is no write/attest tool (though that appears to be by design for a verifiable memory protocol).

Resources