emem
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EMEM_BIND | No | Bind address for the server (default: 0.0.0.0:5051) | 0.0.0.0:5051 |
| EMEM_DATA | No | Path to persistent storage directory (default: ./var/emem) | ./var/emem |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| completions | {} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| emem_toolsA | 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 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 |
| emem_locateA | 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 |
| emem_askA | 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 |
| emem_memory_tokenA | Mint a citation handle, 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_memory_token_resolveA | Parse a 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 |
| emem_memory_bundleA | 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 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_entityA | 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 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 |
| emem_entity_resolveA | 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 When to use: Call BEFORE minting when another agent may already have registered the object, or when you receive a |
| emem_entity_linkA | Record a signed equivalence: bind an alternate label or a stable external id (GERS / OSM / Wikidata) to an existing canonical object so future 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. |
| emem_recallA | 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 When to use: Call after |
| emem_find_similarA | 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. |
| emem_memory_contradictionsA | 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 |
| emem_verify_receiptA | Verify a signed receipt envelope server-side: recomputes the canonical preimage (preimage v1: tagged, length-prefixed segments; receipts without 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 |
| emem_intentA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| flood_history | Long-term flood/inundation history at a place, classified from JRC Global Surface Water v1.4 (1984–2021). |
| air_quality_now | Current PM2.5 / PM10 / NO2 / O3 / SO2 / CO at a place, classified against WHO 2021 AQG ladder. |
| urban_heat | Urban-heat-island assessment from MODIS LST day/night and indices.urban_canopy_index, with cooling-potential note. |
| place_summary | Quick characterisation: landcover (ESA WorldCover), elevation (Cop-DEM), greenness (NDVI), current temperature. |
| compare_places | Cosine similarity over the geotessera 128-D embedding, with dominant-band rationale. |
| forest_loss | Hansen Global Forest Change v1.12 layers: tree cover 2000, year of loss (2001–2024), gain mask. |
| coastal_eutrophication | SDG 14.1.1a coastal-eutrophication first-pass: floating-algae index + chlorophyll proxy + turbidity + SST. |
| carbon_uptake_anomaly | GPP anomaly z-score from MOD17A2H trajectory (current 8-day vs same-DOY climatology). |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| agents.md | Full integration guide: REST + MCP setup for Claude Desktop/Code, Cursor, Cline, OpenAI GPT, plus tool reference and worked examples. |
| spec | Authoritative protocol spec: cell64, tslot, content-addressing, ed25519 receipts, lazy materialization, attestation merkle root. |
| whitepaper | Architecture and math: 1792-D voxel layout, BLAKE3 fact CIDs, ed25519 attestation, agent-native invariants. |
| llms.txt | LLM-optimised summary: when to call which primitive, which bands answer which question, 30-second curl examples. |
| llms-full.txt | Long-form LLM-optimised guide: full band catalogue, every primitive with example payload, error catalogue. |
| agent_walkthroughs | Agent walkthroughs: end-to-end flows for flood-history, urban-heat, similarity, and trajectory questions. |
| temporal | Temporal model: Tempo (Static/Slow/Medium/Fast/UltraFast), tslot mapping, backfill semantics, history bounds. |
| materializers | Materializer playbook: how a band's upstream connector turns into a signed fact, error envelope, no-fallback rule. |
| agent.json | Discovery manifest: operator, surfaces, primitives, policies — what a host platform reads to wire emem in. |
| privacy | Privacy policy of the responder operator (Vortx AI). No PII collected from inbound MCP/REST requests. |
| terms | Terms of service of the responder operator. Apache-2.0 protocol; hosted-instance terms. |
| registry.bands | Full bands manifest keyed by family/topic with units, value_range, interpretation, and per-band dimensions. |
| registry.algorithms | Algorithm registry: formula text, inputs, evaluation AST, accuracy_band, temporal_recipe, citations. |
| registry.sources | Upstream source registry: connector wiring, license, attribution, revisit cadence per source. |
| registry.topics | Topic taxonomy: which bands/algorithms answer which natural-language question. |
| registry.functions | Function registry: per-band recipes that turn raw upstream sources into one signed fact. |
| registry.schema | Active CDDL/JSON schema bundle — describes Receipt, Fact, RecallResp shapes on the wire. |
| corpus.state_stats | Signed snapshot of corpus liveness: distinct_cells, distinct_bands, facts_scanned, top per-band counts. |
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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