Wever Labs Agent Products

Memory deletion check

wever_memory-deletion-check

Read-only

Agent Memory: submit a deletion flow: every place the memory lives (the primary store, a backup, a summary, a profile, an embedding index, a cache, a log, a copy shared elsewhere or other) with what a removal request does there (deletes it, marks it deleted but keeps it, or leaves it), how long it takes and whether a restore from backup can bring it back, the confirmation the principal gets (whether one is sent, whether it names each place cleared and how they can check it: a deletion receipt, an export showing nothing remains, a view of what is kept, or no way), how long deletion may take in all, and optionally the removal requests seen with when each was confirmed and whether the memory was found again afterward. The signed report says place by place whether a removal request clears the memory everywhere it lives, backups and derived summaries and profiles included, and whether the principal gets a confirmation they can check, and names every place the request leaves, every derived copy that survives, every restore that can bring memory back, every memory found again after its confirmation and no confirmation, then every place that only marks memory deleted, every place slower than the stated time, a confirmation that cannot be checked or names no places and every request confirmed late, with the fix for each. This reads one removal request across the agent’s memory: a data policy’s deletion timeline as written is wever_data-retention-check, purging on a retention period is wever_memory-retention-check, switching memory off is wever_memory-consent-check and deletion or return on a processor’s termination is wever_dpa-evidence-check. Verdict deletion_incomplete, deletion_gaps, deletion_unverified or deleted_everywhere. POST /api/memory-deletion-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": {
      "places": "<places>"
    },
    "name": "wever_memory-deletion-check"
  }
}

Input Schema

Name	Required	Description
`flow`	No	The deletion flow, such as forget-me requests.
`label`	No	Optional name recorded in the report.
`places`	Yes	Every place the memory lives, including backups and anything derived from it.
`target`	No	How long deletion may take in all, such as 30 days.
`requests`	No	Removal requests seen, with when each was confirmed.
`confirmation`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Well beyond the annotations, it discloses that the call performs no network request, fetch, money movement, message, sharing, configuration change or external write (consistent with readOnlyHint/openWorldHint=false), that it is paid at 0.10 USDC on Base via x402 exact with 10 signed-wallet free calls per rolling 30 days, that X-Wever-Wallet-Proof must bind the exact JSON arguments and route, and that the result is an Ed25519 signed receipt. It also names the four possible verdicts and enumerates what the report asserts. That is material operational context an agent cannot get from the structured fields.

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

Conciseness2/5

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

Most of the definition is one enormous run-on sentence that chains the report's assertions, its findings, and its fixes into a single breath, then repeats the place-by-place idea several times. Key routing and safety information is buried mid-paragraph, and payment/auth details sit after the report enumeration. The content is largely useful; the structure actively obstructs scanning.

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?

For a six-parameter tool with a nested place array and no output schema, the description does the work of explaining the verdict taxonomy, the report contents, the contract endpoint, and the payment model, so an agent can call it and interpret the result. The remaining gap is that it never states size or latency expectations for large place lists, though the schema caps places at 50 and requests at 1000.

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 already 83%, so the schema carries most of the burden, but the prose adds real meaning by enumerating the place kinds (primary store, backup, summary, profile, embedding index, cache, log, shared copy, other), the three on_request outcomes, the four confirmation check styles, and why requests carry found_after. It stops short of advising on edge cases such as what counts as a derived copy or how to express the 'within' duration format.

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 concrete operation on a concrete resource: submit a deletion flow covering every place a memory lives and what a removal request does there, returning a signed place-by-place verdict. It explicitly separates itself from four similarly named siblings (wever_data-retention-check, wever_memory-retention-check, wever_memory-consent-check, wever_dpa-evidence-check) by naming the distinct concern each covers. The purpose is only discoverable after wading through a colon-delimited list, so it is clear but not front-loaded.

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 gives explicit routing: use this for one removal request across the agent's memory, use wever_data-retention-check for a policy's written deletion timeline, wever_memory-retention-check for purging on a retention period, wever_memory-consent-check for switching memory off, and wever_dpa-evidence-check for deletion or return on processor termination. Those are real when/when-not boundaries with named alternatives, which is exactly what the dimension rewards.

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

All Wever Labs Agent Products tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.