Skip to main content
Glama

emem, the verifiable memory protocol for the physical world

Server-side ed25519 receipt verifier

emem_verify_receipt
Read-onlyIdempotent

Verify a signed receipt envelope server-side: rebuilds the canonical preimage under the rule the receipt's own preimage_version names, runs ed25519 over the embedded key and signature, and returns {valid, reason, failure_detail, signature_valid, merkle_proof_valid, signer_pubkey_b32, preimage_blake3_hex}. A receipt is BYTE-FOR-BYTE OR NOTHING: v2 binds the inclusion proof, so any reshaping (a dropped field, a re-keyed one, a summary) invalidates the signature by design. For when the in-browser /verify path is unavailable, or for a server-side audit of a third party's receipt.

When to use: Pass the receipt EXACTLY as the read primitive returned it, whole and unmodified. Two omissions produce a false forgery rather than a 400, and they are the only two worth memorising: dropping merkle_proof, and dropping preimage_version (absent deserialises to 0, which silently selects the v0 rule, so the proof still walks while the signature reads as invalid). Signature and pubkey may be byte arrays or sig_b32 / responder_pubkey_b32; no other spelling is tolerated. Reshaping a field this responder can check is reported as reason: receipt_reshaped_after_signing with the field named, never accepted. Optionally set pubkey_b32 to assert a specific signer. A bad signature is 200 with valid: false, never a 4xx. The example arguments are a real receipt this responder signed (key epoch 0) over one weather fact at Trafalgar Square: run it unchanged and valid is true; change any byte and it is not.

Example arguments: 1602 bytes, too long to inline in a listing. Call emem_tools with {"name": "emem_verify_receipt"} for it whole and runnable; it is not shortened here because a truncated example is not one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
factsNoThe fact value(s) you intend to rely on. Each is content-addressed and checked for membership in the receipt's `fact_cids`, so a genuine receipt presented beside a tampered fact answers `valid:false` / `fact_mismatch`. Omit it and only the signature is checked, which a doctored fact survives.
receiptYesThe signed receipt envelope, the object under `receipt` in any read primitive's result. Must carry primitive/served_at/request_id/cells/fact_cids and either `signature` byte[] + `responder_pubkey` byte[] or their b32 string forms. IF ALL YOU HOLD IS AN `emem:fact:` TOKEN, this is not the tool to call first: a token is not a receipt and passing one here is a shape error. Call `emem_memory_token_resolve` on the token, then pass THAT result's `receipt` object here. Resolving proves the token points at the bytes it claims; verifying proves this responder signed them.
pubkey_b32NoOptional explicit responder pubkey (base32). When omitted, uses the receipt's embedded pubkey/responder fields.
current_responder_epochNoThe responder key epoch you currently trust, from `/v1/manifests`. Produces an advisory `key_epoch_advisory` comparison against the receipt's epoch; a mismatch is reported, never rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / receipt / description
      Previous value: -"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."New value: +"The signed receipt envelope, the object under `receipt` in any read primitive's result. Must carry primitive/served_at/request_id/cells/fact_cids and either `signature` byte[] + `responder_pubkey` byte[] or their b32 string forms. IF ALL YOU HOLD IS AN `emem:fact:` TOKEN, this is not the tool to call first: a token is not a receipt and passing one here is a shape error. Call `emem_memory_token_resolve` on the token, then pass THAT result's `receipt` object here. Resolving proves the token points at the bytes it claims; verifying proves this responder signed them."
  2. Changed2 schema fields changed
    • addedInput schema / properties / current_responder_epoch
      Added value: +{
      +  "description": "The responder key epoch you currently trust, from `/v1/manifests`. Produces an advisory `key_epoch_advisory` comparison against the receipt's epoch; a mismatch is reported, never rejected.",
      +  "type": "integer"
      +}
    • addedInput schema / properties / facts
      Added value: +{
      +  "description": "The fact value(s) you intend to rely on. Each is content-addressed and checked for membership in the receipt's `fact_cids`, so a genuine receipt presented beside a tampered fact answers `valid:false` / `fact_mismatch`. Omit it and only the signature is checked, which a doctored fact survives.",
      +  "type": "array"
      +}
  3. Added

TDQS

A5/5.0
Behavior5/5

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

Annotations declare readOnly/idempotent/non-destructive, and the description adds critical behavioral detail beyond that: byte-for-byte binding, v2 inclusion proof invalidation on reshaping, the two omissions that produce false forgery rather than a 400, and bad signatures returning 200 with valid:false. 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.

Conciseness5/5

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

Long but dense and front-loaded: the first sentence gives the operation and output contract, and each subsequent paragraph carries a distinct warning, routing rule, or example note. No filler; the length is appropriate for a security-critical verifier with subtle failure modes.

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?

No output schema exists, so the description supplies the full return shape and valid:false semantics. It covers all four parameters, the critical false-forgery cases, the alternative token-resolution path, and even how to obtain a runnable example. Nothing an agent needs to invoke this correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds substantial semantics beyond the schema: consequences of omitting facts, exact accepted spellings for signature/pubkey fields, the merkle_proof and preimage_version failure modes, and the advisory nature of current_responder_epoch. This lifts it well 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?

States a specific verb and resource: 'Verify a signed receipt envelope server-side', then enumerates the exact verification steps and return fields. It also distinguishes itself from the sibling emem_memory_token_resolve by explicitly saying a token is not a receipt and from the in-browser /verify path, so an agent can select it correctly.

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?

Contains an explicit 'When to use' section naming the in-browser /verify path and server-side audit use cases, plus an explicit when-not: if all you hold is an emem:fact token, call emem_memory_token_resolve first. This gives clear routing among alternatives.

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.