memory

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

Discloses important behaviors: export limit, ordering, included field (superseded_by), and cost ($0.01 via x402). No annotations exist, so description fully carries the burden and does so excellently.

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 convey maximum information without redundancy. Each sentence serves a purpose: first states core function and constraints, second adds details on data ownership, history inclusion, and cost.

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 all essential aspects for a simple export tool: purpose, parameters, behavior, cost. However, with no output schema, the description could briefly mention the export format (e.g., JSON array) for fuller completeness.

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 description adds meaningful context to the single parameter offset by explaining its purpose for paging past 1000 rows, augmenting the schema description. Schema coverage is 100% but description enhances usability.

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?

Clearly states 'Export memories' with specific scope (payer-wallet namespace) and includes key details like limit of 1000 per call, newest first ordering, and paging. Distinct from sibling tools like memory_search which is for searching.

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?

Provides clear guidance on using offset for paging when namespace exceeds 1000. However, lacks explicit comparison to sibling tools like memory_search or memory_import for alternative use cases.

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

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

No annotations provided, so description bears full weight. It discloses authorization requirements (own namespace or grant), rate limiting (max 100 ids), and cost ($0.001 per call via x402). This goes beyond the schema to inform behavior.

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 sentences, each carrying essential information: action+scope in first, limit+cost in second. No filler, front-loaded with purpose.

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 delete tool with one parameter and no output schema, the description covers purpose, authorization, limits, and cost. It does not specify return behavior, but that is likely standard. Sufficient for agent selection.

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 schema already covers all parameters with descriptions (100% coverage). The tool description reinforces the 'max 100' constraint but does not add new meaning beyond what the schema provides.

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 specifies the action ('delete memories'), the target ('by id'), and the scope ('from YOUR namespace or a namespace you hold a write/rw grant for'). It distinguishes itself from sibling tools like memory_write (create) and memory_search (search) by focusing on deletion.

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 the max limit of 100 ids per call and the cost, which guides usage. It lacks explicit 'when not to use' or alternatives, but given no other delete tool exists among siblings, 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.

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

With no annotations, the description covers embedding (best-effort, hourly backfill) and pricing. It does not disclose error handling or idempotency, but the given details are sufficient for typical use.

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 sentences front-load the core purpose and constraints, with no extraneous text. Every clause adds value: constraints, input format, embedding, pricing.

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 one parameter, no output schema, and no annotations, the description covers key aspects (input, constraints, behavior). It lacks failure mode details, but the tool is simple enough that this is adequate.

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?

Beyond the schema's 'up to 200 items', the description adds content character limit, exact shape compatibility with memory_export, and embedding behavior. This enriches understanding of the parameter's use.

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 bulk-writes memories into the user's namespace, with specific constraints (max 200/call, 8k chars each). It distinguishes from siblings like memory_write by using 'bulk-write' and referencing memory_export's shape.

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 implies usage when importing from memory_export and mentions pricing compared to free siblings, but does not explicitly state when to avoid or list alternatives. It provides clear context for a specific scenario.

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

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

With no annotations, the description carries full responsibility. It discloses the cost and embedding-based similarity, but omits behavioral details such as error handling, empty result behavior, or any rate limits. Basic behavior is clear but not fully transparent.

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 sentences, front-loading the core purpose, and adds only essential details (cost, namespace). No wasted words or 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?

The description covers the key purpose and cost, but with 2 parameters, no output schema, and zero annotations, it leaves gaps: no details on return format, query parameter semantics, or error cases. It is adequate for a simple tool but not complete.

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% (only k described). Description adds context that results are 'top-k' and paid, but does not explain the 'query' parameter beyond the tool's purpose. It partially compensates for the missing schema description but not fully.

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?

Description clearly states the tool performs semantic search over memories, specifying the namespace (payer-wallet) and return type (top-k by embedding similarity). It distinguishes itself from siblings (memory_export, memory_stats, memory_write) which cover other operations.

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?

