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

No annotations are supplied, so the description must carry the behavioral load, and it does disclose three concrete facts: this is a mutation ('Complete'), it verifies the signer, and it persists the signed delegation encrypted in the agent vault. It omits auth/permission requirements, idempotency, and failure behavior, which keeps it from a 5.

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 action verb and precondition lead, followed by the side effects. Slightly dense with three clauses, but every clause carries 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 multi-step mutation with no annotations and no output schema, the description covers the workflow position and side effects but says nothing about what happens on a bad signature, whether repeated calls are safe, or what the caller receives. Adequate but with visible 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 the schema already documents all five parameters including defaults and the signature override semantics. The description adds no additional meaning about requestId, signature, pendingActionId, or submitPendingAction, 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?

States a specific verb and resource ('Complete a pending agent delegation') and adds the two internal steps (verify signer, store encrypted in agent vault). The precondition 'after the WalletChan signature request is approved' positions it in the workflow relative to agent_prepare_delegation and agent_request_delegation_signature, though it never names those siblings explicitly.

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 a clear triggering context: run this only after the WalletChan signature request has been approved. It does not state exclusions or name an alternative for the case where the request is not yet approved, so it falls short of explicit when/when-not 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, and it does add real behavioral context: a vault-secret file is created automatically, and the private key is deliberately never returned. It is silent on important traits for a key-generating mutation, such as whether it fails or overwrites when a wallet already exists, where state is persisted, and whether the operation is idempotent.

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 with no filler, and the core purpose plus the two most load-bearing facts (auto vault-secret creation, no private key returned) are front-loaded. It could be marginally tighter, but every sentence 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 output schema and no annotations, the description does the important work of declaring the return values (address and profile IDs), which is exactly what an agent needs to chain into later calls. It stops short of clarifying what 'profile IDs' refer to relative to the execution-profile siblings, but the essentials are covered.

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 is a single optional parameter ('label') and schema description coverage is 100%, so the schema already documents it fully. The description adds no extra meaning about the label's role (e.g., whether it must be unique or whether it can be changed later), 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?

States a specific verb and resource ('Create a local encrypted agent wallet'), and the qualifier 'local encrypted' distinguishes it from a remote/custodial flow. However, it never contrasts itself with the closest sibling, agent_import_wallet, so an agent must infer which of the two wallet-creation paths to pick.

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 guidance at all: no statement of when to call this versus agent_import_wallet, versus agent_list_wallets/agent_get_wallet, and no prerequisite (e.g., does an existing wallet need deletion or reset first?). Usage is only implied by the verb 'create'.

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 it well: it explicitly discloses that onchain permissions are NOT revoked and only the MCP local artifact is removed, plus the confirm=true guard. It stops short of stating whether deletion is reversible or what a successful response looks like.

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

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

Three short sentences, front-loaded with the action and scope, then the critical non-effect, then the confirmation requirement. 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 deletion tool with no annotations and no output schema, the description covers the highest-risk ambiguity (that this is a local-only delete). Minor gaps remain around idempotency and success/failure signaling, but nothing that would cause a wrong invocation.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description adds the confirm=true requirement but, since it matches the schema, it is baseline-level rather than additive.

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+resource ('Delete a locally stored agent delegation session') and immediately scopes it against the onchain semantics, so it is distinguishable from siblings like agent_delete_wallet or agent_list_delegations.

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 useful context about the effect (local-only, not onchain) but never states when to use this versus related tools such as agent_get_delegation or agent_delete_wallet. Usage is implied rather than routed.

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 a real behavioral trait beyond the schema: private key material is destroyed, and a confirm flag is mandatory. However, it omits irreversibility, what happens to any on-chain funds, and permission/auth requirements for a destructive 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 short sentences, zero filler, with the destructive scope front-loaded followed immediately by the required precondition.

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, irreversible tool with no annotations and no output schema, the description covers what is deleted and the confirm gate but leaves out the risk context (key loss, funds handling, auth). Adequate but with meaningful gaps 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%, so both walletId and confirm are already documented in the schema, and the description only restates the confirm requirement. Baseline 3 applies since the schema does the heavy lifting and the description adds no syntax or format detail.

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 ('Delete') and resource ('local encrypted agent wallet'), and adds the scope 'and its private key material.' This clearly separates it from siblings like agent_create_wallet, agent_import_wallet, and agent_reset_vault.

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

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

The description gives a prerequisite ('Requires confirm=true') but no when-to-use guidance, no warning about irreversible loss of funds/keys, and no routing to alternatives such as agent_reset_vault or agent_delete_delegation for related cleanup.

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 this is a read operation and that WalletConnect pairing is not needed, but it omits auth requirements, whether the raw profile must exist locally, rate limits, and error behavior. Adequate but not rich 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?

Two tight sentences with zero filler, front-loading the core action and following with the pairing constraint. Every sentence 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 read-only balance query with no output schema, the description conveys what is being fetched (native or ERC-20 balance) at a sufficient level. It could say more about the return shape or default-chain behavior, but with full schema coverage of the inputs, the definition is largely 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 description coverage is 100%, with chain, token, walletId, and profileId all documented in the schema itself (including the agent-eoa alias rule and Base default). The description adds no parameter-level meaning beyond that, 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 (Read) and resource (native or ERC-20 balance) scoped to a 'raw local agent EOA profile', which is a meaningful qualifier. It does not explicitly distinguish itself from siblings like get_portfolio_balances, veil_get_balances, or veil_x402_payer_balances that also report balances, 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?

The line 'Does not require WalletConnect pairing' implies when this tool is applicable (raw/local profiles without a paired session), which is a useful contextual signal. However, there is no explicit when-to-use vs alternatives guidance, no exclusions, and no routing to any of the several sibling balance 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 burden and does disclose two critical traits: the path is non-atomic (partial-failure risk across sequential calls) and it bypasses WalletChan popup approval (no interactive user confirmation). These are exactly the risk-relevant facts an agent needs. It omits prerequisites/permissions and what happens on mid-sequence failure, keeping it short of a 5.

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 tightly written sentences, front-loaded with the core action and followed by the key caveats. No filler and nothing redundant with the structured fields.

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 no-annotation, no-output-schema mutation tool, the description covers the most important behavioral facts (non-atomic, bypasses approval) and the schema fully documents parameters. It leaves out failure/revert behavior and auth prerequisites, so it is strong but not exhaustive.

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

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

Schema description coverage is 100%, so the schema already documents calls, chain, walletId, and profileId, including the agent-eoa alias rule. The description adds only 'sequentially' as ordering semantics, which is the baseline-3 situation where 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 pair (sign and broadcast) and resource (calls) with a clear source (raw local agent EOA). It scopes the operation ('sequentially', 'from a raw local agent EOA'), which helps separate it from generic send paths, but it never names siblings like agent_eoa_send_transaction or send_calls to make the routing 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 line 'This path is not atomic and bypasses WalletChan popup approval' implies when this path is appropriate (agent-driven, no user confirmation) and hints at a tradeoff, but it does not state when to prefer an alternative such as send_calls or agent_oneshot_relay_calls. Usage is implied rather than prescribed.

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 transaction bypasses popup approval, a critical safety-relevant behavior. However it does not state that broadcasting is irreversible, what wallet/profile prerequisites are required, or how gas defaults are applied — gaps that matter for an unguarded mutation 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?

