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

With no annotations, the description carries the full behavioral burden. It implies a read-only local lookup ('locally held'), which is the key behavioral fact, but discloses nothing about auth needs, failure modes, or return format. Adequate but thin for a zero-annotation tool.

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?

A single short sentence with no padding and the key scope qualifier front-loaded. It is efficient, though borderline terse for a tool in a crowded wallet namespace.

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 getter with no output schema, the description should convey what is returned (the address string) and how it relates to sibling tools such as wallet_receive_info. Neither is provided, leaving real gaps given the size of the sibling set.

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 takes zero parameters, so per the baseline this scores 4. There is nothing for the description to compensate for and no misleading parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the locally held wallet address') and adds scope ('locally held'). However, it doesn't explicitly differentiate from siblings like wallet_receive_info or wallet_balance, which also surface wallet-derived data.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives among the many wallet_* siblings. An agent must guess when this is preferred over wallet_receive_info or wallet_balance.

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, and it does disclose a meaningful behavioral property: only ciphertext is written to Relay memory, never plaintext key material. It is silent on reversibility, idempotency, the required witness (the agent-held recovery secret), and whether the local key is left intact or removed after backup.

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?

A single sentence that front-loads the encryption step and then the storage step in causal order. Zero filler and no redundant restatement of the tool name.

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, no-output-schema tool the shape is simple, and the ciphertext-only design is the key fact an agent needs. Still, it omits the dependency on an existing recovery secret and the relationship to the restore siblings, which matter for a key-material operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters with 100% schema coverage, so there is nothing for the description to disambiguate. Baseline of 4 applies; no parameter semantics are needed or missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names specific verbs and resources: encrypt the local key, store ciphertext in Relay memory. It is far more concrete than the bare name. It does not, however, differentiate itself from the obvious counterpart sibling wallet_restore_relay, leaving the agent to infer the pairing.

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 statement of when this should be called versus siblings like wallet_restore_local or wallet_restore_relay, and no stated prerequisite such as the pre-existence of a recovery secret from wallet_generate_recovery_secret. Usage is only implied by the action verb.

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 are provided, so the description carries the burden. It usefully discloses the data source (configured Base RPC), which tells the agent the network and that no arguments are needed, but it omits error/failure behavior (e.g., unconfigured RPC or unreachable node), whether results are cached, and whether any auth is required.

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?

A single front-loaded sentence with no filler. Every word (verb, resource, source) 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-param read tool with no output schema, the description covers the essentials: what is returned (USDC balance) and from where (Base RPC). The only minor gap is failure-mode behavior, which is not critical for an agent 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies no input 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?

States a specific verb (Read) and resource (wallet USDC balance) with the data source (configured Base RPC). This clearly distinguishes it from siblings like wallet_address, wallet_receive_info, and wallet_funding_request, which concern addresses, receive details, and funding rather than balance reads.

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 read-only nature is implied by 'Read', giving implied usage guidance, but there is no explicit when-to-use framing, no mention of prerequisites (e.g., wallet must be configured/created), and no reference to alternative siblings for related balance or address queries.

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. It usefully discloses that the key is generated locally, encrypted under the recovery secret, and only returned after encryption, which is meaningful safety context. It does not address failure behavior, idempotency, or what happens if a wallet already exists.

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?

A single, well-front-loaded sentence that leads with the action and ends with the return-time guarantee. Nothing is wasted.

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-param mutation tool with no annotations and no output schema, the description covers the core mechanism but omits operationally relevant facts: the state of any pre-existing wallet, idempotency, and the shape of the returned value. Adequate but with clear 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no input is needed and instead conveys the environmental precondition (recovery secret) the caller must already have.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: generate a Base wallet key locally and return it encrypted. It implicitly distinguishes from siblings like wallet_restore_local/restore_relay by describing creation of a fresh key, but it never names those alternatives to force the distinction.

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 explicit when-to-use or when-not-to-use guidance. The phrase 'under the agent-held recovery secret' hints that wallet_generate_recovery_secret is a prerequisite, but this dependency is left for the agent to infer and no alternatives (restore paths) are mentioned.

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 are provided, so the description carries the full burden; it does disclose the most safety-relevant trait — generation is local and no signature or transfer is submitted. It stops short of stating whether the wallet must already exist locally or whether any RPC/network access occurs.

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, artifact and safety boundary front-loaded, with zero filler. Every clause 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?

With no annotations and no output schema, the description needs to cover more. It handles the destructive-action question well but leaves the return shape (URI string plus SVG payload?) and the expectedChainId guard behavior unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It implies the asset (Base USDC) and therefore the chain, but does not define the amountUsdc format (units, decimals, string encoding) or what expectedChainId actually guards against (presumably a mismatch check). Partial compensation only.

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 gives a specific verb (generate) and precise artifacts (Base USDC EIP-681 funding URI and SVG QR), which is far more informative than a generic 'funding request'. An agent can distinguish this from wallet_address or wallet_receive_info because the output artifacts are named exactly.

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?

