locker

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

With no annotations provided, the description carries full burden and does exceptionally well: it discloses the destructive nature ('removed immediately'), authentication ('owner-signed'), cost ('Free'), and edge-case behavior ('Unknown ids are silently skipped'). This goes far beyond what the schema alone would convey.

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 short sentences, front-loaded with the most critical fact ('Ack IS delete') and no filler. Every sentence delivers meaningful information: cost/auth, destructive semantics, and edge-case behavior.

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 tool with no annotations and no output schema, the description covers the essential behavioral aspects: immediate deletion, ownership, and handling of unknown IDs. However, it does not specify whether only 'read' messages can be acked, nor does it describe error behavior for invalid signatures or nonce expiry, which are minor but relevant gaps.

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 75%, so the baseline is 3. The description adds context like 'owner-signed' and 'Unknown ids', but it does not add syntax or format details for the parameters beyond what the schema already provides (e.g., nonce from locker_nonce, EIP-191 signature).

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 clearly states 'Acknowledge (= delete) read messages' and the description reinforces the destructive action: 'Ack IS delete — disclosed rule, by design: acked messages and their bodies are removed immediately.' This is a specific verb+resource with explicit semantics, clearly distinguishing it from locker_read (non-destructive) and locker_send.

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 through the 'Ack IS delete' warning and the 'owner-signed' requirement, but it doesn't explicitly say when to use this tool versus alternatives like locker_read or locker_checkpoint. No exclusions or alternatives are named, so guidance remains implied rather than explicit.

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 discloses that the tool is free, returns a machine-readable contract, and details what is included (deletion rules, 30-day sunset, x402 payment flow, error codes). It stops short of explicitly stating that it has no side effects or requires no authentication, but the informational nature is strongly implied.

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-loaded with 'Free' and 'Returns', and every phrase adds value. The enumerations are compact yet comprehensive, and the instruction 'Call this first' is actionable. No filler 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?

Given zero parameters, no output schema, and no annotations, the description covers all critical aspects: cost, return contents, and usage order. The enumeration of contract components is sufficiently detailed for an agent to know what to expect, and the 'call first' guidance provides the needed context within the sibling tool suite.

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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are needed. The empty schema already communicates that no arguments are required.

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 clearly identifies the resource (the machine-readable contract), then enumerates its key contents (identity model, prices, limits, custody commitments, x402 payment flow, error codes). This distinguishes it from sibling tools like locker_send or locker_status, which perform specific actions rather than exposing the full contract.

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 'Call this first' gives explicit sequencing guidance, indicating that this tool should be used before others to understand the contract. It does not explicitly state when not to use it or name alternatives, but the context makes its role as the discovery entry point 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 of disclosing behavioral traits. It reveals critical behaviors: billing from prepaid credit at a GB-month rate, version retention (last 3 versions), slot limit (32), redemption limit for load (≤3), and the 30-day read-only grace period upon credit exhaustion. It also describes the two-phase save process (declare then PUT). This is exceptionally 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 dense but efficiently structured, with each action labeled and described in a compact form. The opening metaphor ('Dead drops to your future self') adds color but is not wasteful. It front-loads the core purpose and then details each operation. While quite long, every clause adds value and the structure is logical.

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?

This is a multi-action tool with significant complexity (billing, versioning, redemption limits, grace period, two-phase save), and the description covers all these aspects without requiring an output schema. It explains the workflow for each action and important constraints. The agent has enough information to select and invoke it correctly, even in edge cases like credit exhaustion.

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 75% coverage, so the description needs to provide some added meaning. It does add action-specific semantics: save uses slot+size_bytes, load returns a signed body_url, version pinning is load-specific, and nonce comes from locker_nonce. It does not explain address/signature beyond schema, but those are auth params with schema descriptions. The description nicely clarifies which parameters apply to which actions.

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 identifies this as a checkpoint storage tool with four distinct actions (save/load/list/delete) for storing state that survives across sessions. It uses specific verbs and resource terms, and the title plus description clearly distinguishes it from sibling tools like locker_send or locker_read, which deal with messaging and reading mail.

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 provides clear context for when to use this tool ('dead drops to your future self', store state), and it implies the storage use case versus sibling tools. It also gives action-specific usage instructions (e.g., save declares slot+size_bytes and PUTs to upload_url, load returns signed body_url). However, it does not explicitly name alternatives or say when NOT to use this tool, so it falls slightly 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, the description carries the transparency burden and does well: it discloses that the tool is free, requires no signature, and that private_count-registered addresses are indistinguishable from unused ones. This goes beyond the schema and gives key behavioral context, though it omits details like rate limits or 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?

The description is two sentences, front-loaded with 'Free.' and a crisp definition of the tool. It contains no filler and every sentence adds unique value: cost, purpose, auth, and a caveat.

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 single-parameter tool, the description covers purpose, cost, authentication, and a behavioral limitation. It does not explicitly describe the return format, but no output schema exists and the semantics are straightforward. The description is complete enough for an agent to decide when to use it.

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 provides full coverage of the single parameter (address), but the description adds meaningful behavioral context by noting that addresses registered with private_count return 0. This enriches the parameter semantics beyond the schema's basic type 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?

