Skip to main content
Glama

Intent-routed planner

emem_intent
Idempotent

Resolve places, summarize locations, compare cells, detect changes, find similar cells, verify claims, or ask questions with one typed intent that executes the plan and returns the answer immediately.

Instructions

Say what you want in one typed object and get the answer, without choosing a primitive. type is a tagged union: it selects the intent AND decides which other fields are read, so send only the fields its row needs. The plan is EXECUTED in the same call, so you receive the result (the resolved cell64, the similarity, the delta, the verdict), not a list of calls to make yourself.

type | needs | optional | answers where_is | description | | cell64 for a named place what_is_here | cell OR place | description | what is attested at a location is_like | a, b | | cosine similarity of two cells did_change | cell, band, window | | delta for one band over [start,end] tslots find_like | key | k, filter | nearest cells by embedding confirm | claim, cell | | verdict plus the signed facts behind it ask | description | place/cell/lat+lng | free-text question, packaged answer

An unknown or missing type returns a structured needs_intent_type envelope naming the seven values rather than a hard error, so you can correct it on the next turn.

When to use: Call when the user's question maps cleanly onto one of the seven rows above and you would rather state the goal than pick a primitive. Reach past it for anything else: a specific band at a cell is emem_recall, a region is emem_recall_polygon, and a free-text place question with no obvious primitive is emem_ask directly (type:"ask" here just forwards to it). window takes tslots, not dates: get valid ones from emem_trajectory first. A tool this router names but tools/list does not show is NOT a dead end: every one of the 107 dispatches by name at /mcp and /mcp/full, so call emem_trajectory or emem_recall_polygon directly. The core list is 16 to keep the per-request catalog small, not to fence the rest off; emem_tools enumerates them.

Example arguments: {"type":"did_change","cell":"damO.zb000.xUti.zde78","band":"indices.ndvi","window":[20245,20620]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aNois_like only: cell64 of the first place in the pair.
bNois_like only: cell64 of the second place. The answer is a cosine similarity in [-1,1] over the two cells' embeddings.
kNofind_like only: how many neighbours to return. Defaults to the primitive's own default when omitted.
keyNofind_like only: cell64 to search from. Neighbours are ranked by embedding cosine against this cell.
latNoask only: latitude, paired with `lng`, when you want to pin the location by coordinate rather than by name or cell64.
lngNoask only: longitude, paired with `lat`.
bandNodid_change only: which band to test, e.g. "indices.ndvi". One band per call; the answer is a delta over `window`, not a whole-cell diff.
cellNocell64 address, e.g. "damO.zb000.xUti.zde78". Required by did_change and confirm. Optional for what_is_here and ask: supply it to skip geocoding, omit it and give `place` instead.
typeYesWhich question you are asking, and therefore which other fields apply. where_is: name a place, get its cell64 (needs `description`). what_is_here: summarise a location (needs `cell`, OR `place`/`description` to resolve it first). is_like: pairwise similarity (needs `a` and `b`). did_change: did one band move over a time window (needs `cell`, `band`, `window`). find_like: nearest neighbours to a known cell (needs `key`; optional `k`, `filter`). confirm: is a claim true at a cell (needs `claim` and `cell`). ask: free-text question about a place, runs locate + topic-route + recall server-side (needs `description`; optional `place`/`cell`/`lat`+`lng` to pin the location).
claimNoconfirm only: the claim to test at `cell`, e.g. {"band":"indices.ndvi","op":"gt","value":0.4}. The answer is a verdict plus the signed facts it rests on.
placeNoFree-text place name for what_is_here and ask when you have a name but no cell64, e.g. "Ashok Nagar, Ranchi". The responder geocodes it. Ignored when `cell` is present.
filterNofind_like only: optional claim constraining which cells may be returned. Same object as `claim` below, same ops, same required fields.
windowNodid_change only: exactly two tslots, [start, end], band-tempo-relative integers from the emem epoch (NOT unix seconds or a date string). Get valid tslots for a cell from emem_trajectory.
descriptionNowhere_is: the place to resolve, e.g. "Mount Everest". ask: the user's question, forwarded verbatim. what_is_here: optional free text used as the question and, if `place` is absent, as the place. Ignored by the other intents.
Behavior5/5

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

The description reveals that the plan is 'EXECUTED in the same call', going beyond the annotations to explain side effects. It discloses the error envelope for unknown/missing `type`, the forwarding behavior for type:"ask", and the tslot/date distinction. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with a table, clear sections, and a concrete example. The opening sentence front-loads the purpose, and every subsequent sentence adds value. Slightly dense but appropriate for the tool's complexity.

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?

With no output schema, the description takes responsibility for explaining return values: it lists the resolved cell64, similarity, delta, and verdict. It also covers error handling, forwarding, and all seven intents. The description is complete enough for an agent to use this tool effectively.

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?

Even though schema coverage is 100%, the description adds a cross-reference table mapping each `type` to required/optional fields and the answer produced. The example arguments illustrate the expected format. This matrix is not present in the schema and is essential for correctly selecting which fields to send.

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 clear verb+resource: 'Say what you want in one typed object and get the answer, without choosing a primitive.' It then explains the tagged union behavior and distinguishes itself from siblings by naming emem_recall, emem_recall_polygon, and emem_ask as alternatives. The table of seven intents makes the scope explicit.

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?

An explicit 'When to use' section states to call this tool when the question maps to one of the seven rows, and to 'Reach past it for anything else', naming specific alternatives. It also warns that `window` takes tslots not dates and points to emem_trajectory for valid values, and explains that hidden tools are directly callable. 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.

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