Usage is implied by the artifact produced, and the boundary statement 'does not sign or submit a transfer' tells the agent this is a non-transactional path. However, no sibling alternatives (e.g., wallet_receive_info) or selection conditions are named, so the agent must infer when to pick this over adjacent tools.

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 meaningful context: it is one-time, exactly 32 bytes, must be persisted in the agent secret manager, and is never transmitted to Voidly. It does not clarify whether a second call invalidates a prior secret, nor what the return value looks like, leaving a small gap for a security-sensitive 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?

Two tight sentences, front-loaded with the action and its key constraint (one-time, 32-byte) followed by the mandatory storage step. Every clause earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool with no annotations, the description covers purpose, ordering relative to wallet_create, storage requirement, and the key privacy guarantee. The only omission is lifecycle edge cases (repeat invocation, errors), which is minor given the tool's simplicity.

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 takes zero parameters, so the schema baseline is 4. There is nothing further for the description to disambiguate, and it introduces no misleading parameter-like instructions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Generate a one-time 32-byte recovery secret') with concrete size and lifecycle detail. It also implicitly distinguishes itself from siblings by tying its use to the moment 'before creating a wallet', which no other sibling claims.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear sequencing guidance ('Store it in the agent secret manager before creating a wallet'), which tells the agent when in the flow to call it. It stops short of naming alternatives or stating when-not to call it (e.g. whether it can be re-run), so it falls just below explicit when/when-not coverage.

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 and does disclose two non-obvious traits: keys are 'locally retained' and the call 'never retries or pays', establishing a side-effect-free read. It still doesn't state what authentication is concretely required or what happens on a pagination/empty result, so it is strong but not exhaustive.

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?

A single tight sentence front-loads the verb and resource, then appends the safety constraint after a semicolon. No filler, though the phrasing is dense enough that it reads slightly compressed.

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, annotation-free list tool with no output schema, the description covers what is enumerated and its non-destructive nature. Only the return shape (key count, format) is left unstated, which is a minor gap given the simplicity.

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 takes zero parameters, so the schema is complete by construction and the baseline is 4. There is no parameter information for the description to add or omit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and a precise resource ('locally retained Marketplace quote and payment keys'), which an agent can distinguish from siblings like wallet_recover_marketplace. It stops short of explicitly contrasting itself with those siblings, but the scope is 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?

'for payer-authenticated recovery' implies the context in which to reach for it, and 'never retries or pays' rules out using it as an action tool. However, it never names an alternative (e.g. wallet_recover_marketplace) or states when NOT to use it, leaving the routing decision partly to inference.

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 discloses that funds come from local USDC authorization and that per-call/daily limits are enforced, which is real behavioral context. However, it omits critical traits for a money-spending tool: irreversibility, what happens on insufficient funds or failed payment, and any auth requirements beyond 'local'.

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?

A single front-loaded sentence with no filler; the core action and its constraints appear immediately.

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 mutation/spend tool with no annotations, no output schema, and 0% parameter coverage, the description is too thin. It should clarify what the call returns (payment receipt, status), failure modes, and how the amount limit interacts with maxAmountUsd.

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 0% across 4 parameters, so the description must compensate. It hints at a resource URL and per-call limits (loosely mapping to url and maxAmountUsd) but says nothing about body, method, or the format/units of maxAmountUsd, leaving most parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Pay') plus a specific resource type ('public HTTPS x402 resource') and the funding mechanism ('local USDC authorization'). This clearly distinguishes it from the other wallet_* siblings, which are all about wallet lifecycle, balances, or recovery rather than spending.

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 (pay an x402 resource, subject to per-call and daily limits) but names no alternatives and gives no when-not-to-use guidance. An agent can infer intent but not how to choose between this and, say, wallet_funding_request.

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. It clearly discloses that it fetches and signs only the exact challenge, returns a fixed submit URL and body, and does not submit. It does not cover auth requirements, rate limits, or whether signing alters wallet state.

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?

A single sentence, front-loaded with the tool action and scoped by 'only' and 'without submitting.' Every phrase 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 zero-parameter preparation tool with no output schema, the description explains the inputs needed (none) and the return shape (fixed submit URL and body). It does not explain when to choose this over other wallet tools, but otherwise it is sufficient 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?

There are zero parameters and the schema description coverage is 100%, so the baseline is 4. The description adds no parameter meaning because there are no parameters to describe.

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 verb+resource: fetch and sign Voidly's exact seller-registration SIWE challenge, and return the submit URL/body without submitting. It is clearly not a tautology and is distinguishable from generic wallet tools, but it does not explicitly differentiate itself from any sibling by name.

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?

