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 that a password is required to verify ownership, which is a real behavioral trait. However, for a destructive wallet operation it omits whether deletion is irreversible, what happens to funds/keys, and any confirmation behavior — gaps a delete tool should address.

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 the destructive action first and the auth requirement immediately after; no wasted text.

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

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

For a destructive, two-parameter tool with no annotations and no output schema, the description covers the auth requirement but says nothing about irreversibility or consequences. It is minimally adequate but not complete for a delete 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?

Schema coverage is 100% and both parameters are already documented ("Keystore password to verify ownership", "Wallet ID (UUID)"). The description's note about password ownership verification largely restates the schema, so it adds little beyond the baseline.

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 ("Delete a stored wallet"), which is unambiguous and easily separated from the sign/list/generate siblings. It does not explicitly name or contrast with any sibling, but the operation itself is clear.

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 parenthetical gives a prerequisite (password needed to confirm ownership) but offers no when-to-use vs. when-not guidance or alternatives among the wallet_* family. Usage is only implied by the 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?

With no annotations, the description carries the full burden. It usefully discloses that the output is sensitive secret material (a private key) and that a password is required to decrypt, but it says nothing about whether the secret is logged/audited, whether the operation is reversible, or any rate or security constraints on repeated exports.

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 verb+resource leads and the prerequisite follows. Nothing could be removed without losing information.

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, no-annotation, no-output-schema tool, the definition is minimally adequate: parameters are covered by the schema and the sensitivity of the result is hinted at. It omits what the export actually returns (raw hex string vs. JSON envelope) and any warning about handling the exposed secret, which an agent would benefit from.

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 both parameters are already fully documented in the schema, including that the password decrypts the keystore. The description's 'requires password to decrypt' merely restates the schema, so 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 states a specific verb and resource: exporting a stored private key, which is distinct from wallet_get_public_key or the wallet_sign_* siblings. It does not, however, explicitly differentiate itself from those siblings (e.g., 'reveals the secret key material, unlike get_public_key'), 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 when-to-use or when-not-to-use guidance, and no alternative is named. The parenthetical about the password is a prerequisite, not routing guidance; an agent gets no help deciding between wallet_export and wallet_get_public_key.

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 it does disclose the meaningful traits: a new keypair is created, the password is used for encryption, and the result persists in the keystore. It stops short of covering the risk profile an agent needs — whether creation is irreversible, whether the private key or address is returned, overwrite behavior, or password requirements.

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 stating action, transformation, and destination 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?

Wait — no output schema exists, and the description never says what the tool returns (address, public key, derived path), which an agent needs after creation. For a mutation with no annotations this is a gap, though the core operation is otherwise fully specified.

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 chain, label, and password are already documented in the schema. The description adds only a reinforcing note that the password encrypts the keystore, which is marginal added value over the structured fields — the baseline for full coverage.

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 concrete verb+resource ('Generate a new keypair') and enumerates the full pipeline (encrypt, store in keystore), so an agent immediately understands this creates a brand-new wallet. It implicitly separates itself from wallet_import (existing keys) but never names that sibling or any other, which keeps it 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 explicit when-to-use guidance, no mention of the alternative wallet_import for bringing in an existing key, and no prerequisites beyond the inline password reference. The agent must infer the generation-vs-import decision entirely from the tool name.

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 of behavioral disclosure. 'Query' implies read-only, but the description does not explicitly state that it is non-mutating, nor does it mention permissions, network calls, caching, error behavior, or return format. The token symbol mapping adds context but not behavioral transparency.

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 purpose and followed by useful clarification of the native token per chain. No redundant or filler text. Efficient and well-structured.

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 read tool with one fully documented parameter, the description is nearly complete. It explains the native token mapping, which helps interpret results, but does not describe the return value format despite the absence of an output schema. That gap is minor for a balance query.

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% for the single required parameter walletId, so the schema already documents it fully. The description adds no additional meaning about the parameter, which matches the baseline of 3 when the schema does the heavy lifting.

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 (Query) and resource (native token balance of a stored wallet). The resource distinguishes it from all named siblings: signing/sending transactions, listing/deleting wallets, generating/importing/exporting, and getting public keys. No ambiguity about what it does.

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 no explicit when-to-use guidance, prerequisites, or alternatives. The native token mapping is contextual but not usage guidance. An agent must infer that this is the tool for reading balances, which is straightforward but not stated.

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 and largely fails to. It implies a read, but says nothing about whether the wallet must be unlocked, whether a password is needed, or whether the operation is side-effect free; for a key-material accessor these are material omissions.

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 the resource stated immediately and no filler. Nothing is wasted and nothing is buried.

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 read getter with no output schema, the description names the returned artifact (public key / address) and the scope (stored wallet), which is close to sufficient. The only shortfall is the absence of any note on access prerequisites, which no annotation covers either.

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

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

Only one parameter exists and schema description coverage is 100%, with the schema already defining walletId as a UUID string. The description adds no format, sourcing, or example detail beyond the schema, so the baseline of 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?

States a specific verb ('Get') and resource ('public key / address') scoped to a stored wallet, which distinguishes it in substance from siblings like wallet_get_balance or wallet_sign_message. It does not, however, explicitly name a sibling or contrast itself with wallet_list/wallet_generate, 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?

