emem, the verifiable memory protocol for the physical world
Server Details
Shared, verifiable memory for AI agents and robots: signed tokens that resolve and verify offline.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Vortx-AI/emem
- GitHub Stars
- 46
- Server Listing
- emem
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 14 of 14 tools scored. Lowest: 3.2/5.
Tools have distinct purposes: location (emem_locate, emem_entity), fact recall (emem_recall), citation (emem_memory_token), and high-level query (emem_ask). Some overlap between emem_ask and manual composition, but descriptions clarify when to use each.
All tools use snake_case and start with 'emem_'. Most follow a verb_noun or noun_verb pattern, though a few (emem_entity, emem_intent, emem_tools) are noun-only but still clear. No mixed styles.
14 tools is well-scoped for a complex Earth memory protocol covering location, identity, facts, citations, verification, and similarity search. Each tool earns its place without being excessive.
The tool set covers the full workflow: locate, entity, recall, tokenize, bundle, verify, find similar, and high-level ask. Metadata tools (emem_locate inventory, emem_tools) fill gaps, making the surface complete for the domain.
Available Tools
15 toolsemem_askAsk a free-text question about a placeARead-onlyIdempotentInspect
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"}
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | User's natural-language question about the place (e.g. "is this neighbourhood flood-prone"). | |
| lat | No | WGS-84 latitude (paired with `lng`; alternative to `place` / `cell`). | |
| lng | No | WGS-84 longitude (paired with `lat`). | |
| cell | No | cell64 string (alternative to `place` — use when you have one from a prior emem_locate / emem_recall response). Provide this OR `place` OR `lat`+`lng`. | |
| place | No | Free-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. | |
| include | No | Opt-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). | |
| verbose | No | When 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. | |
| include_image | No | Bundle a Sentinel-2 RGB scene URL for the resolved cell. Adds ~1-2 s on first call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: the server-side chain, auto-materialization of bands on miss, signed receipts with fact_cids at root, default slim response, the effect of verbose and include_image on latency and size, and the envelope structure. No contradictions with annotations. Misses details on error handling or rate limits, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but verbose, with several long paragraphs. The first sentence is a good summary, but the detailed breakdown of the process, response structure, and parameter nuances could be more concise. For a tool of this complexity, the length is partly justified, but it could be structured more efficiently with bullets or shorter sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the return envelope: topic_routing, facts, algorithms_for_question, optional scene URL, caveats, receipt, fact_cids. It covers default slim response vs verbose, behavior for out-of-scope questions, and the location resolution process. Given the tool's complexity (8 parameters, server-side chain), this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description enriches parameters by explaining that cell64 comes from prior emem_locate/emem_recall, place is geocoded via Nominatim, include array enum options are listed, verbose default respects MCP cap, and include_image adds latency. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Ask a free-text question about a place' and the first sentence clearly state the tool's function: single-shot free-text answer backed by signed receipts. It distinguishes itself from siblings by emphasizing a packaged, citation-bearing answer versus manual primitive composition, and by mentioning the server-side locate→recall→algorithm chain, which is unique among the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 specific real-world places when a packaged answer is preferred over manual composition. It provides guidance on parameter selection (q verbatim, place/cell/lat+lng) and explains how to handle out-of-scope questions (topic_routing.matched_topic: null with full inventory to route elsewhere). This clearly delineates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_echo_verifyCheck a value against the fact it cites, before you publish itARead-onlyIdempotentInspect
Grade a value you are about to emit against the signed fact your citation points at. Returns matches and, when it does not, the drift between what you were about to say and what emem holds. This is the step that turns a transcription error into a caught event instead of a silent wrong number: a model that resolves a fact correctly can still retype 0.2411 for 0.241103, and nothing else in the loop notices. Algebra: verify.
When to use: Call immediately before publishing, logging, or handing on any value you took from an emem fact, and treat a false matches as a gate rather than a warning. Pair it with value_verbatim from resolve: quote that exact decimal string rather than reformatting the number, then echo-verify what you actually emitted. For a due-diligence or compliance record this is what lets you assert every cited value was echo-verified with a signed check per citation instead of a promise. Accepts a bare cid too, so a damaged citation still grades rather than failing closed.
Example arguments: {"token":"emem:fact:defi.zb572.xoso.zb1ec:2p6sz3pv45ndkyqstir4nd6bjnzx63rrcb4pnhgahsnb2oczh5aq","claimed_value":"-0.0558"}
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The citation you used. Any form resolve accepts, including a bare cid (answers degraded). | |
| strict | No | Require BYTE-IDENTICAL equality. Default false, which also accepts a numerically equal value spelled differently (0.50 for 0.5). | |
| claimed_value | Yes | The value you are about to publish, as a string or a number. A string is compared verbatim first, which is what catches a retype a float comparison would forgive. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description expands on these by explaining the tool catches retype errors, accepts bare cid for degraded answers, and returns matches and drift. No contradictions, and it adds valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: it starts with the core function, then provides usage guidance, and ends with an example. Every sentence adds value without repetition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values ('matches and drift') and the behavior when matching fails. It covers all necessary aspects for an agent to use the tool correctly, including edge cases like bare cid and strict mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds context: explains strict default is false, that claimed_value can be string or number, and that a string is compared verbatim first. This additional meaning justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool grades a value against a signed fact, returning matches and drift. The title 'Check a value against the fact it cites, before you publish it' is specific and aligns with the description. It distinguishes from sibling tools like emem_verify_receipt by focusing on pre-publish verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'When to use: Call immediately before publishing, logging, or handing on any value you took from an emem fact' and advises to treat false matches as a gate. It also recommends pairing with value_verbatim from resolve and provides example arguments, giving clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_entityMint or get a canonical object identityAIdempotentInspect
Give a real-world object (a bridge, a farm plot, a river, a named place) a single, shared, content-addressed identity that any agent resolves the same way. Returns an entity_token (emem:entity:<entity_cid>) plus a signed receipt that attests how the reference resolved. Two agents that name the same object mint the SAME entity_cid; when a stable external id (Overture GERS / OSM) is known it dominates identity, so divergent labels for one real object still collapse to one id. This is the object-level antidote to referential drift: 'the damaged bridge near the river' becomes one canonical thing every model reasons about, not a phrase each model re-interprets.
When to use: Call when a conversation refers to a THING and you want a stable handle to it that survives summarization and travels between agents/turns/LLMs, before it drifts into 'that infrastructure issue'. Anchor it with place, a cell, or lat+lng. Hand the returned emem:entity: token to any other agent; they dereference the identical object. Recall/ask at the entity's cell64 for signed facts about it.
Example arguments: {"label":"Golden Gate Bridge","kind":"bridge","place":"Golden Gate Bridge, San Francisco"}
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| cell | No | cell64 to anchor the object directly (no geocode). | |
| kind | No | Object class: bridge, river, farm_plot, building, admin_division, place, custom, ... Defaults to "place". | |
| label | Yes | Human name of the object, e.g. "Golden Gate Bridge", "the north dam". Required. | |
| place | No | Free-text place to anchor the object (geocoded). Provide place OR cell OR lat+lng. | |
| parent | No | Optional parent entity_cid (containment). | |
| external_ids | No | Stable ids that drive convergence. Caller-supplied values win over geocoder-derived ones. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, openWorldHint=true, etc. The description adds key behavioral details: same object yields same entity_cid, external IDs dominate identity, and it returns a signed receipt. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main action, explanation, and usage guidance. It is slightly verbose but every sentence adds value. Could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, 1 required, no output schema), the description is quite complete. It explains the return value, anchoring methods, identity convergence, and when to use, making it sufficient for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (missing descriptions for lat and lng). The description adds context for parameters like cell, place, external_ids, explaining their roles in anchoring and convergence. This compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gives a real-world object a content-addressed identity, returning an entity_token and receipt. It distinguishes from siblings by explaining it's the 'antidote to referential drift' and mentions specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' paragraph that explains the context for calling this tool, and suggests anchoring methods. However, it doesn't explicitly state when not to use or compare directly to sibling tools like emem_entity_link or emem_entity_resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_entity_linkAttest that a phrasing/id denotes an existing objectAIdempotentInspect
Record a signed equivalence: bind an alternate label or a stable external id (GERS / OSM / Wikidata) to an existing canonical object so future emem_entity_resolve calls on that phrasing converge to the same entity_cid. Builds the shared reference graph that keeps different agents' vocabularies pointing at one identity.
When to use: Call when you learn that two phrasings denote the same object ('the north dam' == an existing entity), or to attach an authoritative external id to an object minted from free text.
Example arguments: {"entity_token":"emem:entity:0a1b2c3d4e5f60718293","alias":"the north dam"}
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | An alternate label/phrasing that should resolve to this object. | |
| entity_cid | No | The canonical object to attach an equivalence to. Provide entity_cid OR entity_token. | |
| entity_token | No | A `emem:entity:<entity_cid>` handle for the same. | |
| external_ids | No | Stable ids to bind to this object. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, destructiveHint=false. Description adds context about building the shared reference graph and future resolution convergence. No contradictions, but could detail signing mechanism or side effects more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear paragraphs: first explains what, second explains when. No wasted words, though the first sentence is slightly long. Well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the long-term effect (future resolution convergence) but does not describe immediate outcome or error scenarios. Missing some completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the relationship between parameters (alias vs external_ids, entity_cid vs entity_token) and their role in the equivalence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record a signed equivalence: bind an alternate label or a stable external id ... to an existing canonical object.' It uses specific verbs and specifies the resource, distinguishing it from siblings like emem_entity_resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section provides clear context: 'Call when you learn that two phrasings denote the same object ... or to attach an authoritative external id.' It could mention when not to use, but overall gives strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_entity_resolveResolve a phrase (or emem:entity: token) to a canonical objectARead-onlyIdempotentInspect
Converge a fuzzy phrasing onto the canonical object other agents already minted, so everyone co-refers to the same identity instead of re-minting divergent ones. Pass text (e.g. "the collapsed span at the ford") to get ranked existing candidates; pass near to narrow to a place; or pass an emem:entity: token to dereference it directly to the signed entity body. Read-only.
When to use: Call BEFORE minting when another agent may already have registered the object, or when you receive a emem:entity: token and want the object behind it. This is how two agents avoid referential drift: resolve first, mint only if nothing matches.
Example arguments: {"text":"the golden gate bridge","near":"San Francisco"}
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Max candidates (default 10). | |
| near | No | Optional place/cell to narrow to objects anchored nearby. | |
| text | No | Fuzzy phrasing to resolve to an existing canonical object (e.g. "the damaged bridge near the river"). | |
| label | No | Alias for `text`. | |
| token | No | A `emem:entity:<entity_cid>` handle to dereference directly to its signed object (bypasses the text search). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'Read-only' and explains two operational modes (fuzzy search vs token dereference) and the 'near' narrowing behavior. However, it lacks details on failure modes or response shape when no match is found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs with no wasted words. The first paragraph explains the core function and parameters, the second gives usage guidance. Information is front-loaded and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers when and how to use the tool. It explains the two use cases clearly. However, it does not mention what happens if no match is found or how candidates are ranked, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by explaining how 'text' and 'label' are aliases, how 'token' bypasses search, and the purpose of 'near'. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Resolve' and the resources 'canonical object' and 'entity body', with specific actions ('Converge', 'dereference'). It distinguishes itself from siblings like emem_entity and emem_entity_link by explaining the role in avoiding referential drift.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section advises calling BEFORE minting and when receiving a token. It provides clear context: 'resolve first, mint only if nothing matches', which helps the agent decide when to invoke this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_find_similark-NN over the corpus by embeddingARead-onlyIdempotentInspect
k-NN over the corpus by cell embedding or inline vector.
When to use: Call when the user asks 'find places like X', 'where else looks like this', or hands an embedding to find neighbours. key is either a cell64 or inline:[x,y,...]. Default band is geotessera (128-D Tessera foundation embedding); pass band: "geotessera.multi_year" for the 1152-D 9-vintage (2017–2025) fusion.
Example arguments: {"key":"damO.zb000.xUti.zde78","k":10}
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| key | Yes | cell64 (look up that cell's vector) or 'inline:[x,y,...]' literal vector | |
| band | No | vector band to scan (default: 128-D Tessera foundation embedding). For mode=hamming/hamming_then_rerank you can pass either the cosine band (e.g. 'geotessera') or its binary sibling ('geotessera.bin128') — the responder picks the right one. | geotessera |
| mode | No | Scoring mode. cosine = fp32 over full vector (precise, ~256 B/cell scan). hamming = sign-bit popcount over the binary sibling band (~16 B/cell, ~1000× faster, ~65% recall@10). hamming_then_rerank = triage with Hamming on 4·k candidates then re-rank by cosine — matches cosine precision at ~16× less work. | cosine |
| as_of_tslot | No | Bi-temporal valid-time bound. Applied to candidate cells BEFORE cosine scoring — a cell with no fact whose tslot ≤ as_of_tslot under the scoring band is dropped from the candidate pool (undecidable→drop). When set, the Lance ANN fast-path is bypassed (the index has no signed_at column); brute-force k-NN runs instead so as_of is honoured truthfully. | |
| as_of_signed_at | No | Bi-temporal transaction-time bound (RFC 3339). Also applied to candidates BEFORE cosine. Same Lance-bypass note as as_of_tslot. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds valuable behavioral details: mode performance trade-offs, bi-temporal filtering bypassing ANN, and default band. This significantly aids invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive: usage guideline followed by parameter specifics. No redundant information, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of output format (e.g., returned cell IDs or scores). Given no output schema, the description should clarify what the tool returns. Otherwise, strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description enriches schema with practical meaning: key format distinction, multi-year band option, mode performance numbers, and as_of bypass notes. This is critical for correct parameter setting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs k-NN over the corpus using cell embedding or inline vector, which is specific and actionable. It distinguishes from siblings by focusing on embedding similarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' scenarios like 'find places like X', which helps the agent decide. However, it does not mention when not to use or explicitly compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_intentIntent-routed plannerBRead-onlyIdempotentInspect
Submit a typed Intent; receive a plan or executed result.
When to use: Call when the user asks something like 'where is X' or 'is A like B' and you don't want to pick a primitive yourself — the planner maps Intent variants to the right tool call.
Example arguments: {"type":"what_is_here","cell":"damO.zb000.xUti.zde78"}
| Name | Required | Description | Default |
|---|---|---|---|
| a | No | ||
| b | No | ||
| k | No | ||
| key | No | ||
| band | No | ||
| cell | No | ||
| type | Yes | ||
| claim | No | ||
| window | No | ||
| description | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, openWorldHint, idempotentHint, non-destructive. Description adds only that it returns a 'plan or executed result', which is minimal but consistent. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably short, but critically fails to explain parameters. It front-loads purpose, but conciseness is not an excuse for omission of essential parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no parameter descriptions, the definition is severely incomplete. The agent cannot know how to fill parameters like 'claim' (object) or 'window' (array).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 10 parameters with 0% description coverage. The description only mentions 'typed Intent' relating to the 'type' enum, leaving the other 9 parameters (a, b, k, key, band, cell, claim, window, description) completely unexplained. The description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: submit an Intent and get a plan or result. It distinguishes itself from siblings by indicating it avoids manual primitive selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance with concrete examples ('where is X', 'is A like B') and contrasts with picking primitives directly, making it easy for the agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_locateResolve place to cell64 + band inventoryARead-onlyIdempotentInspect
Mint the canonical, vendor-neutral address (cell64) for a real-world place: the shared spatial identity every agent resolves to identically, so two models refer to the same ground instead of two descriptions of it. Also returns the topic-grouped inventory of bands and algorithms recallable there. For a first-class OBJECT identity (a bridge, a plot, a named place) rather than a raw cell, use emem_entity.
When to use: Use whenever the input refers to a real-world location and the next step needs the cell64 identifier or wants to know which bands are available before recalling. The response carries data_at_this_cell with three sub-fields: live_bands_by_topic (every band recallable here, grouped by topic such as flood_water_event_window, vegetation_condition, built_up_human_geography), algorithms_for_topic (composition recipes that fuse those bands into named scores), and declared_but_no_materializer_at_this_responder (cube slots reserved without a live connector). For the single-shot path that runs the full chain server-side and returns one packaged answer, use emem_ask instead.
Example arguments: {"place":"Mount Everest"}
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| place | No | Free-text place name (e.g. 'Mount Everest', 'Tokyo'). REQUIRED unless `lat`+`lng` is provided. Aliases also accepted: `q`, `query`, `name`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds the response structure (three sub-fields) and clarifies input alternatives, going beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with three concise paragraphs: primary purpose, usage and response details, and alternative tool reference. No wasted words, front-loaded with core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description comprehensively details the response (three sub-fields) and input constraints, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds clarification on parameter combinations (e.g., 'Provide either this or place or lat+lng'), which is not explicit in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool mints a canonical cell64 address and returns band inventory, explicitly distinguishing itself from sibling tools like emem_entity and emem_ask.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section explains the appropriate context (real-world location, need for cell64 or band inventory) and directs to alternatives (emem_ask for full chain, emem_entity for object identity).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_memory_bundleCompose a signed multi-fact memory bundleARead-onlyInspect
Compose N (cell, band, tslot?) triples into ONE signed envelope. Each triple runs through the standard auto-materialize recall path; the resulting fact_cids are bundled into a content-addressed envelope and the responder signs over the full receipt. The composed bundle_token is emem:bundle:<bundle_cid>, a single rebindable string that cites the whole set. Algebra: merge.
When to use: Call when the agent wants to cite multiple (place, band, vintage) facts as one handle. The bundle stays verifiable offline via /v1/verify_receipt (the receipt covers all cited fact_cids and cells). Use this instead of N separate emem_memory_token composers when the citation is conceptually one thing (e.g. "the EUDR-relevant baseline for these 8 plots at 2020-12-31"). Caps at 256 triples per call, and the response reports members and resolved so a bundle that only partly resolved is visible without walking every citation.
Example arguments: {"triples":[{"cell":"defi.zb4d9.pefa.zf619","band":"copdem30m.elevation_mean"},{"cell":"defi.zb493.xoso.zcb6a","band":"indices.ndvi"}],"purpose":"audit baseline 2026"}
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | No | Optional human-readable purpose string. Included in the bundle_cid preimage so the same triples + different purposes produce distinct CIDs. | |
| triples | Yes | One to 256 (cell, band, tslot?) triples to bundle. Each entry is recalled through the standard auto-materialize path; the bundle envelope cites every resulting fact_cid. 257 or more is a typed 400: the token is O(1) in size for any N, but covering N facts costs ceil(N/256) calls, so plan round trips rather than meeting the cap mid-run. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds context about the bundle being verifiable offline via /v1/verify_receipt and that the receipt covers all cited fact_cids and cells. However, it does not significantly add beyond what annotations convey, and the readOnlyHint is consistent with the compose action. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the main action in the first sentence. However, the phrase 'Algebra: merge.' is cryptic and could be omitted or explained. The 'When to use' section is clear. Overall, it is well-structured but could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (composing multiple facts into a bundle) and good annotations, the description adequately explains the output format (bundle_token) and verification path. There is no output schema, but the description covers the return value implicitly. It provides sufficient context for the agent to understand what the tool does and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds that the 'purpose' parameter is included in the CID preimage to produce distinct CIDs, and that each triple runs through the standard auto-materialize path. This adds some nuance but does not deeply enrich understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Compose N (cell, band, tslot?) triples into ONE signed envelope.' It specifies the verb 'compose' and resource 'triples into a signed envelope'. The title also states 'Compose a signed multi-fact memory bundle', and the tool distinguishes itself from siblings like 'emem_memory_token' and 'emem_memory_bundle_resolve' in the usage guidelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'When to use' section: 'Call when the agent wants to cite multiple (place, band, vintage) facts as one handle. Use this instead of N separate emem_memory_token composers when the citation is conceptually one thing.' This clearly specifies when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_memory_contradictionsScan for multi-attester disagreementARead-onlyIdempotentInspect
Surface where the corpus DISAGREES with itself (algebra: competing evidence). When two or more independent sources signed different values for the same place + band + time, this returns that disagreement with a 0–1 severity score and citations to every disputed fact, instead of silently picking one value and hiding the conflict. The opposite of a confident single answer: it tells you when not to trust one.
When to use: Call this when trust matters before you rely on a number — 'is there disagreement about X', 'do the sources corroborate this', 'audit this claim', or 'find contradictory observations in region Y'. Use it to decide whether a fact is well-corroborated or contested. Narrow with cell_prefix (e.g. "defi.zb5") for a region and band for one family; min_severity filters out trivial differences. Severity is per band kind: scalar = spread over the band's range, vector = 1 − mean cosine, categorical = 1 − mode share. The receipt cites every disputed CID — follow up with emem_diff to quantify a pair, or (with the refinement loop on) read the emitted disagrees_with edge via emem_edges_recall.
Example arguments: {"cell_prefix":"damO","band":"indices.ndvi","min_severity":0.2}
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | Band key filter (e.g. `indices.ndvi`). Omit to include all bands. | |
| limit | No | Max contradictions to return. | |
| cell_prefix | No | Bytewise prefix on cell64 (e.g. `defi.zb5f9`). Omit to scan the whole corpus up to the scan cap. | |
| min_severity | No | Severity floor in [0, 1]. 0 = report every disagreement, 1 = only flagrant. Severity scoring is per band kind: scalar (max-min over band range), vector (1 - mean cosine), categorical (1 - mode share). | |
| window_unix_s | No | [lo, hi] inclusive Unix-seconds filter on attestations' signed_at — all disagreeing attestations must fall in the window. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: severity computation per band kind, that it returns citations to disputed CIDs, and that it does not silently pick a single value. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loading the core purpose and usage guidance. The second paragraph adds parameter context. Every sentence earns its place, though it could be slightly shorter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains what is returned (severity score, citations to every disputed fact, receipt with CIDs). It covers the tool's purpose, when to use it, parameter usage, and follow-up actions. No gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 enriches parameter understanding by explaining severity scoring per band kind in context, clarifying that cell_prefix is a bytewise prefix, and describing the window filter. This adds meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool surfaces disagreements in the corpus when multiple sources have conflicting values for the same place, band, and time. It uses a specific verb ('surface') and resource ('disagreement'), and distinguishes itself from siblings by mentioning follow-up tools like emem_diff and emem_edges_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call this tool: 'when trust matters before you rely on a number'. It provides example queries ('is there disagreement about X', 'audit this claim') and explicitly recommends alternatives (emem_diff, emem_edges_recall) for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_memory_tokenCompose a memory_token citation handleARead-onlyIdempotentInspect
Mint a citation handle, emem:fact:<cell64>:<fact_cid> (or :<state_cid>), that any agent or LLM resolves to the byte-identical signed object. The antidote to referential drift on the value side: hand this one string to another agent instead of re-describing the fact. Validates both components are non-empty and free of the : separator. Algebra: cite.
When to use: Call when the agent wants a single rebindable string to cite a place plus an attested fact across messages, threads, agents, or tools, without re-fetching or re-describing it. Pair with emem_verify_receipt on the receiving end to check the signed payload. To cite an OBJECT rather than a single reading, use emem_entity's emem:entity: token. FOR MANY FACTS, USE emem_memory_bundle INSTEAD, and this is a measured cost rather than a style preference: a token is ~104 characters while the signed value it points at averages ~18, so N individual tokens cost roughly 5.8x the context of simply pasting the N numbers, and an N-token prompt hits the context wall SOONER than the plain values would. A bundle is 38 characters at ANY N up to 256 and resolves in one round trip. Individual tokens are for citing ONE fact you must be able to verify later; they are the wrong tool for carrying a set.
Example arguments: {"cell":"defi.zb493.xoso.zcb6a","fact_cid":"cxjiu7l54ujzrpnekp24n4534yojpue4mprddbvevnqtti3lh5bq"}
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | Optional band key. When set, the minted citation carries the band's tamper-provenance block (class, deterministic, tamper_evidence, trust_rank) so the receiving agent sees the trust class without a resolve round-trip. | |
| cell | Yes | cell64 — neither component may contain `:`. | |
| fact_cid | Yes | 52-char base32-nopad-lowercase content-id of the fact (full 32-byte blake3). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds valuable context about validation (non-empty, no colons) and the concept of 'referential drift', which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into two clear paragraphs: one for the core functionality and format, and another for usage guidance. It is concise with no unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations, the description covers all essential aspects: purpose, return value (implicitly), validation, and usage context. No output schema is needed as the result is a simple string.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so each parameter is already documented. The description provides some additional semantics (e.g., band optional explanation, fact_cid format) but does not significantly add beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mint a citation handle' and specifies the exact format (emem:fact:<cell64>:<fact_cid>). It distinguishes itself from sibling tools like emem_entity and emem_memory_bundle by noting when to use those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is an explicit 'When to use' section that explains the tool's purpose (creating a rebindable string for citing a place and fact across contexts). It also mentions pairing with emem_verify_receipt and provides alternatives for citing objects or multiple facts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_memory_token_resolveDereference a memory_token in one round-tripARead-onlyIdempotentInspect
Parse a emem:fact:<cell64>:<fact_cid> citation handle and return the signed fact body the cid binds. Saves the agent from string-splitting the token and chaining GET /v1/facts/<cid> manually. Algebra: resolve.
When to use: Call when an agent receives a memory_token from another agent (or out of a previous turn) and wants the underlying signed bytes. The response carries the parsed cell + fact_cid, the full fact body, and the stable fact_url an agent can hand to any other peer. 404 with a typed code if the responder doesn't hold the cid; try /v1/fetch with the cid then, or paste the token at a mirror.
Example arguments: {"token":"emem:fact:defi.zb493.xoso.zcb6a:cxjiu7l54ujzrpnekp24n4534yojpue4mprddbvevnqtti3lh5bq"}
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | A `emem:fact:<cell64>:<fact_cid>` citation handle to dereference. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: response contents (parsed cell, fact_cid, fact body, fact_url) and 404 error behavior. Annotations already cover read-only and idempotent, so description supplements well but could detail more edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise with front-loaded main action and a separate usage paragraph. Minor extra phrases like 'Algebra: resolve' are acceptable but not essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, return values, and error handling for a simple tool. Lacks explicit response structure but sufficient given one parameter and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 100% schema coverage; description reinforces format but adds minimal extra meaning beyond schema. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'dereference' and the resource 'memory_token', with specific format details. Distinguishes from siblings by explaining it saves manual chaining of GET calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section and post-failure guidance to try /v1/fetch or a mirror. Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_recallRecall facts at a cell (auto-materializes on miss)ARead-onlyIdempotentInspect
Read the signed facts at a canonical address (cell64); auto-materializes on a miss for any band with a registered materializer. A fact_cid names one signed attestation, so a recalled fact is citeable and re-verifiable rather than a paraphrase: resolving it anywhere returns those exact bytes. It is NOT a fingerprint of the observation. The digest covers the responder's key and the moment it signed, so two responders that measure the same thing mint different fact_cids and a cid resolves only at the responder that signed it; use emem_entity for identity that crosses responders. Pass deterministic:true (or a provenance class list) to keep only facts recomputable from the cited raw source, with no model or human in the loop. In the memory algebra this is ensure(cell, bands), not get: state what must exist and the responder reuses or materializes.
When to use: Call after emem_locate (or with a known cell64). Returns every Primary fact stored at that (cell, band, tslot). IMPORTANT: if the cell has no fact yet for a requested band AND that band has has_materializer=true (per emem_coverage_matrix / emem_materializers), the responder fetches the upstream value, signs it under its identity, persists it, and returns it in the same response (slower on the first call while the upstream is fetched; fast once cached). So for any wired band you can recall ANY cell on Earth without seeding, just pass bands: [<band>]. The response carries materialize_notes listing what was just fetched. Empty result with no notes means the band has no materializer at this responder.
Example arguments: {"cell":"damO.zb000.xUti.zde78","bands":["weather.temperature_2m","copdem30m.elevation_mean"]}
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | optional single band key — convenience alias for bands:[band]. Use when you want exactly one band (e.g. 'geotessera.2020', 'modis.ndvi_mean') and would otherwise have to wrap it in an array. Both `band` and `bands` are accepted; if both are given they are merged. | |
| cell | Yes | cell64 string, e.g. 'damO.zb000.xUti.zde78' | |
| bands | No | optional band keys to filter, e.g. ['indices.ndvi','geotessera'] | |
| scope | No | Optional multi-tenant scope {user_id, agent_id, run_id, org_id}. When at least one field is set, the recall is FILTERED to facts written under the same four-tuple (a recall scoped to {user_id:'u1'} sees only u1's facts, never another tenant's and never globally-written facts) AND the signed receipt binds the scope. Omit (or send {}) for the global, pre-v0.0.8 recall. | |
| tslot | No | optional time slot (band-tempo-relative integer offset from emem epoch) | |
| include | No | Opt-in response expansion. include:['freshness'] attaches an advisory per-fact freshness block: a Q(Δt) staleness score from the band's physics decay kernel (the same one /v1/temporal_route ranks bands with), so an agent learns how stale each reading is in the call that returns it. Advisory only; it does NOT enter the receipt. include:['edges'] attaches each fact's typed temporal edges and threads their CIDs into the receipt. Absent leaves the response byte-identical to the pre-v0.0.9 recall. | |
| provenance | No | Tamper-provenance filter: return only facts whose band's provenance class is in this list. Applied BEFORE the receipt is signed, so the receipt covers exactly the returned facts; `bands_already_attested_at_cell` stays unfiltered so you still see what else exists at the cell. | |
| as_of_tslot | No | Bi-temporal valid-time bound. Returns the latest fact per (cell,band) whose tslot ≤ as_of_tslot — answers `what did this place look like AS OF date X`. Conflicts with an explicit `tslot` when as_of_tslot < tslot (rejected with code:`invalid_temporal_bound`). | |
| deterministic | No | Sugar over `provenance`: true keeps only facts any third party can recompute from the cited raw source (direct_sensor + deterministic_index); false keeps the rest (model_output + human_curated + unclassified). Composable with `provenance` (intersection). | |
| as_of_signed_at | No | Bi-temporal transaction-time bound. RFC 3339 string. Returns only facts whose `signed_at` ≤ as_of_signed_at — answers `what did emem KNOW as of system-date Y`. Malformed strings are rejected with code:`invalid_signed_at_format`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, but description adds critical behavioral details: auto-materialization on miss, fact_cid properties (citeable, not a fingerprint), deterministic vs. provenance filter interaction, and response structure (materialize_notes). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and front-loaded with key points, but slightly verbose in some sections (e.g., repeat of materialization logic). Still concise given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, nested objects, and no output schema, the description covers behavior, error conditions (conflict, malformed strings), and expected response artifacts (materialize_notes). Sufficiently complete for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning: explains deterministic as sugar over provenance, documents conflict between as_of_tslot and tslot, details include options, and describes scope filtering behavior. Goes well beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reads signed facts at a canonical address and auto-materializes on miss. It distinguishes from siblings like emem_entity by noting that fact_cid resolution is responder-specific and recommends emem_entity for cross-responder identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call after emem_locate or with a known cell64. Explains when materialization occurs and its latency impact. Advises using emem_entity for identity across responders. Provides context on deterministic filtering and provenance constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_toolsWhat tools exist here, and when to reach for eachARead-onlyIdempotentInspect
The map of emem's tool surface, and the only tool you need to find the rest. Returns the working loop in the order you walk it (name a thing, ground it, cite it, resolve it, verify it, check for drift), then every other tool grouped by the question it answers, each with its one-line trigger. Pass name to get one tool's full input schema and a runnable example, so you can use a tool without loading all of the descriptors into context. This endpoint advertises the core loop only; the Earth-observation, search, embedding and log tools are catalogued here and remain callable by name.
When to use: Call this FIRST when you do not know which emem tool answers the question, or when you need a capability you cannot see in your tool list. This responder advertises a small core loop by default rather than its full catalog, so a tool being absent from your list does not mean it is absent from the server. Pass q to search by topic (ndvi, cloud, flood, verify), name for one tool's exact schema, or no arguments for the whole map. If you want the full catalog registered as callable tools instead, reconnect to the /mcp/full endpoint; for a one-shot answer without picking a primitive at all, use emem_ask.
Example arguments: {"q":"ndvi"}
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text filter over tool names, titles and trigger text, e.g. `ndvi`, `cloud`, `flood`, `verify`, `token`. | |
| name | No | Return the full descriptor for exactly this tool (input schema, runnable example, annotations), e.g. `emem_ndvi`. Use this when you already know the name and want its schema without loading the whole catalog. | |
| tier | No | Which slice to list. Defaults to `all`, so this tool shows the whole surface even when the endpoint advertises only the core loop. | |
| shape | No | Filter by what the answer looks like, which is usually the real question. `scalar` is one number at one address; `raster` is a gridded field over an area; `timeseries` is a value per timestep; `vector` is a learned embedding; `identity` is a canonical name for a thing; `token` is a citation handle; `proof` checks one. | |
| bundle | No | Filter by the job you are doing. Call with no arguments first to see each bundle and its size. | |
| category | No | Filter to one category. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, destructiveHint false. The description adds behavioral context: it advertises a small core loop by default, using parameters to access full catalog, and notes that a tool absent from the list does not mean it is absent from the server. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose (three paragraphs) but well-structured: purpose, usage, and alternatives. Each sentence adds value, though some could be tightened. Front-loading is good with the core purpose in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, many siblings), the description covers all necessary aspects: purpose, when to use, parameter semantics, return value description (map of tools), and related tools/endpoints. It provides a complete mental model for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, but the description adds significant semantic value: explains how to use each parameter (e.g., 'filter by what the answer looks like' for shape, 'filter by job you are doing' for bundle) and when to pass no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is 'the map of emem's tool surface' and 'the only tool you need to find the rest.' It distinguishes itself from siblings by being the discovery tool and explains the core loop vs full catalog, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use ('Call this FIRST when you do not know which emem tool answers the question'), with detailed parameter usage (q, name, tier, shape, bundle, category) and clear alternatives (emem_ask for one-shot, /mcp/full for full catalog).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emem_verify_receiptServer-side ed25519 receipt verifierARead-onlyIdempotentInspect
Verify a signed receipt envelope server-side: recomputes the canonical preimage (preimage v1: tagged, length-prefixed segments; receipts without preimage_version verify under the legacy request_id | served_at | primitive | cells, | fact_cids, concatenation), runs ed25519 over the embedded pubkey + signature, and returns {valid, reason, pubkey_b32}. Use when the in-browser /verify path is blocked (CDN offline, agent runtime has no crypto) or when you want a server-side audit of a third-party receipt. Algebra: verify.
When to use: Pass a receipt object exactly as returned by any read primitive (signature can be byte[] or sig_b32; pubkey can be byte[] or responder_pubkey_b32 — the verifier tolerates both shapes). Optionally override pubkey_b32 to assert verification against a specific signer. Returns 200 with valid: false when the signature fails — never 4xx for a structurally-well-formed bad signature.
Example arguments: {"receipt":{"primitive":"recall","served_at":"2026-05-14T12:00:00Z","request_id":"req-1","cells":["damO.zb000.xUti.zde78"],"fact_cids":["qbq2dy7adyuvozs7s3gqg5jnpkcwq2duegltjyhbxsivuqbpjofq"],"signature":[1,2,3],"responder_pubkey":[4,5,6]}}
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The signed receipt envelope (as returned by any read primitive). Must carry primitive/served_at/request_id/cells/fact_cids and either `signature` byte[] + `responder_pubkey` byte[] or their b32 string forms. | |
| pubkey_b32 | No | Optional explicit responder pubkey (base32). When omitted, uses the receipt's embedded pubkey/responder fields. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format `{valid, reason, pubkey_b32}`, error behavior (200 with valid:false, never 4xx for well-formed bad signatures), and the preimage computation details. Annotations already indicate readOnly, idempotent, non-destructive, so the description adds valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides usage guidelines and details. While informative, it is somewhat lengthy with technical details (preimage versioning) that may be beyond the immediate needs. Still, no extraneous sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (cryptographic verification, nested receipt object), the description covers when to use, parameter details, behavioral outcomes, and return format. No output schema exists, so the description compensates by explaining the result structure. Completely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already describes parameters. The description adds value by explaining the receipt object's required fields (primitive/served_at/request_id/cells/fact_cids) and the tolerance for byte[] or b32 string forms, which is not explicit in the schema. This justifies above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Verify a signed receipt envelope server-side' and explains the verification process. Distinguishes from siblings by specifying 'server-side ed25519 receipt verifier' and mentions alternative paths like in-browser verify. The verb 'verify' and resource 'receipt' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when in-browser /verify is blocked or for server-side audit of third-party receipts. Also describes what to pass and provides optional override guidance. This helps the agent decide between this and other verification tools (e.g., emem_verify).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.