agent-memory

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

With no annotations, the description carries the full behavioral burden, and it succeeds: it flags that ack is delete, that deletion is immediate and includes message bodies, and that unknown ids are silently skipped. This is strong disclosure of destructive behavior and error handling.

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 front-load the most important safety facts (free, owner-signed, delete semantics) and then cover edge-case behavior. Every clause earns its place; there is no filler.

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 destructive mutation tool with no annotations and no output schema, the description covers the essential invocation context: cost, authentication posture, irreversible deletion, and behavior on invalid ids. The schema supplies the nonce/signature mechanics. Nothing critical is missing for correct use.

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 documents address, nonce, and signature well (75% coverage) and message_ids is self-explanatory from its name. The description adds only the 'owner-signed' and 'free' context rather than new parameter-level detail, which is acceptable but not additive beyond schema.

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 states a specific operation (acknowledge/delete) on a specific resource (read messages) and explicitly clarifies that ack is a destructive delete, immediately removing messages and bodies. This prevents confusion with the non-destructive locker_read/count siblings and resolves the euphemistic 'ack' ambiguity.

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 title and description make it clear this is for acknowledging/removing read messages, and 'Free, owner-signed' signals the operative conditions. It does not explicitly name alternatives or state when not to use it, so it falls just short of a fully explicit routing guideline.

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?

There are no annotations, so the description carries the behavioral burden. It discloses that the call is free, read-oriented ('Returns'), and what the response covers (identity, prices, limits, custody, deletion rules, sunset, payment flow, error codes). It stops short of explicitly stating 'no side effects', but for a zero-parameter informational tool this is solid disclosure.

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, front-loaded with 'Free' and the core action, followed by a compact but complete list of contents. There is no filler, and each phrase earns its place.

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 zero-parameter discovery tool with no output schema, the description fully covers what the agent needs: when to call it, what it returns, and why it matters. The 'call first' guidance and detailed contents make the tool self-sufficient.

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 zero parameters, the parameter semantics burden is minimal; the baseline is 4. The description adds relevant context about what the returned contract contains, so no additional parameter explanation is needed.

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 ('Returns') and names a concrete resource ('the machine-readable contract') with an explicit inventory of contents. 'Call this first' also orients it as the discovery/meta tool, setting it apart from the operational locker_* 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?

It gives clear placement guidance with 'Call this first', which tells an agent when to use it relative to other tools. It does not explicitly list exclusions or alternatives, but the 'first' directive and complete contract framing make the intended usage 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 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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the disclosure burden. It states that the call is free, requires no signature, and that private_count-registered addresses return 0 and are indistinguishable from unused addresses. It does not describe the response shape, but this is minor for a count operation.

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, front-loaded sentences. The first sentence conveys cost and purpose, the second adds authentication context, and the third covers an important edge case. No 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?

For a simple one-parameter tool, the description covers cost, authentication, purpose, and a privacy-sensitive edge case. The only notable omission is explicit return-format detail, which is a minor gap given the low complexity.

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 documents the address parameter with 100% coverage, including the EVM wallet address format. The description adds little beyond reinforcing that the count is per-address, so the baseline 3 applies.

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 states the exact operation: count of unacked messages for an address, and frames it as a cheap liveness/mail check that needs no signature. This clearly distinguishes it from sibling locker tools like locker_read or locker_status without requiring schema inspection.

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 gives clear usage context: use this for a cheap liveness or mail check when no signature is available. It does not explicitly name alternatives or exclusion conditions, so it stops 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.

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

With no annotations provided, the description carries the full burden of disclosing side effects and behavior. It reveals the tool is paid, modifies credit balance, imposes financial limits, and clears read-only grace—each a significant behavioral trait beyond the obvious 'top-up'. It also explains the two-step payment flow (call without payment_b64, then retry with it), which is essential for correct invocation. It does not cover error states or what happens on failed payment, but the disclosed information is substantial and accurate.

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 three sentences and front-loads the critical 'PAID' flag, immediately setting expectations. It packs a lot of information—payment flow, rate, limits, and effects—without redundancy. The only minor inefficiency is the lengthy first sentence, but it is dense and necessary. Overall, it is well-structured for an agent to quickly grasp the key points.

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 essential operational flow (payment steps, limits, and the grace-clearing effect) and explains the key parameters, but it omits error handling, what the response contains, and any failure contingencies. Given there is no output schema and no annotations, this represents a notable gap. An agent might need to probe for error behavior, but the core invocation path is clear enough to start.

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 33% (only address has a description). The description compensates by explaining the payment flow for payment_b64 ('call without payment_b64 for requirements, retry with it') and interpreting amount_microusd through the min/cap and rate context. It clarifies that amount is in micro USD and tied to the published rate, adding meaning beyond the raw integer type. This is a strong mitigation of the schema's sparse documentation.

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 precisely states the action ('Top up storage credit') and adds critical specifics: it funds checkpoint storage at a published GB-month rate, with a minimum of $1 and a cap of $100. It also clarifies the payment mechanism (x402) and the immediate effect of clearing read-only grace, leaving no ambiguity about what the tool accomplishes. This is a specific verb+resource combination that stands apart from siblings like locker_send or locker_status.

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 when to use this tool (to add prepaid credit and clear grace) but does not explicitly contrast it with alternatives or state exclusion criteria. It references locker_send for the payment flow, which suggests they share a payment pattern, but it never says 'use this instead of X when Y' or mentions when not to use it. The guidance is adequate but relies on the reader to infer the selection context.

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 the behavioral burden. It discloses the operation is free, describes the returned data, explains the 404 semantics, and even exposes the privacy property that mail existence is never leaked. It does not mention rate limits or other operational details, but the key behaviors are covered.

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 sentences deliver high-value information with no filler. The cost note, return payload, verification requirement, and 404 behavior are all packed in efficiently and front-loaded.

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?

