Skip to main content
Glama

emem, the verifiable memory protocol for the physical world

Find signed facts for a place, as citable sources

search
Idempotent

Search emem's signed corpus and return results shaped as citations: each entry is one signed fact, with an id to dereference, a title naming band, place and the value as signed, and a stable url serving those bytes. Takes a place name, a cell64, or an emem citation handle (a handle returns the one fact it cites). Capped for the wire; the final entry names the cell and the TRUE total. On a cold cell it MATERIALIZES a missing band first, as emem_recall does: fetched upstream, signed, persisted. Hence readOnlyHint false.

When to use: Call first when a question is about a place and the answer must be citable: it turns the question into a list of sources, each of which fetch expands. For a synthesised answer in one call, use emem_ask instead.

Example arguments: {"query":"Trafalgar Square, London"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesA place ('Trafalgar Square, London'), a cell64, or an emem citation (`emem:fact:<cell64>:<fact_cid>`). A citation returns the one fact it cites, so a result handed over by another agent resolves exactly.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYesOne entry per signed fact, plus a final entry for the cell itself carrying the true total, so a capped list still says how much there was.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining why readOnlyHint is false: on a cold cell it materializes a missing band, 'fetched upstream, signed, persisted.' It also discloses the wire cap and the sentinel final entry naming the cell and TRUE total, which are not visible in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is front-loaded with the core behaviorstalemate, then usage guidance, then an example, with no filler. Every sentence contributes either output shape, input semantics, behavioral caveats, or alternative routing.

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 one simple parameter, a rich output schema, and annotations, the description supplies all remaining operational context: when to call it, how to prefer it over emem_ask, what the output looks like, and the important cold-cell materialization side effect. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is a 3, but the description adds an example argument and clarifies behavioral distinctions between the accepted query forms, notably that a citation handle 'returns the one fact it cites.' This enhances what the schema alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Search emem's signed corpus and return results shaped as citations,' and it precisely enumerates the output shape (id, title, url). It also distinguishes itself from siblings by positioning results as citable sources that fetch can expand and emem_ask can synthesize.

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?

It explicitly states when to use the tool: 'Call first when a question is about a place and the answer must be citable.' It also names the alternative: 'For a synthesised answer in one call, use emem_ask instead,' and explains the handle case that returns a single fact. This gives an agent clear routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.