Skip to main content
Glama

Ask a free-text question about a place

emem_ask
Idempotent

Ask a question about a specific place and receive an answer backed by satellite, elevation, water, and built-up data, complete with signed evidence receipts and caveats.

Instructions

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.
Behavior5/5

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

Despite annotations already covering readOnlyHint/destructiveHint/idempotentHint, the description adds substantial behavioral context beyond those: the server-side resolve/classify/recall chain with auto-materializing bands, the signed receipt structure at the envelope root, the caveats block surfacing grid resolution and revisit cadence, and the default slim response size (~5 KB) under MCP's 25 KB cap. It also discloses that `verbose` expands the response, and that the deterministic answer never calls a model.

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 long and information-dense, but every sentence serves a purpose: usage, parameter interplay, return structure, edge cases, and version-flavored behavior. It is front-loaded with the core purpose, though the middle section is dense and could be organized more tightly. For a tool with 11 parameters and a complex envelope, the length is justified over conciseness.

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's complexity — 11 parameters, a rich multi-band response envelope, fabricated facts, signed receipts, aliases, and output-size control — the description is remarkably complete. It covers parameter resolution order, opt-in heavy sections, output shape, error behaviors (unroutable model, out-of-scope question), and performance caveats (image adds 1-2 s, Cosmos 13-22 s). No output schema exists, so the description rightly carries the burden of return-value disclosure.

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 baseline is 3. The description adds meaningful semantics beyond the schema: how `place` is geocoded (OSM Nominatim), the mutual exclusivity of location parameters (`cell`, `place`, `lat`+`lng`), the behavior and risks of `model` (including refusal rather than silent substitution), and the distinction between `answer` and `model_answer`. It doesn't fully explain every enum value in `include`, but that's the schema's job.

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 ('Single-shot free-text answer about a real-world location') and differentiates the tool from a manual primitive composition by describing the server-side locate → recall → algorithm chain. It clearly distinguishes it from siblings like emem_locate, emem_recall, and emem_entity by stating it returns a packaged, citation-bearing answer envelope for a specific location plus question.

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 explicitly states when to use it ('Use when the question concerns a specific real-world place and a packaged, citation-bearing answer is preferable to manual primitive composition') and explains how to forward parameters ('Forward the user's question verbatim as `q` plus the location as `place`...'). It also addresses out-of-scope behavior with `topic_routing.matched_topic: null`, giving the agent clear routing guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vortx-AI/emem'

If you have feedback or need assistance with the MCP directory API, please join our Discord server