Encrypted, pay-per-use persistent memory storage for AI agents, gated by x402 payments on Base.
Scored across 6 tools
Core memory operations (store, read, extend) and key management operations are largely distinct. The only potential confusion is between register_key_release and share_memory_key, but their descriptions clearly separate the registration and release steps.
All tools follow a consistent lowercase snake_case verb_noun pattern, such as read_memory, extend_memory, and share_memory_key. There are no mixed conventions or vague generic verbs.
Six tools is a well-scoped size for a focused encrypted memory service with key release and payment functionality. Each tool covers a necessary part of the workflow, though send_feedback is slightly tangential.
The core lifecycle is covered: store, read, extend, and key sharing/registration for access control. Minor gaps include no explicit delete or revocation mechanism, but TTL expiry and the release flow may be intentional design choices.
Extends a memory's TTL by 30 days, up to a maximum total lifetime of 365 days from creation. Requires x402 payment.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the core effect (extends TTL, max lifetime) and the payment requirement. It does not mention side effects, errors, or edge cases (e.g., id not found), but the primary behavior is transparent. Given the lack of annotations, it carries the full burden and could be more detailed.
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?
The description is a single, focused sentence. It packs the essential action, constraint, and requirement without any fluff or redundancy. Information is front-loaded, making it easy to parse.
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?
The description covers the purpose, effect, and requirement, which is sufficient for a simple one-parameter mutation. However, it omits explanation of the 'id' parameter and does not mention any output or return value. Since the schema provides no additional detail, this leaves some ambiguity for the agent.
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 only parameter 'id' has no schema description, and the tool description does not clarify what it refers to (though it implies a memory identifier). Without explicit context, an agent might not know exactly what id to supply, making this a notable gap.
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 clearly states a specific verb ('extends') and resource ('memory's TTL'), with concrete details (by 30 days, max 365 days from creation). It distinguishes this from siblings like read_memory or store_persistent_memory by focusing on the TTL extension action.
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?
It implicitly defines when to use the tool (when extending a memory's TTL) and mentions a requirement (x402 payment). It does not explicitly contrast with alternatives, but the operation is distinct enough that the context is clear.
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}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| wrappedKey | Yes | ||
| readerPubKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It does not mention side effects, authorization requirements, failure behavior, or what happens with invalid signatures. It only states what the action is, not its broader behavior or guarantees.
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?
The description is a single, focused sentence with no unnecessary fluff. It packs the key action, recipient, and proof mechanism efficiently.
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 the lack of annotations and output schema, the description is too thin for full context. It does not explain the purpose of each parameter, the return value, error cases, or how this interacts with the other memory-related tools.
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% and no parameter descriptions are provided. The description partially explains id, readerPubKey, and timestamp by including them in the EIP-191 signature format, but wrappedKey and signature are not defined beyond their names.
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 clearly states the tool's specific action: a creator registers a wrapped content key for a specific reader's public key, with proof via an EIP-191 signature. This distinguishes it well from the sibling tools such as read_memory, extend_memory, store_persistent_memory, and share_memory_key.
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 does not explicitly state when to use this tool versus the sibling tools. It implies use by a creator for registering a key release, but there is no direct comparison with share_memory_key or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Sends feedback about the Protocol to its operators by email. 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, the description must carry behavioral context. It states the action and constraints (free, optional name, message limit) but does not mention side effects, confirmation, or privacy considerations.
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 short sentences with the most relevant information front-loaded (free, purpose, constraints). Every word earns its place; 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?
For a simple feedback-sending tool with two parameters, the description covers the essential usage details. It does not describe return behavior, but given the simplicity and lack of output schema, that is a minor omission.
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 descriptions are absent (0% coverage), so the description compensates by explaining that name is optional and its omission means anonymous feedback, plus message length limit. This adds practical meaning beyond raw schema constraints.
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 clearly states the action (sends feedback), the target (Protocol operators), and the scope. It distinguishes itself from the sibling memory/key-release tools immediately.
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 use case is clear: use this tool to send feedback about the Protocol. There are no direct alternatives among siblings, so no explicit exclusion is needed, though no 'when not to use' guidance is provided.
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 (base64 ciphertext, up to 16384 bytes). Automatically completes x402 payment challenges.
| 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?
The description explicitly discloses the automatic x402 payment challenge completion, which is a significant behavioral side effect. It also indicates a write operation (stores) and size constraints, offering transparency beyond the bare parameters.
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?
The description is two concise sentences, directly stating the core functionality and the payment side effect without redundant or ambiguous wording.
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?
The description covers the primary purpose, size limit, and payment behavior, but omits details about the tags parameter, expected return value, or potential errors. Given the absence of an output schema, this leaves meaningful gaps in agent expectations.
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?
Only ciphertext has any descriptive semantics (from both the schema and tool description), while tags lacks any description. The tool description adds no new meaning beyond the schema for ciphertext and none for tags, so parameter coverage is insufficient.
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 clearly states the action (stores encrypted text memory), the format (base64 ciphertext), and the size limit. It unambiguously identifies the tool's purpose despite not explicitly contrasting with siblings.
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 does not indicate when to use this tool over its siblings (extend_memory, read_memory, etc.). It mentions an automatic payment side effect but provides no decision guidance for alternative selection.
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.
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 tools for autonomous agents, settled in USDC on Base via x402.
Add one secure layer between your agents and this server.