With no output schema, the description explains the success return (X25519 public key and signed statement) and the key error case (404). It could specify the exact shape of the signed statement for verification, but the essentials for correct invocation are present.

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 100%, so the schema already documents the address parameter. The description reinforces that the address is the lookup key for a registered X25519 key, but adds little new parameter-level syntax or format guidance beyond the schema.

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 names a specific operation: retrieving a recipient's registered X25519 public key and the wallet-signed registration statement for an address. This clearly distinguishes it from sibling tools like locker_register_key (registration) and locker_send (sending).

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 establishes the intended context: look up a recipient's encryption key before sealing, and verify the signature. It does not explicitly name alternative tools or state when not to use it, but the purpose is concrete and actionable enough for an agent to select it appropriately.

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 the transparency burden and does a solid job: it states the tool is free, explains the cross-agent memory/mailbox effect, and explicitly discloses that keys never touch the server because the kit carries a placeholder. It stops short of describing output structure, but the key security behavior is clear.

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 compact and front-loads the core action before explaining the value and privacy behavior. The vendor list is long but maps directly to the target enum, and the sentences all contribute useful context.

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 two-parameter tool with no output schema, the description covers what the output is for, how to use it, and the important security caveat. It could add more detail about the contents/format of the returned kit, but nothing essential is missing for correct invocation.

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%, so the baseline is 3. The description reinforces that the kit targets other vendors and mentions placeholders, but it does not add meaningful syntax or formatting details beyond the property descriptions already present in the schema.

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, 'emits', and names the resource (a one-paste onboarding kit) for a range of target vendors, so an agent can tell what the tool produces. It does not explicitly contrast it with sibling tools like locker_send or locker_register_key, so it falls short of full sibling differentiation.

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 gives a clear workflow: hand the operator the kit, they paste it, and the sibling agent can load shared memory. It does not list exclusions or name alternative tools, but the intended scenario is described well enough.

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 carries the full burden. It discloses that the call is free, the nonce is single-use, expires in 5 minutes, and uses EIP-191 format. This gives an agent useful behavioral context, though it omits details like whether the nonce is consumed by this call and what the exact response looks like.

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 clauses convey cost, purpose, format, and expiry with no filler. The key fact 'Returns the single-use statement' is front-loaded, and every sentence adds value.

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 single-parameter tool with no output schema, the description covers the essential usage constraints: free, single-use, EIP-191, and 5-minute expiry. It could more explicitly state the next step in the auth flow, but overall an agent has enough to invoke it correctly.

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%: the 'address' parameter is fully described as an EVM wallet address and mailbox identity. The tool description adds no additional parameter meaning beyond the schema, so the baseline 3 applies.

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 verb 'Returns' and the resource 'single-use statement to sign (EIP-191)', which is specific and unambiguous. It does not explicitly name a sibling tool for differentiation, but the nonce-generation purpose is distinct enough from siblings like locker_send or locker_read.

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 phrase 'for authenticated tools' implies this tool is a prerequisite in an authentication flow, and the 5-minute expiry signals time sensitivity. However, there is no explicit guidance on when to use it versus alternatives, nor any when-not-to-use exclusions.

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 the full behavioral burden and delivers: free, non-destructive, unacked-only, body URL redeemability limits, TTL-based persistence, and pagination via next_cursor. This goes well 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with cost/safety, and each clause adds distinct operational detail (body handling, retention, pagination). No filler.

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 tool with no output schema, it explains key return elements (body_b64, large-body URL, next_cursor) and lifecycle behavior. The main gap is that optional filtering and limit behavior are undocumented, but the tool remains callable from the required auth parameters.

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 meaning to 'address' (your address), 'cursor' (next_cursor pagination), and clarifies the default unacked filter. However, with only 50% schema coverage, it leaves limit and the nested filter object (tag/since/producer) unexplained in both the schema and the 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?