The description clearly states the tool counts unacked messages for an address, with 'a cheap liveness/mail check' as a specific verb+resource. It distinguishes itself from sibling tools by emphasizing it requires no signature and provides only a count, not message content, which separates it from locker_read and locker_send.

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 clear usage context: a free, unauthenticated liveness/mail check. It includes an important caveat about private_count addresses returning 0, effectively telling users when the result may be misleading. However, it does not explicitly name alternative sibling tools or state 'when not to use' beyond the caveat.

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 paid nature, the two-step payment mechanism, amount limits, and the immediate grace-clearing effect. This is substantial behavioral context for a payment tool, though it doesn't describe failure modes or refunds.

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 with no filler. It front-loads the critical 'PAID' and payment flow, then efficiently covers rates, limits, and side effect. Every clause adds distinct 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 3-parameter, no-output-schema tool with no annotations, the description covers the payment flow, constraints, and behavioral side effect. It doesn't describe return values or error handling, but the two-step flow implicitly addresses the requirements-retrieval step, making it reasonably 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 only 33% (only 'address' described). The description compensates by explaining that 'payment_b64' is omitted in the first call and used in the second, and by giving minimum/cap context for 'amount_microusd' ($1 min, $100 balance cap). However, the exact micro-to-dollar conversion is not explicit, leaving some ambiguity.

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 purpose: adding prepaid credit for checkpoint storage, with a specific verb ('top up') and resource ('storage credit'). It distinguishes itself from siblings like locker_send (which has a similar payment flow but different outcome) and locker_status, making the function unambiguous.

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 provides explicit usage guidance for the x402 payment flow ('call without payment_b64 for requirements, retry with it'), as well as constraints (minimum $1, balance cap $100) and a side effect (clears read-only grace). It doesn't explicitly name alternatives or exclusions, but the tool's unique role among siblings makes the usage context 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 carries the full burden. It discloses the free nature, the response contents, the 404 behavior, and the privacy guarantee that mail existence is never leaked. This is strong transparency for a read-only lookup, though rate limits or auth requirements are not mentioned.

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-loaded with 'Free' and then the core function. Every clause adds value—return value, signature verification, 404 handling, privacy. No redundancy or 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 single-parameter lookup with no output schema, the description completely covers what the tool returns, how to interpret the result (verify signature), error handling (404), and privacy behavior. The agent has all needed context to invoke 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?

The input schema already describes the only parameter (address) with 100% coverage. The description adds context about the return value but does not add new syntax or format details beyond the schema. Baseline 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 the registered X25519 public key for an address, along with a wallet-signed registration statement. This is a specific verb+resource action that distinguishes it from siblings 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?

Provides clear context: use this to look up a key before sealing/sending, and verify the signature. Also explains the 404 error meaning. It does not explicitly name alternative tools or when-not-to-use, but the context is sufficient.

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 discloses that the nonce is free, single-use, follows EIP-191, and expires in 5 minutes—key behavioral traits beyond just 'get a nonce.' It doesn't cover edge cases like invalidation of prior nonces, but the core behavior is well explained.

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, each with distinct information: cost ('Free'), purpose ('Returns...'), and behavior ('Expires in 5 minutes'). 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 one-parameter tool with no output schema, the description covers the essential return value, the signing standard (EIP-191), expiry, and cost. It could mention how the nonce relates to the address, but the schema already describes the address. Sufficiently 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?

The schema already provides 100% coverage for the single 'address' parameter with a clear description ('EVM wallet address (0x…, the mailbox identity)'). The tool description adds no additional parameter semantics, but the baseline for high schema coverage is 3.

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 it 'Returns the single-use statement to sign (EIP-191) for authenticated tools,' using a specific verb and resource. It distinguishes itself from siblings like locker_send or locker_status by focusing on nonce acquisition.

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 says the nonce is 'for authenticated tools,' implying it is a prerequisite for authentication, and notes the 5-minute expiry. However, it does not explicitly mention when to use it vs alternatives or any exclusions, so it falls 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, the description carries the full burden. It discloses key behaviors: non-destructive reading, inline vs. large-body handling with signed URLs limited to 3 redemptions, need to re-read for a fresh link, and pagination via next_cursor. This is rich and exceeds typical tool descriptions.

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 with dense information: free, behavior, pagination. Every part earns its place and is front-loaded with the most relevant facts. No redundancy or 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 read tool with no output schema and no annotations, the description explains return formats (body_b64 vs. body_url), signed-link restrictions, TTL-based retention, and pagination. It does not cover error handling or exact TTL duration, but it is adequately complete for a tool of this 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?

