Encrypted, pay-per-use persistent memory storage for AI agents, gated by x402 payments on Base.
Scored across 6 tools
Most tools target distinct operations (store, read, extend, feedback), but register_key_release and share_memory_key are both key-management tools that could initially be confused with one another, though their descriptions clarify the register vs. release distinction.
All six tools follow a consistent snake_case verb_noun pattern (extend_memory, read_memory, register_key_release, send_feedback, share_memory_key, store_persistent_memory) with no mixing of conventions.
Six tools is well-scoped for an encrypted memory service covering storage, retrieval, TTL extension, key management, and feedback, though a delete/list operation might reasonably be expected.
Core lifecycle (store, read, extend, key register/release) is covered, but there is no explicit delete/revoke, no listing or discovery of memories, and no metadata lookup, leaving notable gaps that could hinder an agent managing memories over time.
Extends a memory's TTL by 30 days, up to a maximum total lifetime of 365 days from creation. Requires x402 payment. An expired memory is deleted and cannot be extended.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses the TTL delta, the hard lifetime cap, a payment/cost requirement, and the failure mode that expired memories are deleted and non-extendable. It omits error behavior for unknown/invalid ids and whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and constraint, then payment requirement, then failure case. No filler; every sentence carries new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers cost and lifecycle limits well but leaves the id semantics and the outcome of a successful call (e.g., new expiry) unstated, so the agent cannot fully predict the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id' has 0% schema description coverage, so the description must compensate. It only implies that the parameter identifies the memory; it says nothing about id format, source, or what an invalid id does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (extend a memory's TTL) with concrete scope: +30 days, capped at 365 days from creation. The operation is clearly distinguishable from siblings like store_persistent_memory and read_memory without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives useful preconditions (requires x402 payment, expired memories cannot be extended), which implies when the tool is applicable. However, it never names an alternative or tells the agent when to extend versus re-create a memory with store_persistent_memory; routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads an encrypted memory by id. Requires x402 payment. 70% of the fee accrues to the memory's creator.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds meaningful behavioral detail: the memory is encrypted accrues a 70% fee to the creator, and requires x402 payment. This is substantial for a read operation, though it doesn't cover error behavior or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences; the main action is front-loaded and the payment detail is secondary. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers payment and encryption but omits the return shape and failure behavior. Since there is no output schema, an agent does not know what a successful read yields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description should explain the id parameter, but it only repeats 'by id' without type, format, or source. The agent gets no additional semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Reads an encrypted memory by id.' It clearly conveys the operation, though it does not explicitly distinguish itself from sibling tools or state when it should be preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear context: reading an encrypted memory by id, and notes the x402 payment prerequisite. However, it does not mention when to prefer this over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Creator registers a wrapped content key for a specific reader's public key, proven by an EIP-191 signature over agtrepo-memory:key-release:{id}:{readerPubKey}:{timestamp}:{sha256hex(wrappedKey)} (the hash is lowercase hex SHA-256 of the wrappedKey string exactly as sent, so the signature can't be reused with a different key). {id} only exists after store_persistent_memory returns, and {timestamp} is Unix epoch milliseconds (an integer, not an ISO date) that must be within 5 minutes of the server clock -- so sign at call time; a pre-signed or archived signature will be rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| signature | Yes | ||
| timestamp | Yes | Unix epoch milliseconds, within 5 minutes of server time; the exact value that was signed | |
| wrappedKey | Yes | ||
| readerPubKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: cost ('Free'), the exact EIP-191 signed message format, replay protection rationale (hash binding prevents reuse with a different key), and the 5-minute server-clock validity window. This is rich behavioral context an agent could not infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action after a one-word cost cue, and every sentence carries required information. The parenthetical explaining the hash-then-sign ordering is necessary but makes the text dense; three long clauses in one sentence could be marginally clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-required-param mutation with no annotations and no output schema, the description covers the signing contract, timing, and dependency chain well. It stops short of describing the success response or the exact error behavior on a rejected signature, which leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20%, yet the description gives meaning to essentially every one of the 5 parameters: id's origin (after store_persistent_memory), timestamp's unit and validity (Unix epoch ms integer, within 5 minutes), wrappedKey's role in the SHA-256 hash, readerPubKey's role as the reader's key, and signature's algorithm and signed payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('registers a wrapped content key for a specific reader's public key') and immediately names the cryptographic proof mechanism that distinguishes it from siblings like share_memory_key. An agent can tell what this tool does and how it differs from sibling key/memory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear preconditions and timing constraints: '{id} only exists after store_persistent_memory returns' and 'sign at call time; a pre-signed or archived signature will be rejected.' It does not explicitly state when to prefer this over share_memory_key, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Sends a message to the human operators of this service: a bug report, a problem with these tools or the documentation, or a suggestion. It is read by people, not processed by software, and nothing is returned beyond an acknowledgement. Do NOT use it for status updates, progress notes, task narration, error logs, or as a fallback when another tool is unavailable or a payment cannot be made -- it cannot complete, retry or work around any task. Name is optional (omit for anonymous feedback); message is limited to 1000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the full burden and does so well: it is free, it is read by humans rather than processed by software, it returns nothing beyond an acknowledgement, and it cannot complete, retry, or work around any task. These are exactly the behavioral facts an agent needs to avoid misusing it as a fallback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight paragraph led by the most decision-relevant fact ('Free.'), then purpose, then mechanism, then the exclusion list. Every clause earns its place; the negative list is the highest-value content and is included without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema, no-annotation tool, the definition covers purpose, permitted uses, prohibitions, cost, and return behavior. Nothing an agent needs in order to call it correctly or avoid abusing it is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does for both parameters: name is optional and omitting it yields anonymous feedback, and message is capped at 1000 characters. The name's 80-character maximum is left to the schema, but nothing essential is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Sends a message to the human operators of this service') and enumerates the valid intents (bug report, documentation problem, suggestion). It is unmistakably distinct from the memory-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit positive triggers (bug report, problem with tools/docs, suggestion) and an unusually thorough exclusion list: not for status updates, progress notes, task narration, error logs, or as a fallback when another tool or a payment fails. The agent knows exactly when to route here versus anywhere else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores encrypted text memory (standard padded base64 ciphertext, up to 16384 bytes decoded). Requires x402 payment. Returns the memory's id.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| ciphertext | Yes | base64-encoded, client-encrypted content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose key behavioral traits: the payment requirement (x402), the return value (memory's id), the format and size limit of the ciphertext. However, it omits important details such as permission/authentication requirements beyond payment, whether the memory is immutable, and any rate limits. Adequate but incomplete for a mutation tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse sentences, each carrying distinct and necessary information (what, format/size constraint, payment requirement, return value). No redundancy or filler; front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only 50% schema coverage, the description covers the essentials (action, format, payment, return) but leaves gaps for a mutation tool: it doesn't explain what happens to existing memories, whether tags are for retrieval, or any access control. It's minimally viable but not rich enough for a state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (ciphertext has a description, tags does not). The description adds meaning by specifying 'standard padded base64 ciphertext, up to 16384 bytes decoded', which is valuable for the ciphertext parameter beyond the schema's 'base64-encoded, client-encrypted content'. However, the tags parameter is completely undocumented in both the schema and the description, leaving a semantic gap for half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource ('Stores encrypted text memory') and specifies the content type, distinguishing it from siblings like read_memory or share_memory_key. However, it doesn't contrast with extend_memory, which is a closely related write operation, leaving some ambiguity about when to store a new memory versus extend an existing one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance, no prerequisites beyond the payment mention, and no mention of alternatives like extend_memory. The agent is left to infer that this creates a new memory rather than adding to an existing one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
register_key_release2 fields changedInput schema / properties / readerPubKey / maxLengthAdded value: +2048Input schema / properties / wrappedKey / maxLengthAdded value: +8192share_memory_key1 field changedInput schema / properties / readerPubKey / maxLengthAdded value: +2048store_persistent_memory2 fields changedInput schema / properties / tags / items / maxLengthAdded value: +64Input schema / properties / tags / maxItemsAdded value: +16register_key_release2 fields changedInput schema / properties / timestamp / descriptionAdded value: +"Unix epoch milliseconds, within 5 minutes of server time; the exact value that was signed"Input schema / properties / timestamp / typePrevious value: -"number"New value: +"integer"send_feedbackextend_memoryread_memoryregister_key_releaseshare_memory_keystore_persistent_memoryPrivate, permanent encrypted storage for AI agents. Paid per call in USDC via x402.
Persistent agent memory paid per call via x402 USDC. Your wallet is your private memory namespace.
Verifiable crypto signals, recorded history and always-on monitoring for AI agents via x402 on Base.
Pay-per-call AI infra for agents: DeFi market data, LLM inference, STT/TTS. x402 v2, USDC on Base.
Add one secure layer between your agents and this server.