Two sentences, zero waste. The primary action is front-loaded and the usage constraint follows 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 10-parameter, zero-required, no-annotation transaction-signing tool with no output schema, the description covers the routing decision well but leaves behavioral risk (irreversibility, required wallet setup) and half the parameters unexplained.

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 only 50%: data, chain, value, walletId and profileId are documented, but to, gas, gasPrice, maxFeePerGas and maxPriorityFeePerGas are not. The description adds no parameter meaning at all, so it fails to compensate for the undocumented half.

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 ("Sign and broadcast a transaction") and scopes it to a raw local agent EOA, which implicitly contrasts with the popup-approval path used by siblings like send_transaction. It does not name an alternative tool explicitly, so sibling differentiation is by contrast rather than 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?

It gives an explicit selection condition: use only when the user explicitly chose the raw agent wallet. It also names the behavioral alternative (WalletChan popup approval) that this bypasses, but does not name a specific sibling tool to use instead.

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 does disclose two real behavioral facts: metadata-only by default, and that payload retrieval involves local decryption. It omits permission/auth requirements, error modes, and what the returned metadata contains, so it is only partially transparent 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?

Two tight sentences, front-loaded with the operation and then the payload nuance. No filler, no repetition, and the most decision-relevant clause comes first.

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?

There is no output schema and no annotations, so the description should ideally say more about the returned metadata shape. It adequately covers the default-vs-payload switch and the security-relevant decryption step, but leaves auth requirements and return contents unspecified.

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 documented in the schema and the baseline is 3. The description adds one genuine nuance beyond the schema by tying includePayload=true to local decryption, but the remainder restates the schema's default-vs-payload distinction.

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 one local agent delegation"), and the singular "one" implicitly separates it from the sibling agent_list_delegations. It does not name any sibling or alternative explicitly, so an agent must infer the single-vs-list routing 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?

The description explains the default behavior and how to escalate with includePayload=true, which is useful invocation guidance. It gives no when-to-use framing against agent_list_delegations or the prepare/complete/delete delegation siblings, and states no prerequisites.

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 behavioral burden, and it does disclose a security-relevant trait: the private key is neither decrypted nor returned, and the record is a 'local' one. It still omits auth/permission requirements and not-found behavior, but the secret-handling disclosure is meaningful context an agent cannot infer from the schema.

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

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

Two short sentences with zero filler; the retrieval scope is front-loaded and the security caveat follows 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?

No output schema exists, so the description usefully names the return payload (metadata record plus profile IDs) and its one exclusion (private key). It is nearly complete for a single-record getter, missing only error/not-found and permission context.

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 walletId parameter, so the schema already documents it. The description adds nothing about ID format or source, leaving the baseline 3 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?

States a specific verb (Get), a specific resource (one local agent wallet metadata record) and scopes the return (profile IDs), which cleanly separates it from agent_list_wallets and the deletion/creation siblings. An agent can tell what it retrieves without opening the schema.

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 word 'one' implies lookup-by-ID rather than listing, so usage is implied, but the description never states when to prefer this over agent_list_wallets or what precondition (existing walletId) is required. No alternatives or exclusions are 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 and does well: it discloses a side effect ('Creates a local vault-secret file automatically when needed'), the return contents ('address and profile IDs'), and a security guarantee ('never the private key'). It omits idempotency, overwrite behavior when a wallet already exists, and permission requirements, keeping it short of a 5.

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 tight sentences, front-loaded with the action, then side effect, then return guarantee. No filler and every sentence 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?

No output schema exists, and the description compensates by naming what is returned (address and profile IDs) and what is not (the private key). It covers the core behavior for an import operation, though it could say more about error/duplicate-wallet handling.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, including that the private key is encrypted immediately and never returned. The description adds a security note but no syntax or format detail, and never mentions the optional 'label' parameter. Baseline 3 applies.

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

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

The description states a specific verb and resource: 'Import a local encrypted agent wallet private key.' This is clear and distinguishable from other verbs, but it never explicitly contrasts with the nearby sibling agent_create_wallet, leaving the import-vs-create distinction to inference.

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 guidance, no prerequisites, and no named alternative despite obvious siblings like agent_create_wallet. The usage is only weakly implied by the verb 'Import', which is not enough routing help.

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 does disclose the key behavioral trait that signed delegation payloads remain encrypted and are not returned, which is genuinely useful. However, it says nothing about permissions, scope (local only), pagination, or ordering, so a read operation's behavioral surface is only partially 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?

Two tight sentences, no filler. The most important constraint (encrypted payloads not returned) is front-loaded after the core action.

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

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

Covers the essentials for a list tool: what it lists and what it does not return. But with no annotations and no output schema, it could usefully say what the metadata includes (delegation ID, status, chain) and whether results are scoped to the local agent. Adequate but with clear gaps for a tool in a crowded delegation lifecycle family.

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?

All three filter parameters are already documented at 100% schema coverage with clear descriptions and an enum for status. The description adds no filter semantics, but the schema fully supplies them, so the baseline for high coverage applies. Slight uplift over pure baseline because the description clarifies these are optional filters in effect.

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 specific resource (local agent delegation metadata), which is clear. It hints at the sibling boundary with agent_get_delegation (single vs. list) but does not explicitly distinguish itself from agent_get_delegation or the other delegation lifecycle 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?

No guidance on when to use this versus alternatives such as agent_get_delegation, agent_prepare_delegation, or the request/complete signature tools. The description reads as a bare statement of behavior with no routing context.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses a safety-relevant behavior ('Does not decrypt or return private keys') and that it is read-only in nature, but says nothing about auth requirements, vault lock state, or behavior when no wallets exist.

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

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

Two short sentences, front-loaded with the resource and scope, followed by the one negative constraint that matters. Every sentence earns its place.

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

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

For a zero-parameter read-only listing with no output schema, the description covers what is returned (wallet metadata and profile IDs) and what is excluded (private keys). It is nearly complete; a note on when the list may be empty or how wallets are ordered would close the remaining gap.

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, which is the baseline for a 4. There are no parameters whose semantics could be clarified, so nothing more is required here.

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: listing local agent wallet metadata and profile IDs. Clear and unambiguous. However, it does not distinguish itself from sibling tools like get_wallets, agent_get_wallet, or agent_list_delegations, so sibling differentiation is absent.

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, no prerequisites, and no named alternatives. An agent cannot tell from the description when to choose this over get_wallets or agent_get_wallet; the only implicit signal is that it lists rather than fetches a single wallet.

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 behavioral burden. 'Fetch' implies a read, but it does not describe what a capability payload contains, whether any auth or registration is required, or whether results are cached/rate-limited.

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 with the primary action front-loaded. The second sentence is slightly tangential but still earns its place as a related-tool note; nothing is padded.

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

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

With no output schema and no annotations, the description should do more to explain what capabilities are returned and why an agent needs them before relaying. It is minimally adequate for a zero-required-param read tool but leaves the consumer to infer the value.

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 the single chainIds parameter is fully documented in the schema, including the Base 8453 default. The description's 'one or more chains' restates the schema without adding format or syntax detail, so baseline 3 applies.

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

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

