Skip to main content
Glama

Ask a free-text question about a place

emem_ask
Idempotent

Answer questions about real-world places with cited evidence from satellite, elevation, water, and built-up data. Receive a signed, packaged answer with 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`.
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?

Annotations provide idempotentHint and readOnlyHint=false, but the description adds substantial behavioral context: signed receipts, server-side chain, optional Sentinel-2 thumbnail, response envelope structure, verbose vs default cap, and out-of-scope behavior. No contradictions 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 earns its place, covering purpose, usage, parameters, response behavior, and an example. It is structured with clear subsections and front-loaded with the core definition.

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 no output schema, the description thoroughly explains the return envelope (topic_routing, facts, algorithms, receipt, fact_cids, caveats, include sections). It also covers edge cases like out-of-scope routing and response size limits, making it exceptionally complete.

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?

Despite 100% schema coverage, the description goes beyond by explaining the place/cell/lat+lng alternatives, alias parameters (query/question), include array semantics, verbose default cap, and the trade-off of include_image. It adds actionable value beyond the JSON schema.

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.' It clearly differentiates from sibling tools like emem_locate and emem_recall by emphasizing the packaged, citation-bearing answer and the server-side locate→recall→algorithm chain.

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?

Explicit 'When to use' section states the tool is for questions about a specific real-world place where a packaged answer is preferable to manual primitive composition. It also notes out-of-scope questions return a null topic for routing elsewhere, providing clear usage boundaries.

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