Skip to main content
Glama

Memory provenance check

wever_memory-provenance-check
Read-only

Agent Memory: submit stored memories as supplied, each with the fact as stored, where it came from (observed in a call, stated by the principal, inferred by the agent or imported from another system), the call, message or record behind it, what an inference was drawn from, the system an import came from and whether an inference is labeled as one wherever the agent reads it, plus optionally the memory design: whether every write records its source, whether inferences are stored with a label and what the agent does before acting on an inference (confirms with the principal, acts, or never acts on inferences). The signed report counts the memories by source and says memory by memory whether each carries where it came from, and names every memory with no source, every inference stored without a label (an inference read as fact), a design that records no source or stores inferences as facts and an agent acting on inferences unconfirmed, then every observed or stated memory with no call, message or record behind it, every inference with no basis and every import with no source system, with the fix for each. This reads where each memory came from: what happens when a new fact contradicts a remembered one is wever_memory-conflict-check, what the agent keeps at all is wever_memory-scope-check and which stores hold run state and cross-session memory is wever_memory-design-check. Verdict rumors_kept, provenance_gaps, provenance_unverified or memories_sourced. POST /api/memory-provenance-check. Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route. Returns a report with an Ed25519 signed receipt. Contract: /api/agent-memory-contract. Human page: https://weverlabs.com/agent-memory/.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "memories": "<memories>"
    },
    "name": "wever_memory-provenance-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
designNo
systemNoThe agent, such as the travel assistant.
memoriesYesEach stored memory, as supplied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, it discloses that reads are confined to the call with no network request, fetch or external write, that the call is paid (0.10 USDC x402 exact with 10 signed-wallet free calls per rolling 30 days), that the X-Wever-Wallet-Proof header must bind to the exact JSON arguments and route, and that the response carries an Ed25519 signed receipt. These are the operational facts an agent must know to invoke it successfully, which the readOnlyHint/destructiveHint annotations alone do not convey.

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

Conciseness3/5

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

The core information is present but the opening sentence runs well over a hundred words and re-enumerates the same source taxonomy that appears again in the report paragraph, which makes it hard to scan. The related-tool routing and pricing details are valuable, but the delivery is dense and back-loaded rather than crisply front-loaded.

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

Completeness4/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 does the work of describing the return: per-memory provenance status, counts by source, named gaps with fixes, and the verdict set, plus endpoint, contract and human page. The only soft spot is that the four verdict tokens are listed without explaining when each is returned, leaving the agent to infer their meaning from their names.

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 high at 75%, but the description adds real meaning by implying conditional relationships between fields: observed or stated memories need a call, message or record behind them, an inference needs a basis, and an import needs a source system, which the flat schema does not enforce or explain. It also groups the design sub-fields under a single plain-language question about pre-action behaviour. The enum values themselves are largely restated rather than extended.

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

Purpose4/5

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

The description states a specific verb and resource ('submit stored memories as supplied') and spells out what the resulting signed report counts and flags, so the agent knows exactly what the tool produces. It is weaker on separating its own scope from siblings in the opening sentence, because that separation is only made later in a long run-on construction.

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

Usage Guidelines4/5

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

It explicitly routes three named alternatives with their conditions ('what happens when a new fact contradicts a remembered one is wever_memory-conflict-check, what the agent keeps at all is wever_memory-scope-check and which stores hold run state ... is wever_memory-design-check'). That is clear contrast guidance even though there is no explicit 'use this tool when' sentence and no stated prerequisite such as first obtaining a wallet proof.

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.