Identifies a specific operation (returns unacked messages for the caller's address) and a specific resource (mailbox), with concrete output details (body_b64, signed body_url). The 'non-destructive' phrasing and explicit contrast with locker_ack make it distinguishable from sibling mail 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?

Explains the tool is for reading unacked messages and notes messages remain until explicitly acked or TTL expiry, which implies when to use locker_ack instead. It does not explicitly name sibling alternatives for counting or capability checks, but the context is clear enough for selection.

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 carries the full behavioral burden and does well: it discloses the owner-signed requirement, the EIP-191 signature formats, the effects of require_e2e (mailbox rejects non-ciphertext) and private_count (locker_count answers as unused), and the recommendation to derive keys from the wallet signature. It could add more about side effects or reversibility, but the core behavioral traits are covered.

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 compact and front-loaded with the core purpose. The first sentence states the action and effect, and subsequent sentences add necessary signing and policy details. Every sentence contributes useful information without fluff.

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 7-parameter tool with no output schema, the description explains the key mechanics: the signed statement, the nonce, the pubkey format, and the privacy flags. It lacks explicit return-value or error-case details, but the essential operational context for correctly invoking the tool is present.

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 71%, and the schema already describes most parameters. The description adds real meaning for key_sig by specifying the exact signed statement format ('veritap-locker:register-key:{address}:{enc_pubkey}'), which is valuable. The two optional booleans get semantic context (require_e2e and private_count effects) beyond their bare names. However, some parameters like 'signature' and 'nonce' are not further enriched, so the extra value is moderate.

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 that the tool registers an X25519 public key to a mailbox identity so senders can encrypt to it. The verb 'publishes' and the resource ('X25519 public key') are specific and distinguish this tool from the locker_read/send/status sibling functions.

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 when the tool is used (initial key registration for end-to-end encryption) and gives guidance on the require_e2e and private_count flags, plus a recommended key-derivation practice. It does not explicitly name alternative tools to compare against, but the usage context is clear enough for an agent to select it appropriately.

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 carries the full disclosure burden and does so well. It reveals the paid x402 flow, the two-round payment negotiation, inline vs. upload body modes, E2E encryption requirements, and the receipt_vault storage duration. This is substantial behavioral context beyond what the schema alone provides.

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?

Four dense sentences, each serving a distinct purpose: purpose, payment flow, body-size routing, and encryption/product variations. There is no filler, and critical information is front-loaded before procedural details.

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 12-parameter, no-annotation, no-output-schema tool, the description is remarkably complete: it covers payment requirements, size limits, upload workflow, encryption, and product variants. Minor gaps remain, such as explicit return-value shape, default behavior for ttl_days, and failure semantics, so it is strong but not exhaustive.

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 67%, so the description must add meaning, and it does: 32KB inline limit, EIP-3009 signing, upload_url, sealed-box ciphertext requirements, and flat-priced receipt semantics. It does not clarify every undocumented parameter like tag, ttl_days, or content_type, but the most workflow-critical parameters are meaningfully enriched.

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 opening sentence names a specific verb and resource: delivering data to a wallet-addressed mailbox, including to another agent or one's own future self. This clearly distinguishes the operation from sibling read/ack/invite tools and establishes the mailbox-delivery scope.

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 gives a clear usage context: sending data to a wallet mailbox, with a required payment flow and body-size decisions. It does not explicitly name sibling alternatives or say when not to use this tool, but the procedure is concrete enough that an agent knows when to invoke it.

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 the full burden. It usefully adds that the tool is free and discloses the set of returned account metrics, which is relevant behavioral context. However, it does not explicitly state read-only behavior, permissions, or other operational traits beyond the word 'status' and the listed values.

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 very compact and has no wasted words: 'Free' is front-loaded, and the metric list is short. It is slightly telegraphic and could be improved with a verb, but it remains efficient and easy to scan.

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, the description is adequate: a caller knows the required address and the high-level fields returned. But there is no output schema, and the description does not explain units, value formats, or possible grace-state values, so an agent is left guessing at the exact response shape.

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%, so the schema already documents the single `address` parameter, including its EVM format and mailbox-identity meaning. The description only repeats 'for an address' without adding new parameter-level semantics, which matches the baseline for fully covered schema 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?

The title and description clearly identify this as a storage-account status tool and enumerate the specific metrics returned: credit balance, stored checkpoint bytes, daily burn, projected empty date, and grace state. However, the description lacks an explicit verb like 'retrieves' or 'returns,' and it does not directly distinguish itself from overlapping siblings such as locker_credit or locker_checkpoint.

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 a caller wants an aggregate storage-account status view, and the field list clarifies what that view contains. But it provides no explicit guidance on when to prefer this tool over siblings, nor does it state any exclusions or alternatives.

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