emem, the verifiable memory protocol for the physical world

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: Call when the input names a real-world place and the next step needs its cell64, or wants to know which bands exist there before recalling. data_at_this_cell carries live_bands_by_topic (every recallable band, grouped by topic), algorithms_for_topic (recipes that fuse them into named scores) and declared_but_no_materializer_at_this_responder. For one packaged answer in a single call, use emem_ask.

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

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Alias for `place`, accepted because OSM/Mapbox/Google Geocoding all use `q`. Provide either this or `place` (or `lat`+`lng`).
`lat`	No	WGS-84 latitude in degrees, paired with `lng`. REQUIRED with `lng` unless `place`/`q` is provided.
`lng`	No	WGS-84 longitude in degrees, paired with `lat`. REQUIRED with `lat` unless `place`/`q` is provided.
`name`	No	Alias for `place`.
`place`	No	Free-text place name (e.g. 'Mount Everest', 'Tokyo'). REQUIRED unless `lat`+`lng` is provided. Aliases also accepted: `q`, `query`, `name`.
`query`	No	Alias for `place`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 12, 2026

addedInput schema / properties / name

Added value: +{
+  "description": "Alias for `place`.",
+  "type": "string"
+}

addedInput schema / properties / query

Added value: +{
+  "description": "Alias for `place`.",
+  "type": "string"
+}

Changed1 schema field changedJul 28, 2026

changedInput schema / properties / q / description

Previous value: -"Alias for `place` — accepted because OSM/Mapbox/Google Geocoding all use `q`. Provide either this or `place` (or `lat`+`lng`)."New value: +"Alias for `place`, accepted because OSM/Mapbox/Google Geocoding all use `q`. Provide either this or `place` (or `lat`+`lng`)."

Changed6 schema fields changedApr 30, 2026

removedInput schema / anyOf

Removed value: -[
-  {
-    "required": [
-      "place"
-    ]
-  },
-  {
-    "required": [
-      "q"
-    ]
-  },
-  {
-    "required": [
-      "lat",
-      "lng"
-    ]
-  }
-]

removedInput schema / description

Removed value: -"Resolve a place to a cell64. Provide either `place`/`q` (free text) or both `lat`+`lng`."

changedInput schema / properties / lat / description

Previous value: -"WGS-84 latitude in degrees, paired with `lng`."New value: +"WGS-84 latitude in degrees, paired with `lng`. REQUIRED with `lng` unless `place`/`q` is provided."

changedInput schema / properties / lng / description

Previous value: -"WGS-84 longitude in degrees, paired with `lat`."New value: +"WGS-84 longitude in degrees, paired with `lat`. REQUIRED with `lat` unless `place`/`q` is provided."

changedInput schema / properties / place / description

Previous value: -"Free-text place name (e.g. 'Mount Everest', 'Tokyo'). Aliases: `q`, `query`, `name`."New value: +"Free-text place name (e.g. 'Mount Everest', 'Tokyo'). REQUIRED unless `lat`+`lng` is provided. Aliases also accepted: `q`, `query`, `name`."

changedInput schema / properties / q / description

Previous value: -"Alias for `place` — accepted because OSM/Mapbox/Google Geocoding all use `q`. Resolves the same way."New value: +"Alias for `place` — accepted because OSM/Mapbox/Google Geocoding all use `q`. Provide either this or `place` (or `lat`+`lng`)."

Changed6 schema fields changedApr 30, 2026

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "place"
+    ]
+  },
+  {
+    "required": [
+      "q"
+    ]
+  },
+  {
+    "required": [
+      "lat",
+      "lng"
+    ]
+  }
+]

addedInput schema / description

Added value: +"Resolve a place to a cell64. Provide either `place`/`q` (free text) or both `lat`+`lng`."

changedInput schema / properties / lat / description

Previous value: -"WGS-84 latitude in degrees, paired with `lng`"New value: +"WGS-84 latitude in degrees, paired with `lng`."

changedInput schema / properties / lng / description

Previous value: -"WGS-84 longitude in degrees, paired with `lat`"New value: +"WGS-84 longitude in degrees, paired with `lat`."

changedInput schema / properties / place / description

Previous value: -"Free-text place name (e.g. 'Mount Everest', 'Tokyo')"New value: +"Free-text place name (e.g. 'Mount Everest', 'Tokyo'). Aliases: `q`, `query`, `name`."

addedInput schema / properties / q

Added value: +{
+  "description": "Alias for `place` — accepted because OSM/Mapbox/Google Geocoding all use `q`. Resolves the same way.",
+  "type": "string"
+}

First observedApr 28, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the canonical/vendor-neutral nature of the address, the precedence rule ('coordinates win when both arrive'), the alias acceptance, and the '_unrecognised_arguments' behavior for typos. It doesn't describe the full return shape, but the description explicitly mentions the key return fields (live_bands_by_topic, algorithms_for_topic, declared_but_no_materializer_at_this_responder). This is strong behavioral disclosure.

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?

The description is dense but well-organized: purpose first, then return-value summary, then disambiguation, then parameter semantics, then when-to-use, then example. Every sentence earns its place, though the opening sentence is long and packs many concepts. The 'When to use' section is clearly front-loaded after the core purpose. Slightly verbose but not wasteful.

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?

For a read-only, idempotent tool with 100% schema coverage and no output schema, the description is quite complete. It explains the core return fields, the input alternatives, the precedence rule, and the error behavior for unrecognized arguments. The only minor gap is that it doesn't describe the exact structure of the cell64 or the full response envelope, but the description explicitly names the key return fields. Given the tool's complexity and the absence of an output schema, this is strong coverage.

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 description coverage is 100%, so the schema already documents all 6 parameters. The description adds meaning beyond the schema by explaining the alias relationship ('q, query and name are all accepted spellings of place'), the precedence rule, and the typo-handling behavior. It also gives a concrete example argument. This exceeds the baseline 3 for full schema coverage.

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 states a specific verb ('Mint the canonical, vendor-neutral address (cell64)') and resource ('real-world place'), and explicitly distinguishes itself from emem_entity ('For a first-class OBJECT identity... use emem_entity'). It also names the sibling emem_ask for a different use case. This is a clear, specific purpose that an agent can act on.

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 description gives explicit when-to-use guidance: 'Call when the input names a real-world place and the next step needs its cell64, or wants to know which bands exist there before recalling.' It also names alternatives: emem_entity for object identity, emem_ask for a packaged answer. It even explains the coordinate-vs-place precedence rule. This is exemplary usage guidance.

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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resolve place to cell64 + band inventory

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources