Skip to main content
Glama

emem, the verifiable memory protocol for the physical world

Ask a free-text question about a place

emem_ask
Idempotent

Single-shot free-text answer about a real-world location, backed by signed satellite/elevation/water/built-up receipts. Forwards a place mention plus a question; runs the locate → recall → algorithm chain server-side; returns one packaged envelope.

When to use: Use when the question concerns a specific real-world place and a packaged, citation-bearing answer is preferable to manual primitive composition. Forward the user's question verbatim as q plus the location as place (free text), cell (cell64), or lat+lng. The server resolves the location, classifies the question to a topic, recalls every relevant band (auto-materializing Sentinel-2 / Sentinel-1 / Cop-DEM / JRC GSW / Overture / weather on miss), surfaces the algorithm recipes that compose those bands into named scores, and returns a single envelope with topic_routing, facts, algorithms_for_question, an optional Sentinel-2 RGB scene URL, and a caveats block (grid resolution, revisit cadence). All facts are signed by the responder; the signed receipt (and its content-addressed fact_cids) is surfaced at the envelope ROOT, response.receipt / response.fact_cids, exactly like every other primitive, and is also mirrored under facts_summary.receipt for back-compat. Set include_image: true to bundle the latest cloud-free Sentinel-2 thumbnail. Out-of-scope questions return topic_routing.matched_topic: null plus the full inventory so the caller can route elsewhere.

Example arguments: {"q":"is this neighbourhood flood-prone for a flat purchase","place":"Ashok Nagar, Ranchi"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesUser's natural-language question about the place (e.g. "is this neighbourhood flood-prone").
latNoWGS-84 latitude (paired with `lng`; alternative to `place` / `cell`).
lngNoWGS-84 longitude (paired with `lat`).
cellNocell64 string (alternative to `place`, use when you have one from a prior emem_locate / emem_recall response). Provide this OR `place` OR `lat`+`lng`.
modelNoOptional. Compose an EXTRA prose answer with a named model, returned as `model_answer` beside the deterministic `answer`. It does not replace it: `answer` is synthesised from the structured fields and never calls a model, so every number in it traces to a fact_cid, and asking for a model must not turn a checkable answer into an unchecked one. `model_answer` carries provenance.class = model_output. Name it by base_model (`nvidia/Cosmos3-Edge`), by family (`cosmos3_edge`, `gemma`), or by any fragment naming exactly one of them (`cosmos`); a fragment matching several is refused and names them; an unroutable name is refused with the list of routable ones, and a routable model whose service is not answering is refused as busy or down rather than silently substituted. Cosmos deliberates and typically takes 13-22 s.
placeNoFree-text place name (e.g. "Mount Fuji", "Ashok Nagar, Ranchi"). REQUIRED unless `cell` or `lat`+`lng` is provided. Extract the noun phrase from the user's turn; the responder geocodes via OSM Nominatim.
queryNoAlias for `q`.
includeNoOpt-in heavy response sections. Default response is slim (~5 KB): answer + algorithm key + fact_cids + caveats. Name specific sections to include them. Ignored when verbose=true (which includes everything).
verboseNoWhen true, return the full envelope: per-algorithm formula strings, temporal_recipe blocks, per-fact band_metadata duplicates, and the long _explanation prose. Default (since 2026-05-05) is false so the response fits MCP's 25 KB cap; the signed receipt + fact CIDs + algorithm keys + algorithms_cid are always retained. Pass true to get the full body when debugging.
questionNoAlias for `q`.
include_imageNoBundle a Sentinel-2 RGB scene URL for the resolved cell. Adds ~1-2 s on first call.

TDQS

A5/5.0
Behavior5/5

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

The description goes well beyond the annotations. It discloses the server-side processing chain, auto-materialization of bands on miss, the signed receipt placement at the envelope root, caveats (grid resolution, revisit cadence), and the detailed behavior of the `model` parameter (refusal rules, timing, provenance tagging). These are behavioral traits not captured by readOnlyHint/openWorldHint/idempotentHint/destructiveHint, and they are described precisely. 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 carries operational value: purpose, usage, parameter semantics, response envelope, example. It is front-loaded with the core purpose and usage, then details. No fluff—each clause earns its place in supporting correct agent invocation.

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?

Given the tool has 11 parameters, no output schema, and a complex response envelope, the description is complete. It describes the response structure (topic_routing, facts, algorithms_for_question, scene URL, caveats, receipt placement), the out-of-scope behavior, and the forward of parameters. An agent has all needed to call it correctly and interpret results, so nothing critical is missing.

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?

Schema covers all 11 parameters, but the description adds substantial meaning beyond basic types: it explains `model`'s resolution and refusal logic, `include`'s opt-in sections with default response size, `verbose`'s MCP cap rationale, and `include_image`'s latency impact. It also gives example arguments tying `q` and `place` together. This is a high bar for parameter enrichment.

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 pair: 'Single-shot free-text answer about a real-world location' backed by signed receipts. It clearly distinguishes itself from sibling tools by describing the server-side locate→recall→algorithm chain that produces a packaged envelope, vs. the manual primitive composition those siblings would require. This is unambiguous and differentiates from tools like emem_locate or emem_recall.

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' paragraph explicitly states the condition: when the question concerns a specific real-world place and a packaged, citation-bearing answer is preferable to manual primitive composition. It also explains the alternative (manual composition of primitives) and routing when out-of-scope, telling callers to route elsewhere. This is direct guidance with an exclusion condition.

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

Try in Browser

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).