The description states a specific verb and resource ('Fetch 1Shot public relayer capabilities') with the scope 'for one or more chains'. This distinguishes it from the other oneshot siblings (fee data, relay calls, status), though it doesn't name them explicitly.

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 to call this versus agent_oneshot_get_fee_data, agent_oneshot_relay_calls, or agent_oneshot_get_status. The second sentence only cross-references agent_prepare_delegation's behavior, which is context, not usage guidance for this tool.

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 behavioral burden. 'Public relayer fee data' implies a read with no auth, but it does not disclose return format, whether fees are cached/time-sensitive, rate limits, or freshness, which matters for fee estimation.

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 filler. It is appropriately sized, though it is so terse that it omits useful routing context rather than being over-verbose.

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-optional-parameter read tool with full schema coverage, the description is minimally adequate: purpose is clear, but with no annotations and no output schema the agent gets no signal about return shape or behavior. 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?

Schema coverage is 100%, so both parameters (token, chainId) are fully documented in the schema, including their defaults. The phrase 'chain/payment token pair' merely restates those two params and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Fetch), resource (1Shot public relayer fee data), and scope (chain/payment token pair). An agent can tell this apart from siblings like agent_oneshot_relay_calls or agent_oneshot_get_status, though the description doesn't explicitly contrast them.

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, when-not-to-use, or alternative guidance is given. The description only says what is fetched, not when an agent should call it (e.g., before relaying a call to estimate cost) versus checking capabilities or status.

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 discloses one useful trait, that this queries a public relayer (implying no auth), but says nothing about whether the call blocks or returns immediately, polling/rate-limit behavior, or what a terminal vs pending status looks like. That is a significant gap for a polling 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 front-loaded sentence with no filler; the resource and the required input are both in the first clause. It is efficient, though the brevity borders on under-specification given the tool's polling semantics.

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?

No output schema and no annotations, so the description is the only source of behavioral and return information, and it omits both. An agent cannot tell what status values to expect, whether the task is complete, or whether to keep polling, which is exactly what a status-check tool needs to convey.

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 documented in the schema (taskId format, logs flag). The description only alludes to taskId and says nothing about the logs parameter, so it adds no meaning beyond the schema. 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?

States a specific verb (poll), resource (1Shot public relayer status), and key input (submitted task ID), which distinguishes it from agent_oneshot_relay_calls (submission) and agent_oneshot_get_capabilities/get_fee_data (static info). It does not explicitly name those siblings, so the differentiation is implied rather than stated.

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 a submitted task ID' implies the usage context: this is the follow-up call after relay_calls has accepted a task. However, there is no explicit when-to-use/when-not, no named alternative, and no guidance on how often to poll or when to stop.

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 it does disclose the two most important traits: the dry-run/preview default and the confirm=true gate required to actually submit. It omits failure modes, fee-charging behavior, and irreversibility of a relayed bundle, which keeps it from a 5.

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, zero padding, with the core action front-loaded and the prerequisite and default-mode caveat following immediately. Every sentence 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 17-parameter mutation tool with no annotations and no output schema, the description covers the prerequisite and the submit gate but says nothing about what is returned (taskId, status, estimate payload) or how to follow up. The rich schema compensates for parameter gaps, but the return/follow-up story is left entirely implicit.

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% across all 17 parameters, so the schema already documents memo, chain, confirm, estimateOnly, skipEstimate, payment fields, etc. The description adds no parameter syntax or format detail beyond reiterating the preview/confirm behavior, 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?

States a specific verb set (build, estimate, submit), a specific resource (ERC-7710 delegated transaction bundle), and the channel (1Shot public relayer). An agent can distinguish this from siblings like agent_oneshot_get_status, agent_oneshot_get_capabilities, or the generic send_calls without opening any schema.

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 a concrete prerequisite (an active 1Shot-compatible agent delegation whose delegate equals the relayer targetAddress) and the default operating mode (preview unless confirm=true). It does not name alternative tools for the estimate-only or status-checking paths, so it stops short of explicit when-not routing.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the unsigned payload is stored encrypted in the agent vault (a real side effect), but says nothing about required authority/permissions, reversibility, or that the delegation is inert until a separate signing step, leaving meaningful gaps for a mutation 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?

Three tight sentences with the core action, the default configuration, and the storage side effect front-loaded in that order. 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?

For a 20-parameter, workflow-critical tool with no annotations and no output schema, the description covers the defaults but omits the surrounding workflow (subsequent signature/completion steps) and what the caller gets back. It is serviceable but doesn't fully orient the agent within the delegation lifecycle.

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

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

Schema description coverage is 100%, so the schema already documents all 20 parameters, including defaults for chain, scopeType, token, and periodDuration. The description merely restates the headline defaults (1Shot relayer, Base USDC daily scope) without adding new parameter meaning, so the baseline 3 applies.

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

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

The description states a specific verb (Create), resource (a pending ERC-7710 delegation), and source (the connected WalletChan wallet), which is concrete and unambiguous. It implies this is the first step via 'pending' and 'unsigned', but never names the follow-up siblings (agent_request_delegation_signature, agent_complete_delegation), so differentiation is contextual rather than 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 implied by the operation itself and by the default-relayer framing, but the description gives no explicit when-to-use guidance, no prerequisites, and no reference to sibling tools that carry the delegation workflow forward. An agent must infer that signing/completion is a separate tool.

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 does usefully disclose the signing primitive (eth_signTypedData_v4) and that approval happens interactively in the WalletChan popup by the main wallet, which is real behavioral context. It omits error/rejection behavior, wallet/permission requirements, and whether the request blocks.

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

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

Two short sentences, front-loaded with the action and resource, then the approval mechanism. Nothing is padded.

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?

Adequate minimum for a single-parameter signing request with no output schema, but thin given zero annotations: the agent is not told what a successful signed result enables next, what happens on rejection, or how this fits with agent_complete_delegation.

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?

One parameter with 100% schema description coverage, so the schema already explains delegationId as 'Pending delegation ID returned by agent_prepare_delegation.' The description adds no additional parameter meaning, 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?

States a specific verb ('Open ... eth_signTypedData_v4 request') and a specific resource ('pending agent delegation'), which distinguishes it from generic siblings like sign and sign_siwe. It stops short of naming which sibling precedes or follows it in the flow.

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

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

The phrase 'for a pending agent delegation' implies it should be called after a delegation is prepared (schema points at agent_prepare_delegation), but there is no explicit when-to-use, no when-not, and no mention of the natural follow-up (agent_complete_delegation).

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 burden and does well: it discloses the destructive sweep scope, the notable fact that the vault is not decrypted, and the required confirmation gates. The only gap is that irreversibility of the loss is implied by 'Forget' but never stated outright.

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 front-loaded sentences: what it does, when to use it, and the preconditions. Every sentence earns its place with no filler or repetition.

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 no-annotation tool with no output schema, the description covers the scope of destruction, the non-decryption behavior, and the confirmation requirement. Only minor omissions remain, such as whether the state is recoverable or what the vault file becomes afterward.

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 both parameters are already fully documented in the schema. The description restates confirm=true and confirmationText=RESET_AGENT_VAULT, adding no meaning beyond the structured fields. 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?

