Skip to main content
Glama

emem, the verifiable memory protocol for the physical world

Scan for multi-attester disagreement

emem_memory_contradictions
Read-onlyIdempotent

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. Read the SCOPE before quoting a zero: by default this asks only whether two DISTINCT attesters disagree, so one responder answering an address from two different upstreams is not counted until you pass include_same_attester_sources: true.

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. On a single-responder deployment add include_same_attester_sources: true: the likeliest real disagreement there is one signer answering from two different providers, and the default scope cannot report it. Each record names its disagreement_scopemulti_attester is two witnesses, same_attester_provider_substitution is one witness that changed instruments. 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}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bandNoBand key filter (e.g. `indices.ndvi`). Omit to include all bands.
limitNoMax contradictions to return.
cell_prefixNoBytewise prefix on cell64 (e.g. `defi.zb5f9`). Omit to scan the whole corpus up to the scan cap.
min_severityNoSeverity 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_sNo[lo, hi] inclusive Unix-seconds filter on attestations' signed_at, all disagreeing attestations must fall in the window.
include_same_attester_sourcesNoAlso report keys where ONE attester answered the same address from two different upstreams. Default false, which scans only for disagreement between two or more DISTINCT attesters — so on a single-responder corpus a zero here means the narrower question was answered, not that nothing disagrees. Set true and a key qualifies when the facts differ in `derivation.fn_key` or in their `sources[].scheme` set; the same provider re-signed is a refresh, not a disagreement, and stays excluded. Each record carries `disagreement_scope` and a `providers[]` list naming what changed.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description discloses critical behavioral nuances: the default scope excludes same-attester sources, the zero result means something specific, severity is computed differently per band kind, and single-responder deployments need a different flag. This adds substantial context not present in annotations, and there is no contradiction.

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

Conciseness5/5

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

The description is long but well-structured: purpose first, then usage, then an example. Every sentence adds meaningful information or useful nuance, and it never repeats empty phrases. The text is front-loaded with the core behavior and includes a punchy summary ('The opposite of a confident single answer') that efficiently communicates intent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately describes return values (severity, citations, `disagreement_scope`, providers) and covers edge cases (single-responder deployments, same-attester sources). It also references follow-up tools, making the description complete for a tool with this complexity and parameter count.

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?

The input schema already covers 100% of parameters with rich descriptions, so the baseline is 3. The description adds extra value by giving example arguments (`{"cell_prefix":"damO",...}`), explaining how `cell_prefix` and `band` narrow the scan, and providing a conditional usage note for `include_same_attester_sources`. While some param details overlap with schema, the example and contextual guidance push it above baseline.

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 crystal-clear verb+resource: 'Surface where the corpus DISAGREES with itself', then elaborates with return details (0-1 severity score, citations) and contrasts with the opposite behavior ('instead of silently picking one value'). This fully differentiates it from sibling tools like emem_recall or emem_ask, which answer with a single confident value.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'When to use' section lists concrete triggers ('trust matters', 'is there disagreement', 'audit this claim') and even states the alternative follow-ups ('emem_diff', 'emem_edges_recall'). It also warns against misinterpreting a zero result and instructs when to set `include_same_attester_sources: true`, leaving no doubt about proper invocation context.

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.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools are sharply distinct, with the entity_* family (mint/resolve/link) and memory_* family (token/bundle/contradictions) explicitly cross-referenced to prevent confusion. The only mild overlap is the verify cluster — emem_echo_verify, emem_verify_receipt, and emem_guard_verdict all touch verification but are well-delineated (value drift vs. cryptographic envelope vs. policy gate) — and emem_intent's type:'ask' row duplicating emem_ask.

Naming Consistency4/5

All tools share the emem_ prefix and snake_case, with systematic sub-families (emem_entity*, emem_memory_token*, emem_verify*) that make relationships predictable. However, the pattern is not uniformly verb_noun: bare nouns (emem_entity, emem_intent, emem_tools, emem_recall) and mixed constructions like emem_echo_verify and emem_find_similar deviate from a single convention.

Tool Count4/5

16 tools is just over the ideal 3-15 range, but the count is deliberate: the server curates a small core loop and provides emem_tools as a discovery meta-tool to reach the broader 108-tool catalog. Each listed tool earns its place in the locate → recall → cite → resolve → verify workflow, so the slight overage feels justified rather than bloated.

Completeness4/5

The full consumption lifecycle is covered: locate (emem_locate), recall (emem_recall), ask (emem_ask), cite (emem_memory_token/bundle), resolve (emem_memory_token_resolve), verify (emem_verify_receipt/echo_verify), with entity identity, contradiction detection, similarity search, and policy guard as extras. Minor gaps exist — emem_diff for pair quantification and emem_recall_polygon for regions are referenced but not in the core list, and there is no write/attest tool (though that appears to be by design for a verifiable memory protocol).