Skip to main content
Glama

Scan for multi-attester disagreement

emem_memory_contradictions
Read-onlyIdempotent

Reveal where independent sources contradict each other on the same fact, complete with severity scores and citations, to audit contested claims before relying on them.

Instructions

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.
Behavior5/5

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

The description adds substantial behavioral context beyond the readOnlyHint annotation: the default scope excludes same-attester disagreements, severity is computed per band kind, and a zero result may mean only a narrower question was answered. It also discloses the output fields (disagreement_scope, providers[]) and the optional emitted edge, giving full insight into the tool's semantics.

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 highly organized: a clear lead sentence, a critical scope caveat, a 'When to use' block, parameter behavior, and a concrete example. No sentence is wasted; the density is justified by the tool's nuance. The structure makes it easy to parse the key points quickly.

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

Completeness5/5

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

With no output schema, the description must explain the return value, and it does: severity score, citations to disputed facts, records with disagreement_scope, and a providers[] list. It also covers edge cases like single-responder deployments and how to follow up with emem_diff or emem_edges_recall, making the tool fully comprehensible in context.

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

Parameters5/5

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

Even with 100% schema coverage, the description enriches each parameter: cell_prefix and band are framed as region/family narrowers, min_severity is explained with its per-band scoring, and include_same_attester_sources receives a full paragraph detailing when it matters. The example arguments tie all parameters together, demonstrating usage.

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 ('Surface') and a precise resource ('where the corpus DISAGREES with itself'), immediately distinguishing it from sibling tools like emem_ask or emem_recall. It clearly frames the tool as the opposite of a confident single answer, which clarifies its unique role.

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 includes a dedicated 'When to use' section with concrete examples ('is there disagreement about X', 'audit this claim'), explains how to narrow with parameters, and explicitly references sibling tools (emem_diff, emem_edges_recall) for follow-up. It also warns against misinterpreting a zero result, providing vital guidance without being verbose.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vortx-AI/emem'

If you have feedback or need assistance with the MCP directory API, please join our Discord server