Usage is implied: use this tool to prepare a Voidly seller-registration submission rather than to submit it. The 'without submitting' clause clarifies a boundary, but no alternative tool is named for the actual submission step and no explicit when-to-use/when-not-to-use guidance is given.

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 are provided, so the description carries the full burden. The verb 'Get' strongly implies a read-only, side-effect-free lookup, which is meaningful signal, but the description says nothing about permissions, whether the wallet must be created first, or the response shape.

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?

A single front-loaded sentence with no filler, exactly sized for a no-argument getter.

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 parameters, no annotations, and no output schema, the description is nearly sufficient: it names both the address and the network info that will be returned. It could say slightly more about what 'Base network information' contains, but nothing critical is missing.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('the USDC receiving address and Base network information'), so the agent knows exactly what comes back. It does not differentiate itself from the sibling 'wallet_address', which sounds like it may overlap, so it stops short of a 5.

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 call this versus 'wallet_address', 'wallet_balance', or 'wallet_funding_request', nor any stated preconditions (e.g. wallet must already exist). The agent must infer usage entirely from the name and description.

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, and it does disclose one meaningful trait: the operation signs only and never dispatches a payment retry. It omits permission requirements, whether signing consumes the retained attempt, idempotency, and any side effects on local state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One compact sentence, front-loaded with the action and its key safety caveat after the semicolon. No filler, though the dense domain phrasing trades some clarity for brevity.

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 signing tool with no annotations, no output schema, and an undocumented required parameter, the description leaves too much open: what the signed request is for, what the agent should do with it, and how to source quoteId are all unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single parameter quoteId is never mentioned in the description. The phrase 'locally retained Marketplace attempt' loosely implies the identifier refers to a stored attempt, but the required 0x-prefixed 64-hex format and where to obtain the value are not addressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb (sign) and resource (payer recovery request) scoped to a 'locally retained Marketplace attempt', which sets it apart from siblings like wallet_marketplace_attempts. The multi-clause qualifier and jargon ('payer recovery request') keep it from being instantly self-evident, but the purpose is derivable.

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?

Usage is only implied: the 'locally retained Marketplace attempt' qualifier narrows when this applies, and 'never sends a payment retry' excludes one nearby behavior. No sibling is named and no explicit when-to-use/when-not guidance is given, so the agent must infer the trigger condition.

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 mostly does not discharge it. It never says whether restoring overwrites or destroys an existing vault, whether a vault must be absent first, whether the operation is reversible, or what happens on a bad secret. Only the fact that the secret is agent-held is disclosed.

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?

A single front-loaded sentence with zero waste; the operation and its key input are stated immediately. No padding 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?

For a state-mutating recovery operation with no annotations and no output schema, the description is too thin. It omits the precondition (that the recovery secret must already exist), the effect on any existing local vault, and any success/failure signal, all of which an agent needs to call this safely.

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 takes no parameters, so there are no semantics to convey; the baseline for a zero-parameter schema is a 4. Nothing in the description misleads about inputs, though it also adds nothing needed since the schema is trivially complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Restore) and resource (the local encrypted vault) plus the mechanism (the agent-held recovery secret). The word 'local' implicitly distinguishes it from the sibling wallet_restore_relay, but the contrast is never made explicit.

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 no when-to-use guidance, no prerequisites, and no named alternatives. It does not say to use wallet_generate_recovery_secret first, nor when to prefer this over wallet_restore_relay, leaving the agent to infer routing from the names alone.

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, and it does disclose the authorization requirement (an agent-held recovery secret) and that the payload is client-encrypted Relay memory. However, it omits key traits for a mutation tool: whether existing local wallet state is overwritten, what happens on failure, and whether the operation is reversible.

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?

A single tightly written sentence that front-loads the verb and scope, with 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 two-parameter, unannotated, no-output-schema tool with 0% parameter coverage, the description leaves the parameters, failure modes, and overwrite semantics unexplained. The mechanism sentence is a start but not enough 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 0% and both parameters (address, backupKey) are documented only by regex patterns. The description vaguely references a 'recovery secret' without mapping it to backupKey or explaining the address role, so it does not compensate for the missing 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?

States a specific verb (restore), resource (wallet), source (client-encrypted Relay memory) and mechanism (agent-held recovery secret), which separates it from wallet_restore_local and the inverse wallet_backup_relay. It is clear what the tool does, though it never explicitly contrasts itself with the sibling restore path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance. The existence of a sibling wallet_restore_local and wallet_backup_relay makes the routing decision non-obvious, yet the description offers no condition for choosing Relay restore over local restore.

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