emem

Resolve place to cell64 + band inventory

emem_locate

Read-onlyIdempotent

Resolve a place name or coordinates to its canonical cell64 address, then list bands and algorithms you can recall there by topic.

Instructions

Get the canonical address (cell64) of a real-world place. Every agent resolves a place to the same cell64, so two models refer to the same ground. The answer also lists, by topic, the bands and algorithms that you can recall there. For an OBJECT identity (a bridge, a plot) instead of a cell, use emem_entity. Send lat+lng as numbers, or a free-text place. When both arrive, the coordinates win. q, query and name are other names for place. The answer lists keys that this schema does not declare in _unrecognised_arguments, so a typo is visible.

When to use: Call this when the next step needs the cell64 of a named place, or the bands that exist there. data_at_this_cell lists every band you can recall, by topic (live_bands_by_topic), the recipes that use them (algorithms_for_topic), and the bands with no materializer here. For one packaged answer in one call, use emem_ask.

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

Input 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`.

Output Schema

Name	Required	Description
`next`	Yes
`cell64`	No	Pass as `cell` to emem_recall.
`status`	No	needs_location: no place named.
`selected`	No
`place_label`	No
`data_at_this_cell`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.4.4Oct 19, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "required": [
+        "cell64"
+      ]
+    },
+    {
+      "required": [
+        "status"
+      ]
+    }
+  ],
+  "properties": {
+    "cell64": {
+      "description": "Pass as `cell` to emem_recall.",
+      "type": "string"
+    },
+    "data_at_this_cell": {
+      "type": "object"
+    },
+    "next": {
+      "type": "array"
+    },
+    "place_label": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "selected": {
+      "properties": {
+        "confidence_reason": {
+          "type": "string"
+        },
+        "is_high_confidence": {
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "status": {
+      "description": "needs_location: no place named.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "next"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedv1.3.8Aug 11, 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 changedv1.3.1Aug 4, 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`)."

First observedv0.1.0Jul 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-structured behavior: deterministic resolution ('every agent resolves a place to the same cell64'), input precedence ('when both arrive, the coordinates win'), and that unrecognised keys surface in `_unrecognised_arguments` so typos are visible. It stops short of error/rate-limit behavior, so not a 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?

Front-loaded with the core purpose and an efficient usage block, with a concrete example argument. Slightly verbose: the alias sentence ('q, query and name are other names for place') restates what the 100%-covered schema already documents, which is minor redundancy.

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?

An output schema exists, so return values needn't be enumerated, yet the description still characterizes the answer (bands/recipes by topic). With 6 optional params all documented, annotations covering safety, and precedence plus alias behavior explained, an agent has everything needed to call it correctly.

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 baseline is 3. The description adds a precedence rule absent from the schema (coordinates win over free text when both arrive) and consolidates the alias set, giving an agent information the schema fields do not encode.

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?

States a specific verb+resource: 'Get the canonical address (cell64) of a real-world place', plus what else the answer contains (bands/algorithms by topic). It explicitly distinguishes itself from the sibling emem_entity ('For an OBJECT identity ... instead of a cell, use emem_entity'), so an agent can route without opening either schema.

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?

A dedicated 'When to use' block names the trigger condition (next step needs a cell64 or the bands there) and names two alternatives with their selecting conditions: emem_entity for object identity, emem_ask for a single packaged answer. When-not and alternatives are both explicit.

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

Deploy Server