States a specific verb ('Forget') plus the exact resources it sweeps: all local agent wallets, delegations, and the default agent profile. The bulk scope ('all') distinguishes it from single-item siblings like agent_delete_wallet and agent_delete_delegation without opening their schemas.

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 an explicit when-to-use trigger ('intentionally want a fresh agent-wallet setup') and a concrete motivating scenario ('after removing an old env vault secret'). It does not name a specific alternative or state when NOT to use it, 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 behavioral burden. It usefully discloses the payment path (ERC-7710 delegation vs raw EOA) and that the EOA path is the exceptional one, but omits critical traits for a payment tool: irreversibility of the spend, whether a delegation must pre-exist, and failure/settlement behavior when the resource returns an error.

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: purpose first, then the one non-obvious default-versus-explicit decision. Nothing is wasted, though the second sentence packs two distinct ideas (default path and exception) into one clause and could front-load the exception more sharply.

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

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

For a 12-parameter payment tool with no annotations and no output schema, the description covers the central profile tradeoff but leaves out prerequisites, spend irreversibility, and how to obtain a quote before paying. Adequate but with clear gaps an agent would need filled elsewhere.

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 one bit of parameter guidance in the description (profileId / agent-eoa form) is already documented verbatim in the schema's profileId field, so the prose adds little beyond what the structured data provides.

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

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

States a specific verb pair (pay and fetch) and a precise resource type (x402-protected HTTPS resource), which is more specific than most siblings. It does not explicitly differentiate itself from near-neighbors like veil_pay_x402 or agent_x402_quote, so an agent must infer the boundary rather than being told it.

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 does give genuinely useful routing guidance for the profile choice: default uses the main wallet's ERC-7710 delegation, and agent-eoa:<walletId> is only for raw agent-wallet payment. However it never says when to call this versus the sibling quote tools (agent_x402_quote, veil_x402_quote) or what prerequisites (e.g. an established delegation) must hold first.

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 burden and does disclose the critical trait: no signing and no payment submission, i.e. a safe read-only probe. It does not describe error behavior, network cost, or that wallet/profile resolution is required for the delegation answer, leaving some behavioral gaps for a 10-parameter 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?

Two tight sentences with no filler; the core action is front-loaded and the outcome it reports follows immediately. 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?

For a 10-parameter tool with no output schema, the description states the purpose, the safety behavior, and broadly what is returned. It stops short of describing the response shape or the meaning of the ERC-7710 delegation/fee result, but the fully documented schema covers the invocation side.

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 every parameter (url, body, chain, method, headers, walletId, profileId, timeoutMs, tokenDecimals, maxResponseBytes) is already documented with defaults and constraints. The description adds no additional syntax, format, or inter-parameter semantics 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?

States a specific verb ('Probe') applied to a specific resource ('x402-protected HTTPS resource') and specifies what is reported. The phrase 'without signing or submitting payment' cleanly separates it from the paying siblings (agent_x402_pay, veil_pay_x402) without needing to name them.

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 the usage context (probe before committing to payment) but never states it explicitly or names alternatives such as agent_x402_pay. An agent can infer when to use it, but there is no explicit when/when-not guidance or sibling routing.

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 a meaningful side effect: calls are submitted to WalletChan and require popup approval unless previewOnly is true. But it says nothing about irreversibility of the bridge, fund movement, the role of executionProfile/atomicRequired, or failure/fallback behavior, so the safety profile is only partially 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?

A single dense sentence that front-loads the core action (quote, build, submit) and puts the previewOnly exception at the end where it belongs. No wasted words, though the sentence packs three distinct operations without separating them.

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 20-parameter, no-annotation, no-output-schema tool that performs an on-chain bridge, the description is thin. The rich schema compensates on parameters, but the description leaves the agent without routing guidance versus siblings or any note on execution profiles, atomicity, and what the returned prepared calls are for.

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

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

Schema description coverage is 100% with 20 well-documented parameters, so the schema already does the heavy lifting and baseline 3 applies. The description adds only the previewOnly meaning, duplicating what the schema's previewOnly description already states.

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 — quote a WalletChan bridge, build approval + bridge calls, submit them — which is more than a restatement of the name 'bridge'. It distinguishes the full quote-and-submit flow from the quote-only sibling get_bridge_quote, though it never names that sibling explicitly.

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 flow description and the 'unless previewOnly is true' condition, which tells the agent how to get a dry run. However there is no explicit guidance on when to prefer this over get_bridge_quote, swap, or get_bridge_status, and no stated prerequisites (e.g. an approved account).

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 does disclose a real safety boundary ('allowlisted'), but says nothing about side effects (an arbitrary pass-through 'arguments' object could be a mutation), auth requirements, or timeout behavior despite exposing timeoutMs.

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, no filler, with the core action front-loaded and the routing caveat second. 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?

For a generic dispatcher taking an opaque nested 'arguments' object with no output schema, the description is thin: it doesn't explain that valid tool names/arguments vary per protocol nor hint at return shape or error behavior. Adequate as a minimal pointer to the raw layer, but not complete for the tool's 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 description coverage is 100%, so the schema already documents tool, protocol, arguments, and timeoutMs, including the current 'veil' protocol id. The description adds no parameter-level meaning 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 and resource ('Call a raw allowlisted protocol tool') and scopes it ('raw allowlisted'), which distinguishes it from the many first-class veil_* wrappers named in the description. It signals the generic-dispatcher role without restating the title.

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?

'Prefer first-class WalletChan wrappers when available' is an explicit routing rule that tells the agent to fall back here only when no dedicated wrapper exists, which is meaningful given the large sibling set of veil_* tools. It lacks detail on when this is mandatory (e.g., unnamed/tool not yet wrapped) but the exclusion is clear.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it does disclose the allowlist constraint and blocked login tools. But it omits whether the remote call may mutate state, what auth/permissions are required, how failures surface, and there is no output schema to fall back on — significant gaps for a generic passthrough that can invoke arbitrary remote tools.

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 with no filler, and the core action is front-loaded ahead of the login-tool exclusion. Efficient, though the second sentence is narrowly scoped relative to the routing the tool actually needs.

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 bridge tool with a nested free-form arguments object, no annotations, and no output schema, the description leaves too much unsaid: how results are returned, how remote errors are surfaced, and how to discover allowlisted tools/profiles. The schema covers parameters, but behavior and return handling are largely unexplained.

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

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

Schema description coverage is 100%, so the schema already documents tool, profile, and the free-form arguments object; baseline is 3. The description adds no syntax, format, or naming guidance beyond what the schema states.

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: 'Call an allowlisted protocol MCP tool through WalletChan MCP.' It partially differentiates from siblings by ruling out login tools, but never names list_remote_mcp_tools (discovery) or call_protocol_tool (local counterpart), so an agent cannot fully distinguish it from those without reading schemas.

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

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

It gives one explicit exclusion plus an alternative ('Login tools are blocked here; use the remote SIWE login helpers'), which is real routing guidance. However, it says nothing about when to prefer this over call_protocol_tool or list_remote_mcp_tools, nor how to obtain valid tool names/profiles before calling.

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 key downstream side effect (fallback to walletconnect for future mutating tools). It omits whether the operation is idempotent, what happens if no default is currently set, and whether the clearing is reversible, so disclosure is partial.

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 with zero waste; the action is front-loaded and the consequence follows. Every sentence earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description covers the action and its main effect on subsequent tool calls, which is the information an agent needs. Minor gaps remain around idempotency and behavior when no default is set, 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 per the baseline there is nothing for the description to disambiguate. No parameter semantics are needed.

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

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

The description states a specific verb (clear) and resource (stored default execution profile), and it is trivially distinguishable from its siblings get_default_execution_profile and set_default_execution_profile by operation. It does not explicitly name those siblings, but the operation 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?

It implies when this matters by describing the consequence ('future mutating tools fall back to walletconnect'), which gives context for choosing it. However, it never states when to prefer this over set_default_execution_profile or list_execution_profiles, nor any prerequisite, so usage is only implied.

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 entire behavioral burden and falls short: it does not say whether the loginId is single-use or expires, what happens if the signature was not approved, what session/credential is established on success, or whether this is idempotent. Only the approval precondition 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 no filler and the action verb first. It is very terse rather than bloated; the only reason it is not a 5 is that the brevity spills over into under-specification of a stateful step.

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?

No annotations, no output schema, and no enum means the description is the only behavioral source, yet it omits what the call returns (session token, success/failure semantics), the expiry/retry behavior of loginId, and the explicit link back to start_remote_mcp_siwe_login. For a stateful two-step handshake this leaves real 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?

There is a single parameter with 100% schema description coverage, so the schema already explains that loginId comes from start_remote_mcp_siwe_login. The description adds no format, validity, or lifecycle detail beyond that, so the baseline 3 for a fully-documented param 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?

States a specific verb ('Complete') and resource ('remote MCP SIWE login'), and the phrase 'after the WalletChan signature request has been approved' ties it to a distinct workflow step that separates it from start_remote_mcp_siwe_login. The domain jargon (SIWE, WalletChan) is not explained, but an agent can still tell this is the terminal step of a login handshake rather than a new login or a generic sign.

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

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

It gives an implicit precondition ('after the WalletChan signature request has been approved'), which is useful sequencing context. However, it never names start_remote_mcp_siwe_login as the required predecessor, states no when-not conditions, and offers no alternatives or error-path guidance, so the agent must infer the full call order.

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 only discloses the backend source ('same first-party Bungee proxy as the extension'). It never states that this is a non-executing read, whether quotes expire, whether they are gasless or require approval, or any rate-limit/auth behavior — material facts for a quote tool that feeds a later 'bridge' call.

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 filler — the resource and the route are established immediately. It is not padded, though the extreme brevity is arguably under-specification for a 15-parameter tool rather than a virtue.

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 15-parameter, two-required, no-output-schema tool with no annotations, one sentence leaves too much unsaid: no return-value shape, no quote lifecycle (quote then bridge), no defaults summary, and no relationship to sibling quote/status tools. The proxy detail is helpful but far from sufficient.

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

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

Schema description coverage is 100% across all 15 parameters, including aliases (chain/originChain, from/userAddress, decimals/tokenDecimals) and slippage overrides, so the schema does the heavy lifting. The description adds nothing about parameter meaning, defaults, or which of the two required params are the minimum viable set; 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?

States a specific verb and resource ('Fetch a WalletChan bridge quote') and identifies the backend route (first-party Bungee proxy). The word 'quote' implicitly separates it from the execution sibling 'bridge' and from 'get_bridge_status', but the description never names or contrasts those siblings explicitly, so an agent must infer the routing.

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 guidance: nothing says this is the read-only pricing step that should precede 'bridge', nor how it relates to 'get_swap_price', 'get_bridge_status', or the veil/x402 quote tools. The agent is left to guess the call sequence from the name 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 behavioral burden. 'Fetch' implies a read-only lookup, but the description does not state that the call is safe/idempotent, whether authentication is required, what happens when a hash is unknown or the bridge is pending, or any latency 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?

A single front-loaded sentence with no filler; the resource and both identifier options come first. It is appropriately sized, though it could have spent one more clause on the requestHash/txHash relationship.

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, no output schema, and 0% parameter description coverage, the one-sentence description is thin. It leaves the agent guessing about mutual exclusivity of the two keys, error behavior for unknown hashes, and the shape of the returned status.

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%, so the description must compensate. It does add value by clarifying that requestHash is a Bungee request hash and txHash is a source transaction hash, going beyond the bare 'string' types. It still omits whether the two are mutually exclusive, which takes precedence, and expected hash formats.

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 (fetch), resource (WalletChan bridge status), and the two lookup keys, so an agent knows exactly what it returns. It is distinguishable from siblings like get_bridge_quote or bridge, though it does not explicitly differentiate itself from get_request_status or veil_deposit_status, which also fetch statuses.

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 naming the two accepted identifiers (Bungee requestHash or source txHash), which tells the agent when the tool applies. However, it gives no guidance on which key to prefer, whether either is required, or how this differs from the other status-fetching siblings.

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 full behavioral burden. It does disclose the fallback behavior ('Defaults to walletconnect when no explicit default is stored'), which is useful. However, it doesn't state whether this is a safe read operation, whether it requires authentication, or what the return value looks like in detail. For a read-only tool this is partially adequate but leaves gaps.

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 with zero waste. The primary purpose is front-loaded, and the fallback behavior is stated immediately after, making it easy to parse.

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 no annotations and no output schema, the description should do more to describe the return format (e.g., what an execution profile contains) or any authentication requirements. The fallback default is covered, but completeness is minimally adequate for a tool that returns a non-trivial configuration object.

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 is 4. The description does not need to explain parameter semantics, and it correctly avoids doing so.

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 ('stored default execution profile'), clearly distinguishing it from siblings like list_execution_profiles and set_default_execution_profile. It doesn't name those siblings explicitly, but the resource is precise enough that an agent can identify the correct tool.

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

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

The description implies usage context ('stored default'), but provides no explicit when-to-use or when-not-to-use guidance relative to alternatives like list_execution_profiles. The sibling set is large, and an agent might be unsure whether to fetch the default profile directly or list all profiles first.

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 meaningful behavior: it may start a process as a side effect, the URI type varies by transport, and it emits an MCP image content block (QR) before the text fallback. It does not state auth requirements, failure modes, or what happens to existing sessions (that detail lives only in the forceNewSession schema text).

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

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

Three sentences, front-loaded with the action and return value, then transport variability, then output format. Every sentence carries information; a small amount of compositional looseness but 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?

There is no output schema, and the description compensates by naming the return values and the QR image content block. With zero required parameters and all optional params fully documented in the schema, the description covers what an agent needs, though it could say more about when pairing will not be needed.

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 every one of the 7 optional parameters is already documented in the schema, including the alias relationships and the account/forceRequest pairing. The description adds no parameter-level guidance, which is acceptable given full coverage but earns only 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?

The description gives a specific verb+resource pair ('Start or inspect the managed WalletChan RPC bridge') and names exactly what is returned ('the wallet pairing URI and local QR page URL'). No sibling tool covers wallet pairing, so this is unambiguous even among ~60 siblings.

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

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

'when pairing is needed' implies a trigger condition, and the force/forceNewSession/forceRequest params hint at re-pairing scenarios, but the description never states when an agent should call this versus e.g. agent_list_wallets or get_wallets, nor does it note prerequisites. Usage is implied rather than instructed.

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. 'Fetch' signals a read, and the disclosure that results include tokens and DeFi positions adds useful scope information, but it omits any note on auth requirements, data freshness, or return 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 names the action, resource, and target options in one pass with no filler or repetition.

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 low-risk read tool with fully documented optional parameters and no output schema, the description is minimally adequate. It leaves the agent to infer how this differs from the many other balance-listing siblings and what the response contains.

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 five optional parameters (from, limit, address, includeDefi, minValueUsd) are already documented in the schema. The description's mention of DeFi positions loosely maps to includeDefi but adds no syntax or defaults beyond what the schema states.

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 (Fetch) and resource (WalletChan portfolio balances) and scopes the output to tokens and DeFi positions. It is distinguishable from single-balance siblings like agent_eoa_get_balance, but it never names an alternative to clarify the boundary.

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 notes it works 'for an address or the connected WalletChan account', which loosely implies a targeting choice, but gives no explicit when-to-use guidance or exclusions relative to veil_get_balances, veil_x402_payer_balances, or agent_eoa_get_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?

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, but the description never states whether the call is idempotent, whether it blocks, whether statuses are terminal, or what happens with an unknown/expired id. For a polling-style status tool with zero annotation coverage, this is a meaningful gap.

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-formed sentence with no filler, and the resource is front-loaded. It is appropriately sized for the tool's simplicity, though it is arguably too short to carry the missing behavioral 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?

There is no output schema, so the description is the only place to convey what the returned status looks like or how to interpret it, and it omits this entirely. Combined with no annotations and no usage guidance, the definition is incomplete for a tool whose primary value is interpreting a status value.

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 both id and requestId are fully documented in the schema, including the alias relationship and the origin of the id. The description adds nothing 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?

The description names a specific verb (get) and resource (status of a WalletChan MCP request / wallet_sendCalls bundle), which is better than a tautology. However, the sibling list contains many other status tools (agent_oneshot_get_status, get_bridge_status, veil_deposit_status, veil_status), and the description does nothing to distinguish this one from them. The scope is clear but not differentiated.

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 the other status tools, no mention of polling cadence, and no note on prerequisites (e.g., that a requestId must first come from send_calls, sign, or send_transaction). The agent must infer all usage context.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Indicative' is a genuinely useful disclosure (non-binding, may change), but it says nothing about rate limits, freshness, auth/account requirements, or side effects. For a read-only quote tool the safety profile is largely inferable from 'Fetch... price', but the description leaves gaps.

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. It is efficient, though the 'WalletChan'/'extension' references add little actionable information for an agent.

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?

Parameters are fully covered by the schema, but with 11 params, no annotations, and no output schema, the description should at least indicate what the quote returns (price, route, amount) and any usage caveats. It is minimally adequate rather than 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 description coverage is 100%, so all 11 parameters including aliases (taker/from, tokenDecimals/decimals) and defaults are already documented in the schema. The description adds no parameter meaning beyond that, so 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?

States a specific verb and resource (fetch a swap price) and scopes it as 'indicative' via the same first-party API as the extension, which distinguishes it from the sibling execution tool 'swap'. It does not name or contrast with siblings explicitly, 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?

No explicit when-to-use guidance. 'Indicative' hints this is a pre-trade quote rather than execution, but the description never tells the agent to call this before 'swap' or instead of 'get_bridge_quote', nor states any prerequisites.

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 discloses almost nothing: no indication of auth/permission requirements, whether it is a safe read, what 'approved' means, or what the response contains. 'Get' weakly implies read-only, but that is inference, not disclosure.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness is part of why coverage elsewhere is thin.

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

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

For a tool with no annotations, no output schema, and an opaque domain concept ('WalletChan RPC accounts'), the description is too thin to let an agent call it confidently. It leaves undefined what is returned, whether an empty result is meaningful, and how it relates to the other wallet-list tools.

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 sole 'chain' parameter (name or ID, used to validate against configured RPC chains) is fully documented in the schema. The description adds no meaning beyond that, which is acceptable at baseline 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 verb 'Get' plus the resource 'approved WalletChan RPC accounts and configured chains' gives a rough idea of purpose, but the concept of an 'RPC account' versus the many other wallet-listing siblings (agent_list_wallets, agent_get_wallet, veil_get_balances) is never disambiguated. An agent cannot tell from this sentence which wallet universe this returns or how it differs from agent_list_wallets.

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 the numerous alternative wallet/chain listing tools in the sibling set. The optional chain parameter hints at a validation use case, but the description states no conditions for use 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?

No annotations exist, so the description carries the burden, and it does disclose scope ('available inside WalletChan MCP') and that the operation is a listing. It does not state whether auth/pairing is required or what the returned runner records contain. For a zero-parameter read tool the bar is low, but more behavioral context could be given.

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 and object come first. Every word 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 output schema and no annotations, the description is the only spec, and it does not explain the shape of the result or how the returned runners map to commands in run_base_plugin_cli. Adequate as a one-line summary but thin for a tool whose entire value is the returned inventory.

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 compensate for and the baseline of 4 applies. No parameter-related text is 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?

States a specific verb ('List') and resource ('pinned protocol CLI runners and supported commands'), which distinguishes it from the sibling run_base_plugin_cli that executes them. However, 'pinned protocol CLI runners' is internal jargon that is never unpacked, so an agent infers rather than knows exactly what entities are being enumerated.

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 guess this is a discovery step preceding run_base_plugin_cli, but the description never says when to call it, what prerequisite it serves, or that it is the lookup before execution. No exclusions or alternatives are 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 burden, and it does add real domain context: walletconnect routes through the existing popup path while agent/agent-eoa are local delegated vs raw execution profiles. However, it says nothing about read-only nature, whether the list is static or dynamic, or how profiles relate to the default-profile siblings.

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 the action, no filler. The second sentence is dense but each clause conveys distinct profile semantics rather than padding.

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?

There is no output schema, so the description is the only signal about what comes back. It names the three profile categories but never describes the return shape (names, identifiers, ordering, whether defaults are flagged), leaving an agent to guess before calling.

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 is 4. There is nothing for the description to clarify on the input side.

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 ('List WalletChan execution profiles') and then defines what each profile category means. It is clearly distinguishable from siblings like get_default_execution_profile or set_default_execution_profile, though it never explicitly contrasts itself with them.

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 explains what the profile types are, but not when an agent should call this tool versus get_default_execution_profile, set_default_execution_profile, or the agent_* wallet tools. No prerequisites or conditions for use are 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 behavioral burden. It does not state that this is a read-only operation, whether it requires authentication, or whether there are rate limits or side effects. The word 'List' implies a read, but nothing is explicitly 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?

The description is a single well-formed sentence with the verb and resource front-loaded. It contains no filler and is appropriately sized for a simple listing tool.

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

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

Given the tool's simplicity, zero parameters, and no output schema, the description is minimally adequate. It names the category of things returned but does not describe the shape of a protocol integration entry or any pagination behavior, leaving some gap for an agent unfamiliar with the domain.

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 are no parameter semantics to explain. Baseline 4 applies for a correctly parameterless definition.

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 and resource: 'List protocol integrations managed by WalletChan MCP'. It also enumerates the kinds of integrations included, which clarifies scope. However, it does not distinguish this tool from close siblings like list_protocol_tools or list_remote_mcp_tools, so it falls 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?

The description states what the tool lists but gives no guidance on when to use it versus alternatives such as list_protocol_tools or list_remote_mcp_tools. There are no exclusions, prerequisites, or contextual cues for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain the output shape (raw tool list), whether the result is cached, whether it requires authentication, or if any side effects occur. For a discovery tool with zero annotation coverage, this is a notable gap.

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 that efficiently states the tool's function without unnecessary 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?

Given the tool has one required parameter, no output schema, and no annotations, the description should do more to explain what 'raw tools' means, what the return value looks like, and any limitations. It is currently underspecified for an agent to invoke it confidently in context.

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

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

Schema description coverage is 100% (the 'protocol' parameter is fully documented with its allowed value), so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already provides.

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

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

The description states a specific verb+resource ('List raw tools exposed by a managed protocol integration'), which is clear enough. However, it does not differentiate itself from similar siblings in the list such as 'call_protocol_tool', 'list_protocols', or 'list_remote_mcp_tools', leaving the agent to infer 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, nor any mention of alternatives. The agent must guess whether this is the right tool for discovering protocol capabilities versus related listing 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?

No annotations are provided, so the description carries the full burden. It discloses the allowlist constraint and the currently supported profile, which is useful, but omits auth requirements, whether it is a read-only operation, and any rate or scope limits. Adequate but incomplete for a tool with zero annotation coverage.

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 scope. Every sentence earns its place; there is no padding.

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

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

For a simple one-parameter read tool with a fully covered schema and no output schema, the description supplies the key scoping context (allowlist, current profile support). It is largely complete, missing only auth/behavioral notes.

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%, and the single 'profile' parameter is fully documented in the schema with its current allowed value ('virtuals'). The description adds no format or syntax detail beyond the schema, so the baseline 3 is correct.

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 clear verb+resource ('List tools from an allowlisted protocol MCP profile') and names the supported profile. It distinguishes the remote-MCP concept from plain protocol tools only implicitly; it does not explicitly contrast itself with the sibling list_protocol_tools or call_remote_mcp_tool.

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 guidance and no mention of alternatives such as list_protocol_tools or call_remote_mcp_tool. The scope note ('Currently supports the Virtuals ACP MCP profile') hints at applicability but does not tell the agent when this tool is the right choice.

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. It does not say whether this is a read-only lookup, what scope of resources is returned (all skills? installed plugins?), whether results are filtered or paginated, or if any auth/connection to the MCP server 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 short sentence with no filler and the subject front-loaded. It is efficient, though not maximally informative.

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

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

With no output schema and no annotations, the description should describe the returned shape or content of "resources" (skills vs. adapted Base plugins, identifiers, counts). It leaves the agent guessing what a call actually yields.

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 clarify; the baseline for a parameterless tool applies. No parameter semantics gap exists.

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 verb ("List") and a resource ("WalletChan MCP skill and adapted Base plugin resources"), which is more than a tautology. However, "resources" is undefined and it does not distinguish itself from sibling list tools such as list_base_plugin_runners, list_protocol_tools, or list_remote_mcp_tools, so an agent cannot confidently route between them.

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 indication of when to call this tool, what triggers it, or which alternative list tool to use instead. The many sibling "list_*" tools make this omission costly.

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 full behavioral burden. It hints that execution overrides are prepended, but does not describe side effects, persistence, permissions, or what happens after loading.

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 with no wasted words, and the core action is front-loaded. However, the jargon-heavy phrasing slightly reduces immediate clarity.

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 no annotations and no output schema, the description should explain what loading a plugin reference does, whether it persists, and how it affects subsequent calls. It leaves these critical details unaddressed.

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%, and the single parameter is fully documented in the schema. The description adds no extra meaning beyond 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?

States a specific verb ('Load') and a resource ('upstream Base MCP native plugin reference'), but the term 'plugin reference' is jargon that an agent may not understand. It does not differentiate from siblings like run_base_plugin_cli or list_base_plugin_runners, leaving the exact outcome ambiguous.

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 guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when-not-to-use, or how it relates to sibling tools such as run_base_plugin_cli or list_base_plugin_runners.

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 supplied, so the description carries the full burden. It does disclose the RPC fallback order and the set of supported naming systems, which is genuinely useful behavior beyond the schema. It does not describe failure behavior (error vs. null on unresolvable names) or any rate limits, leaving the read semantics partially covered.

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

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

Three tight sentences, front-loaded with the core action and followed by supported inputs and resolution order. Every sentence carries information; no filler or restatement of the title.

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 read tool with no output schema, an agent still needs to know the return shape and failure mode. The description implies an EVM address return but never states it explicitly nor explains what happens when a name cannot be resolved, and it omits any differentiation from 'resolve_names'.

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% and the schema already gives concrete examples (vitalik.eth, name.base.eth, name.wei, name.gwei, name.mega). The description adds the mapping of suffixes to naming services, which is mild added value over the schema, so baseline 3 is correct.

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: 'Resolve a user-provided WalletChan-supported name to an EVM address.' That is unambiguous. However, the sibling tool 'resolve_names' (plural) is nearly identical in name, and the description does nothing to distinguish this singular tool from that sibling, which is a notable omission in a crowded namespace.

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 useful context — it enumerates supported name services (ENS, Basenames, WNS, GNS, MegaNames) and the lookup order (MCP RPC overrides, then WalletChan default RPCs) — but never says when to prefer this tool over 'resolve_names' or what to do if resolution fails. Usage is implied rather than guided.

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 enumerates the supported naming services, which is useful, but says nothing about what happens to unresolvable names (skip, error, null), whether the call is all-or-nothing, which chain it resolves on, or whether any network/latency costs apply.

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 with the core action front-loaded and the supported-domain list trailing it. Nothing is padded, though the domain enumeration reads as a bare list rather than integrated guidance.

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 resolution tool there is no output schema and no annotations, so the description should at least hint at the return shape (parallel address array, ordering, failure handling). It covers the input domain well but leaves the output contract unspecified.

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 the single parameter is documented as "Names to resolve." The description adds the supported name syntaxes (ENS/subdomains, Basenames, .wei, .gwei, .mega), which goes modestly beyond the schema but not deeply into format expectations. 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?

States a specific verb and resource (resolve names to EVM addresses) and clarifies the input is multiple user-provided names. It does not distinguish itself from the sibling resolve_name, which is the singular counterpart, so an agent must infer the batch-vs-single split on its own.

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 explicit when-to-use guidance and no mention of the obvious alternative resolve_name. The only usage signal is implicit in the enumerations of supported name types and the plural "multiple names".

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 behavioral burden. It does disclose meaningful traits: commands are 'pinned' and 'allowlisted' (a safety boundary) and output can be submitted on-chain via WalletChan (a write capability). However, it omits failure modes, approval/permission requirements, and what happens when a command is not allowlisted.

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 the core action and constraint. The second sentence is slightly vague about what 'configured' runners and 'prepared transaction output' mean, but 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 12-parameter tool with nested object args, no annotations, and no output schema, the description is thin. It frames the security model and the optional submission path but does not explain how command/args interact, what a runner is, or the executionProfile flow, leaving gaps for such a complex surface.

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 12 parameters are already documented in the schema (including enum values, executionProfile formats, and submitPreparedCalls semantics). The description adds no syntax or behavioral detail beyond that, so 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 and resource: 'Run a pinned, allowlisted protocol CLI command from the local WalletChan MCP process,' and names the runner scope (configured Base plugin CLI runners). It clearly distinguishes itself from discovery siblings like list_base_plugin_runners, though it doesn't explicitly contrast with call_protocol_tool or load_base_plugin.

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 guidance, no prerequisites (e.g., that a runner must first be loaded/listed), and no named alternatives. The agent must infer that list_base_plugin_runners is the discovery step and that call_protocol_tool is a different path.

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 does disclose real behavioral traits: ERC-5792 batching, and that fallback executes calls sequentially as individually user-approved transactions. It omits critical context such as what 'approved account' means, whether calls can partially succeed, and the implications of atomicRequired defaulting to true.

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, front-loaded with the primary purpose and followed by the fallback behavior. No filler; the only weakness is that the fallback sentence could read as implementation trivia if the agent isn't selecting between submission paths.

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 6-parameter mutation tool with no annotations and no output schema, the description is thin. It covers the execution mechanism but omits the approval/permission model, failure semantics, and the distinction from four similarly named sibling submission tools.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter detail beyond the schema, which already documents from, calls, chain, profileId, atomicRequired, and executionProfile.

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?

Clear and specific: 'Submit wallet calls through WalletChan RPC' states verb and mechanism. It does not, however, differentiate from the close siblings send_prepared_calls, agent_eoa_send_calls, or agent_oneshot_relay_calls, so an agent cannot tell from the description which of these four submission tools to use.

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

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

Explains the internal fallback mechanism (ERC-5792 vs sequential) but gives no guidance on when to choose this tool over send_transaction, send_prepared_calls, or the agent_eoa/oneshot variants. No prerequisites or preconditions are 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. It does disclose useful behavior: accepted input shapes and a sequential fallback for non-batching wallets. But it omits permission/auth requirements, whether submission is irreversible, and what the fallback means for atomicity. Partial coverage for a mutation tool with zero annotation support.

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 tight sentences with the core action front-loaded, then accepted shapes, then fallback behavior. No filler, though the shape list is compacted rather than fully explained.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers input normalization and fallback but leaves return values, auth needs, and error/warning handling (beyond the allowWarnings flag in schema) undescribed.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters including defaults and the executionProfile enum-like values. The description adds the normalization-shape context but no parameter-level detail beyond 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?

States a specific verb chain (normalize + submit) on a specific resource (Base plugin prepare response) and names the transport (WalletChan). This distinguishes it clearly from send_calls, send_transaction, and agent_oneshot_relay_calls.

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 the tool is for harness-fetched Base plugin prepare responses, which implies usage context, but it never states when to prefer it over send_calls or agent_oneshot_relay_calls, nor any 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the call only 'starts' a request and requires 'user approval' (implying an async, human-gated flow), but it does not say what happens after starting, whether anything is irreversible, what auth/permissions are needed, or how the request is later resolved.

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, and the approval/transport information arrives immediately. It is appropriately sized for what it attempts, though the brevity contributes to the coverage gaps elsewhere.

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

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

For a 7-parameter transaction-submitting tool with no annotations and no output schema, the description is too thin. It omits the approval lifecycle (e.g., that status is later checked via get_request_status), the difference between execution profiles, and any routing guidance among the many send_* and sign siblings.

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 86%, so the property descriptions already document to/data/from/chain/value/profileId/executionProfile. The prose adds only the framing of a single transaction and the WalletChan RPC route, 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 names a specific verb ('Start'), the underlying resource ('eth_sendTransaction request'), and the transport ('WalletChan RPC'), and the word 'single' hints at the distinction from the batch-oriented send_calls / send_prepared_calls siblings. It stops short of explicitly naming an alternative, so an agent must infer the contrast.

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. With siblings like send_calls, send_prepared_calls, agent_eoa_send_transaction, and agent_oneshot_relay_calls all capable of sending transactions, the description never says which path to pick or what prerequisites apply.

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 setting is persistent and affects future mutating tools, but omits whether an existing default is overwritten, whether auth is required, or what happens if the profile ID is invalid.

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, zero filler, with the action and scope front-loaded ahead of the value enumeration. 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?

For a single-parameter setter with no output schema and no annotations, the description covers purpose, scope, and value syntax adequately. Only edge-case behavior (overwrite, invalid ID, persistence duration) is left 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 100%, so the baseline is 3, but the description goes further by enumerating the three concrete profile ID forms (walletconnect, agent:<walletId>, agent-eoa:<walletId>) that the schema only gestures at. That is genuine added meaning 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 verb ('Store'), the resource ('default execution profile'), and the scope ('for future mutating WalletChan MCP tools'), which distinguishes it cleanly from the get/list/clear_default_execution_profile siblings. An agent knows exactly what state this mutates.

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 explains the valid profile values but never states when to prefer setting a persistent default versus passing a profile per call, nor whether this must precede other tool calls. Usage is implied rather than guided.

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 approval happens asynchronously in a popup, which is non-obvious. But it omits whether the call blocks or returns a pending handle, and gives no hint that completion must be checked via the get_request_status sibling.

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

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

Two short sentences, front-loaded with the action and immediately followed by the salient behavioral fact. 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 5-parameter tool with no annotations and no output schema, the description is thin. It never says what the tool returns (a request ID or a signature), how the caller retrieves the result, or that it relates to get_request_status, leaving the agent without the information needed to complete the flow.

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 every parameter (data, type, chain, address, message) is already documented in the schema, including the enum values and defaults. The description adds nothing beyond this, 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?

States a specific verb ('Start') and resource ('WalletChan signature request'), so an agent knows this initiates a signing flow. However, it does not distinguish itself from the sibling sign_siwe or explain whether it covers personal_sign vs typed data (that detail lives only in the schema).

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 only guidance is the approval-flow note ('The user approves in the WalletChan popup'). There is no statement of when to use this versus sign_siwe or send_transaction, no prerequisites, and no indication of what happens after the request starts.

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 validation precedes the request and that a personal_sign request is *started* (not completed), and stresses the exact message is signed. It omits permissions/auth requirements, what the call returns, and how to continue the flow after the request starts.

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 efficient sentence with the validate-then-sign sequence front-loaded and no filler. It is arguably too terse for a 15-parameter signing tool, but on the conciseness axis itself there is no waste.

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

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

The schema is rich (100% coverage) and covers inputs well, but for a signing flow with zero annotations and no output schema, the description should clarify the security/permission implications and what the started request yields. As written, an agent knows the inputs but not the operational consequences.

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 every one of the 15 parameters is self-documented, including the 'message omitted' vs 'message provided' distinction. The description adds no parameter-level meaning beyond the schema, which is the expected baseline 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?

The description names a specific two-step operation: validate an EIP-4361 SIWE message, then start a WalletChan personal_sign request. That is a clear verb+resource. It does not, however, distinguish this from siblings like 'sign' or 'start_remote_mcp_siwe_login'/'complete_remote_mcp_siwe_login', so an agent must infer the boundary.

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 and names no alternatives. The useful routing hint ('Preferred when returned by a protocol login_start tool') lives only in the schema for the 'message' property, not in the description, leaving the agent without explicit selection criteria.

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