Schema coverage is 50%, and the description does not compensate. It only mentions 'your address' and pagination via next_cursor (which is a response field), but does not clarify limit, cursor, or filter parameters. The schema itself provides descriptions for nonce, address, and signature, leaving half the parameters unexplained in both places.

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 function: 'Returns unacked messages for your address' — specific verb, resource, and scope. It distinguishes itself from locker_ack by mentioning that messages remain until acked, but it does not explicitly name alternatives or contrasts with 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?

Provides context: 'Free', 'Non-destructive', and explicitly notes that messages persist until locker_ack or TTL expiry, implying when this tool is appropriate. However, it lacks an explicit 'use this when... or use locker_ack instead' formulation, though the guidance is clear 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, the description carries the transparency burden. It discloses that the tool is 'Owner-signed,' requires an EIP-191 signature as proof of key ownership, and explains how require_e2e and private_count alter mailbox behavior. It lacks details on re-registration 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 three concise sentences, front-loaded with purpose, then the signature explanation, then flags and a recommendation. Every sentence earns its place, with no redundancy or 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 tool with several parameters and no output schema, the description covers the essential invocation context: purpose, signature construction, policy flags, and a derivation recommendation. It relies on schema for nonce and address, and doesn't mention response behavior, but it's sufficiently complete for an agent to act.

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 71%, but the description adds significant value. It gives the exact message format for key_sig, which is a complex parameter, and explains the two undocumented booleans (require_e2e, private_count). This goes well beyond the schema descriptions.

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: 'Publishes your X25519 public key so senders can seal to you.' This is a specific verb+resource that distinguishes it from sibling tools like locker_send or locker_read, and the title reinforces 'Register your encryption 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 implies when to use this tool (before others can send you encrypted messages) and explains the effects of policy flags. It does not explicitly name alternative tools or exclusions, but it provides clear context and a reference to locker_capabilities for key derivation, which is helpful.

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 so admirably. It discloses that the operation is paid via x402, explains the two-step payment mechanism, imposes size limits and upload behavior, reveals encryption requirements based on recipient settings, and describes the receipt_vault product variant (flat-priced, 365-day storage). No annotations exist to contradict these statements.

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 (four sentences) yet information-dense. It is front-loaded with the primary purpose, then systematically covers payment, size modes, encryption, and product variants. Every sentence earns its place; there is no redundancy or 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 12 parameters and no output schema, this description covers all critical operational aspects: authentication/payment flow, size constraints, upload mechanism, encryption condition, and special product behavior. The remaining parameters (tag, content_type, ttl_days, producer, idempotency_key) are either self-explanatory or have schema descriptions, so the overall context is complete 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?

Even with 67% schema description coverage, the description adds crucial inter-parameter semantics that the schema alone lacks. It explains how payment_b64 relates to the initial price-request call, how body_b64/body_upload/size_bytes work together for file size handling, what encrypted:true signifies in the context of sealed-box ciphertext, and the special meaning of product:'receipt_vault'. This goes well beyond repeating field types.

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 opens with a specific verb and resource: 'Deliver data to any wallet-addressed mailbox.' It clearly distinguishes this from sibling tools (all of which are read/lookup operations) by explaining it is the send/payment tool. The mention of 'your own future self's' mailbox adds nuance, and the title 'Send a message to a wallet address (paid)' reinforces the 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?

The description provides explicit usage flow: 'call without payment_b64 to get the price and accepts[] requirements, sign an EIP-3009 USDC authorization, retry with payment_b64.' It also lays out conditions for choosing inline vs. upload mode (≤32KB vs larger) and when encryption is required (if recipient registered require_e2e). This goes far beyond simply saying 'use this to send' and gives concrete procedural 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 carries the full burden. It discloses that the tool is free and lists the returned data fields, but does not explicitly state whether it is read-only, whether it requires specific permissions, or if there are any side effects. The term 'status' implies a safe query, but this is not made explicit, and no information about error behavior or data freshness is provided.

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, compact sentence that front-loads the key fact 'Free' and then lists the returned data points in a readable, comma-separated format. Every word contributes to understanding what the tool does, with no unnecessary 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?

Given the low complexity (one parameter, no output schema) and the presence of a 100% schema description, the description adequately lists the return values at a conceptual level. It does not detail the exact response format, but for a simple status tool this is sufficient for an agent to invoke it and interpret the high-level 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 input schema already provides 100% coverage with a clear description of the 'address' parameter. The tool description adds no additional information about the parameter beyond saying 'for an address', which does not enrich the schema. Baseline of 3 is appropriate because the schema fully describes the parameter.

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 what the tool returns: credit balance, stored checkpoint bytes, daily burn, projected empty date, and grace state for an address. It is a clear noun-phrase description of a status check, but lacks an explicit verb like 'get' or 'retrieve'. It distinguishes itself from siblings by listing multiple aggregated data points, though it does not explicitly differentiate from similar tools like 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?

There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or scenarios where locker_credit or locker_checkpoint would be preferred. The usage is only implied by the word 'status', which is insufficient for an agent deciding between sibling tools.

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