Usage is only implied: 'of a stored wallet' quietly tells the agent the wallet must already exist (as opposed to wallet_generate), and the required walletId constrains it. There is no explicit when-to-use, when-not-to-use, or named alternative such as wallet_export for retrieving key material.

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 the internal pipeline (encrypt then persist to keystore), which is real behavioral context beyond the name, but it omits security-relevant traits: overwrite/duplicate-label behavior, password strength requirements, and whether the plaintext key is ever retained.

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 compact sentence that front-loads the operation and its side effects. No filler, nothing redundant.

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 security-sensitive mutation tool with no annotations and no output schema, the description covers the core action but leaves out key operational details (overwrite semantics, error conditions, key validation) that an agent would need before invoking 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?

Schema description coverage is 100%, so all four parameters (chain, label, password, privateKey) are already documented in the schema. The description adds no format or constraint detail beyond what the schema provides, 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 gives a specific verb chain (import, encrypt, store) and names the resource (private key / keystore), so the agent knows exactly what happens. It doesn't explicitly contrast with siblings like wallet_generate or wallet_export, but the action is distinct enough to disambiguate.

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 instead of wallet_generate (the obvious alternative for obtaining a wallet) or any prerequisites/exclusions. The agent must infer usage from the sibling 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that output is limited to addresses and metadata and never private keys, which is real behavioral value. It says nothing about pagination, ordering, authentication requirements, or whether the operation is strictly read-only.

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 sentence, front-loaded with the action and resource, with the key safety-relevant qualifier attached. 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 zero-required-parameter list tool with no output schema, the description covers the essentials: what is returned and what is deliberately excluded. Only minor gaps remain (ordering, pagination, auth), so an agent has enough to call 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 coverage is 100%, so the single 'chain' filter is already documented in the schema. The description adds no further detail about the filter's accepted values or behavior, so the baseline of 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 gives a specific verb and resource ('List all stored wallets') and adds a scope qualifier ('addresses and metadata only, no private keys') that separates it from siblings like wallet_export or wallet_sign_*. It stops short of naming the alternative tools, but the resource 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?

Usage is only implied by the verb 'List' — there is no explicit statement of when to call this versus wallet_get_balance, wallet_export, or wallet_get_public_key. The 'no private keys' note hints at what this tool is not for, but no alternative is named.

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 does disclose one meaningful trait — missing gas/nonce values are auto-filled via an RPC call — but omits that the operation is irreversible once broadcast, that it consumes gas, and that the password decrypts a private key held locally.

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 compact sentences, zero filler, with the core action stated first and the auto-fill behavior second. Nothing needs to be cut.

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-and-broadcasting tool with a nested transaction object, no annotations, and no output schema, the definition leaves real gaps: what is returned (a tx hash?), failure behavior, and network/chain assumptions. The nested EVM/SVM transaction fields are covered by the schema, which helps.

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 phrase 'fills in missing gas/nonce params' adds a little meaning by signaling those transaction fields are optional to supply, but it adds nothing about password or walletId 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?

States a specific compound verb and resource: 'Sign and broadcast a transaction.' The combination of signing plus broadcasting implicitly distinguishes it from wallet_sign_transaction, which by name only signs, but the description never names that sibling to make the boundary 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?

Usage is only implied: an agent can infer this is the tool for submitting a transaction to the network. There is no explicit statement of when to prefer it over wallet_sign_transaction, nor any prerequisites (funded wallet, unlocked keystore, correct chain).

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 behavioral disclosure but only states that signing occurs with a stored wallet. It does not mention the password requirement for decrypting the private key, what happens after signing, or any security or side-effect considerations.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficiently structured, though its extreme brevity contributes to the missing behavioral and usage 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 three-parameter signing tool with full schema coverage, the description is minimally adequate to infer the core operation. However, with no annotations and no output schema, it omits what the tool returns (e.g., a signature) and any usage context, leaving 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?

Schema description coverage is 100%, so all three parameters (walletId, password, message) are already explained in the input schema. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb (Sign) and resource (an arbitrary message with a stored wallet), making it clear what the tool does. However, it does not explicitly distinguish this from sibling tools such as wallet_sign_transaction, leaving differentiation to the tool name alone.

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 about when to use this tool versus alternatives like wallet_sign_transaction or wallet_send_transaction. The description only implies usage from the operation itself, with no stated conditions, prerequisites, or 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 disclosure burden. It does usefully disclose the key non-broadcast side effect and the chain-specific input format, but says nothing about the password/decryption requirement at call time, failure modes, or what the signed output looks like (no output schema to fall back on).

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, with the decisive constraint ('does not broadcast') front-loaded before the chain-specific input details. 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 a nested transaction object, no annotations, and no output schema, the description is adequate on inputs but leaves the return value (signed payload format) and the decryption/password behavior unaddressed, which an agent needs to chain this with wallet_send_transaction.

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 baseline is 3, but the description goes further by specifying 'standard tx fields' for EVM and 'base64-serialized' for SVM on the ambiguous nested 'transaction' object. That adds format-level meaning the schema's terse summary does not fully pin down.

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 ('Sign a transaction') plus the scope ('with a stored wallet'). The parenthetical '(does not broadcast)' implicitly separates it from wallet_send_transaction, but the sibling is never named, so differentiation relies on the agent making the connection itself.

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 context: sign-only, no broadcast, with per-chain input expectations. It stops short of explicitly routing the agent — it never says 'use wallet_send_transaction if you also want to broadcast' — so the when-not guidance is inferable rather than stated.

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