Skip to main content
Glama

Memory scope check

wever_memory-scope-check
Read-only

Agent Memory: submit an agent’s memory design: the scope (whether it is written down, the categories kept, the categories excluded by rule, whether memory is kept per principal, in one global store every principal shares or a mix, the retention headline, and whether a written rule, the model’s own judgment or both decide each write), optionally each category with its kind (facts about the principal, task history, preferences, contacts, credentials, payment details, health details, location, inferences or other), whether it is kept or excluded, what decides it, whether it is kept per principal or shared and why it is kept, and the stored memories seen with their category. The signed report states what is kept, what is excluded by rule and whether the keeping is per principal or global, and names no scope, writes decided by the model, nothing excluded, one global store every principal shares and every stored memory in an excluded category, then a scope set only in code, mixed keying, every category kept in the shared store, decided by the model, kept with no purpose or holding credentials, payment or health details, every category both kept and excluded and every memory outside the scope, with the fix for each. This reads what the system keeps: which stores hold run state and which hold cross-session memory is wever_memory-design-check, whether the principal agreed to be remembered and stays in control is wever_memory-consent-check and how long memory is kept is wever_memory-retention-check. A summary sample is wever_memory-scope-sample on https://weverlabs.com/mcp-free. Verdict keeps_too_much, scope_gaps, scope_unverified or scope_bounded. POST /api/memory-scope-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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "wever_memory-scope-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
scopeNo
systemNoThe agent, such as the travel assistant.
memoriesNoStored memories seen, to find writes outside the scope.
categoriesNoEach category of memory, kept or excluded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses cost (0.10 USDC on Base via x402), the 10 free signed-wallet calls per 30 days, the X-Wever-Wallet-Proof binding requirement, and the guarantee that nothing is fetched, written or shared. It also names the four verdict values and the Ed25519-signed receipt, which is real behavioral context an agent needs before calling.

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?

The core description is a single enormous run-on sentence that chains the input fields, the report findings and the violation list into one breathless clause. Payment, auth, verdict and sibling information are useful but arrive as an undifferentiated block, so the reader must work to extract them. It is substantially longer than needed for the information conveyed.

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 carries the return-value burden and does so by describing what the signed report states, the violation classes it flags and the verdict enum. Pricing, auth binding and the read-only guarantee are also covered. It is only slightly incomplete in not saying which inputs are required for a meaningful verdict, given every parameter is optional.

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

Parameters3/5

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

Schema description coverage is already 80%, so the structured fields do most of the work. The prose recites the same scope fields (written, keeps, excludes, keyed_by, retention, decided_by) and the category fields with an example retention value, but adds no validation rules, defaults, or required-minimum guidance beyond the schema. Baseline 3 is appropriate.

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 an agent's memory design (scope, categories, stored memories) and receive a signed report on what is kept and excluded. It also explicitly separates the tool from wever_memory-design-check, wever_memory-consent-check and wever_memory-retention-check. The opening sentence is a long run-on that buries the core action, which keeps it from a 5.

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 gives clear routing context by naming what the three nearest siblings cover (run state vs cross-session stores, consent, retention), so an agent can pick the right check. It stops short of explicit 'use this instead of X when Y' phrasing or stating what input is minimally required, so it is clear context rather than full exclusion guidance.

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.

Resources