Skip to main content
Glama

emem, the verifiable memory protocol for the physical world

by io.github.Vortx-AI

Resolve place to cell64 + band inventory

emem_locate
Read-onlyIdempotent

Mint the canonical, vendor-neutral address (cell64) for a real-world place: the shared spatial identity every agent resolves to identically, so two models refer to the same ground instead of two descriptions of it. Also returns the topic-grouped inventory of bands and algorithms recallable there. For a first-class OBJECT identity (a bridge, a plot, a named place) rather than a raw cell, use emem_entity. Send EITHER lat+lng as numbers OR a free-text place; coordinates win when both arrive. q, query and name are all accepted spellings of place. A key this schema does not declare is reported in _unrecognised_arguments, so a typo answers about somewhere else rather than erroring.

When to use: Use whenever the input refers to a real-world location and the next step needs the cell64 identifier or wants to know which bands are available before recalling. The response carries data_at_this_cell with three sub-fields: live_bands_by_topic (every band recallable here, grouped by topic such as flood_water_event_window, vegetation_condition, built_up_human_geography), algorithms_for_topic (composition recipes that fuse those bands into named scores), and declared_but_no_materializer_at_this_responder (cube slots reserved without a live connector). For the single-shot path that runs the full chain server-side and returns one packaged answer, use emem_ask instead.

Example arguments: {"place":"Mount Everest"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoAlias for `place`, accepted because OSM/Mapbox/Google Geocoding all use `q`. Provide either this or `place` (or `lat`+`lng`).
latNoWGS-84 latitude in degrees, paired with `lng`. REQUIRED with `lng` unless `place`/`q` is provided.
lngNoWGS-84 longitude in degrees, paired with `lat`. REQUIRED with `lat` unless `place`/`q` is provided.
nameNoAlias for `place`.
placeNoFree-text place name (e.g. 'Mount Everest', 'Tokyo'). REQUIRED unless `lat`+`lng` is provided. Aliases also accepted: `q`, `query`, `name`.
queryNoAlias for `place`.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context: coordinate precedence over free text, alias normalization, the `_unrecognised_arguments` behavior for typos, and the exact `data_at_this_cell` response structure. No contradiction with annotations exists.

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 front-loaded with the core purpose and immediately gives the key selection rule. Subsequent paragraphs cover when to use, response shape, alternatives, and an example without redundancy. Every sentence contributes operational guidance.

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?

Even without an output schema, the description fully explains the return envelope and its three sub-fields, including what each represents. It also covers input alternatives, precedence, alias handling, typo behavior, and alternative tool routing, making it complete for correct invocation.

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?

Schema coverage is 100%, so the schema already documents each parameter. The description adds cross-parameter behavior not present in the schema: coordinates win when both coordinate and text inputs arrive, and it consolidates the alias relationship across q, query, name, and place. This is useful but does not need to repeat per-parameter details.

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 names a precise action and resource: it resolves a real-world place to a canonical cell64 identifier and also returns the band/algorithm inventory for that cell. It explicitly contrasts itself with emem_entity and emem_ask, making sibling differentiation clear.

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?

It provides an explicit 'When to use' section: use it when the input is a real-world location and the next step needs cell64 or band availability. It also names the alternative tools and their selection conditions: emem_entity for first-class object identity, emem_ask for the single-shot full-chain path.

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