Skip to main content
Glama

agent-memory

by dev.veritap

The Locker — durable memory that survives your process (save/load/list/delete)

locker_checkpoint

★ THE CORE PRODUCT. Durable memory for your agent, addressed by its wallet: store the state that must outlive this session, and a fresh process holding ONLY your wallet key loads it back byte-for-byte — no server to run, no second secret. A single agent gets full value alone; no other agent has to exist. Billed from prepaid credit (locker_credit) at the published GB-month rate. save: declare slot + size_bytes, PUT bytes to the returned upload_url (last 3 versions kept, 32 slots). load: returns a signed body_url (≤3 redemptions). list: all slots. delete: remove a slot. Credit exhaustion ⇒ 30 days read-only grace before expiry — top up to resume writes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotNoRequired for save/load/delete; [a-z0-9_-].
nonceYesNonce from locker_nonce (single-use; expires in 5 min).
actionYes
addressYesEVM wallet address (0x…, the mailbox identity).
versionNoload: pin a version.
signatureYesEIP-191 wallet signature over the exact nonce string.
size_bytesNosave: declared byte size.
content_typeNo

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does it well. It discloses non-obvious behaviors: last 3 versions kept, 32 slots, signed body_url with ≤3 redemptions, credit exhaustion leading to a 30-day read-only grace period, and prepaid billing. These go far beyond the structured schema.

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?

The description is dense but well-organized: value proposition first, then billing, then each action, then failure/grace behavior. Despite being long, nearly every sentence carries operational information an agent needs for correct invocation.

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 an 8-parameter tool with no output schema, the description covers a lot: action semantics, limits, billing, retention, and grace behavior. It does not detail the exact PUT request format or response shapes, but the provided workflow information is enough for an agent to begin invoking the tool correctly.

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 75%, so the schema handles most parameter descriptions. The description adds useful action-level semantics: save requires slot + size_bytes and returns an upload_url; load returns a signed body_url; list returns all slots. However, content_type still lacks semantic explanation, and the description does not fully compensate for that gap.

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 clearly states the tool's function: durable, wallet-addressed memory that can be saved and loaded byte-for-byte across sessions. It names the specific resource ('durable memory') and the core actions (save/load/list/delete). It does not explicitly contrast with sibling tools like locker_send or locker_read, so it does not quite earn a 5 for sibling differentiation.

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?

The description gives a clear usage context: 'store the state that must outlive this session,' and explains that a fresh process with only the wallet key can restore it. It does not explicitly say when to prefer a sibling tool instead, so the guidance is strong but not fully exclusionary.

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

All agent-memory toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Each tool targets a distinct area: mailbox operations (ack/read/count/send), checkpoint storage, key registration/directory, and account/billing info. The only mild ambiguity is that locker_checkpoint bundles save/load/list/delete into one tool, and locker_send can target your own future self, which could blur the boundary with checkpoint storage.

Naming Consistency3/5

All names share the locker_ prefix and consistent snake_case, which keeps the set cohesive. However, the second part mixes bare verbs (read, send, ack, count, invite) with nouns (capabilities, directory, nonce, status) and one true verb_noun pair (register_key), so the naming convention is not uniform.

Tool Count5/5

Twelve tools is well within the ideal range, and each tool earns its place by covering a distinct capability: mailbox, checkpoint memory, key identity, billing, and onboarding. Nothing feels redundant or like padding.

Completeness4/5

The set covers the full message lifecycle (send/read/ack/count), checkpoint CRUD via locker_checkpoint, key registration/verification, and billing/status. Minor gaps remain, such as no explicit key revocation/rotation tool or sent-message history, but core workflows are complete.

Resources