Description implies usage for semantic retrieval of memories, and the sibling names clarify alternatives. However, it does not explicitly state when not to use this tool or provide context for choosing between searching and other operations.

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

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

Discloses free tier, cap, and auth scheme, but no annotations exist. Does not state if operation is read-only or has side effects, nor behavior when cap is exceeded.

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 with key information front-loaded. No extraneous text.

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?

Explains auth and cap, but lacks details on return format or error handling. Adequate for a simple search tool, but could be more complete given no output schema.

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 covers 67% of parameters (k and wallet_auth have descriptions). Description does not add beyond schema; query parameter lacks description in both schema and description.

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?

Clearly states it's a free semantic search over the user's namespace with wallet authentication. Distinguishes from sibling tools like memory_search (paid) and memory_write_free (same auth scheme).

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?

Indicates free tier with cap of 500 searches per 30 days, implying use for limited queries. References same auth as memory_write_free, but lacks explicit when-to-use vs memory_search or when-to-avoid.

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

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

No annotations provided, so description carries the burden. It discloses the tool returns count and timestamp, and explicitly states content is never returned on free tier, which is a key behavioral constraint. However, it lacks details on authentication or rate limits.

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?

Single sentence that is front-loaded with 'FREE' and efficiently conveys the tool's purpose and limitation without wasted words.

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 main functionality and a key constraint, but lacks details on what 'count' represents (e.g., number of entries) or the format of the timestamp. Adequate for a simple tool but not fully comprehensive.

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 description coverage is 100% with 'wallet address' for the namespace parameter. The description adds no further semantic detail beyond schema, so baseline score of 3 is appropriate.

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 returns 'count + last-write timestamp for any wallet namespace' and specifies the free tier limitation, distinguishing it from siblings like memory_search which likely returns content.

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 implies usage context via 'FREE' and mentions content is never returned on free tier, but does not explicitly guide when to use this tool vs alternatives like memory_search for content or memory_write for mutations.

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

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

With no annotations provided, the description fully bears transparency. It details permanent storage, namespacing, semantic indexing, the supersedes effect (excluded from search but visible in export), and the payment mechanism. No contradictions with absent 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?

The description is a single paragraph that front-loads the purpose. Each sentence adds unique information (purpose, scope, supersede behavior, payment). No wasted words, though slightly longer than necessary. Efficient for the amount of detail.

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 tool has 3 parameters, no output schema, and no annotations, the description covers core behavioral aspects well: permanent storage, namespacing, indexing, supersedes, and payment. It lacks return value details and error handling but is comprehensive for a write tool.

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 schema has 67% description coverage, with content and supersedes already described. The description adds context for supersedes (effect) and mentions semantic indexing, but does not elaborate on tags or provide new parameter semantics beyond what the schema offers. Moderate value.

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 'Store a memory permanently' with a specific verb and resource. It adds scope ('Namespaced to YOUR paying wallet') and distinguishes this paid version from alternatives via the payment mention, differentiating it from siblings like memory_write_free.

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 outlines what the tool does (store permanently, searchable, supersede) and mentions it is paid, but does not explicitly state when to use this versus sibling tools like memory_write_free or memory_import. It implies usage for permanent storage but lacks when-not-to-use guidance.

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

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

With no annotations, the description fully discloses behavioral traits: free tier, auth mechanism, namespace sharing, write cap (1000/30 days), and error behavior.

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 dense sentences with zero waste, front-loaded with 'FREE (no payment)' for quick understanding.

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 purpose, auth, namespace, rate limits, and error handling. No output schema exists, so return value omission is acceptable. Complete for a free write tool.

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 description adds significant detail for wallet_auth (format, signing scheme, timestamp constraint) beyond the schema. Tags lack schema description but description doesn't expand it; overall good compensation.

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 stores a memory using a free auth method (EIP-191 personal_sign) instead of payment, distinguishing it from the paid tier.

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 explains this is the free alternative to paid calls, mentions the cap and error redirection, but does not explicitly list alternative tools or when-not-to-use scenarios beyond the cap.

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