Skip to main content
Glama

Memory sharing check

wever_memory-sharing-check
Read-only

Agent Memory: submit a memory-sharing flow: whose memory it is and each way stored memory can cross (the categories that cross, who receives it and whether that is another agent, a tool, another principal, an operator or an external system, under whose instruction: the principal each time, a standing rule the principal set, an operator, the agent on its own or no one, whether it is logged in full, in part or not at all, whether only the memory the instruction names crosses and whether the recipient may keep it), plus optionally the crossings seen with under whose instruction each happened and whether it is in the log. The signed report says crossing by crossing what stored memory crosses to another agent, tool or principal, under whose instruction and whether it is logged, and names every crossing no one instructed, every crossing the agent decides on its own, every crossing carrying memory to another principal without the first principal’s word, every unlogged crossing, every crossing that hands over the whole store and, among the crossings seen, every path nobody declared, every crossing nobody instructed and every crossing missing from the log, then every partial log, every crossing on an operator’s word in place of the principal’s and every recipient that keeps the memory, with the fix for each. This reads deliberate sharing of stored memory: context handed over inside a live session, and whether one sharing event needs consent, is wever_context-sharing-check, whether memory stores stay apart by default is wever_memory-separation-check and what a handoff format carries is wever_context-transfer-check. Verdict memory_wanders, sharing_gaps, sharing_unverified or sharing_instructed. POST /api/memory-sharing-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-sharing-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
flowNoThe memory-sharing flow, such as handoffs to the booking agent.
labelNoOptional name recorded in the report.
eventsNoCrossings seen, to find any nobody instructed or logged.
crossingsNoEach way stored memory can cross to another agent, tool or principal.
principalNoWhose memory it is, such as the traveler.

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 payment terms (0.10 USDC on Base via x402, 10 signed-wallet free calls per rolling 30 days), the X-Wever-Wallet-Proof binding requirement, the Ed25519 signed receipt, and that nothing is fetched or written externally. Those are exactly the operational facts annotations cannot carry.

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 summary is a single sprawling sentence with five levels of nested parentheses, followed by a long report enumeration that largely duplicates what the schema already declares. The front-loaded opening helps, but the middle is hard to parse and repeats structured data.

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 paid tool with no output schema, it lists the verdict values and describes what the report contains, plus a contract path and human page. Only pagination/response shape details are absent, which is minor given the explicit report description.

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 100%, so the schema already documents every property and enum. The prose restates the same semantics (categories crossing, recipient kind, instructed_by, logged, only_named, recipient_use) without adding format or interplay guidance, so the baseline 3 applies.

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 opening clause gives a specific verb and resource ("submit a memory-sharing flow: whose memory it is and each way stored memory can cross") and later names three sibling checks with the distinct question each answers. The purpose is identifiable, but the dense nested enumeration of flow attributes muddies the single-line summary an agent reads first.

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 the agent away: consent for a single sharing event is wever_context-sharing-check, default store separation is wever_memory-separation-check, handoff format content is wever_context-transfer-check. No explicit when-not-to-use case is given beyond those alternatives, so it falls short of a 5.

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.