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

Annotations are empty, so the description carries the full behavioral burden. It does imply a non-mutating/display-only operation and links token and wallet_fk back to /access/login, which is genuine context. But it says nothing about pagination, result size, caching, or what 'assets' encompasses, and its return note is only 'a json object'.

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 structurally broken: the same opening sentence appears twice, the second copy is truncated mid-sentence ('any asse'), and free-form @param/@return tags are pasted in without clean formatting. It is repetitive rather than dense, so it fails the 'every sentence earns its place' test.

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

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

With no annotations and no output schema, the description must carry the return-shape burden, yet it only offers 'a json object'. For a four-parameter listing tool whose schema is entirely undocumented, the definition should at least sketch the asset fields and pagination behavior, and it does not.

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, and it largely does: all four parameters are addressed via @param, with token and wallet_fk traced to their origin at /access/login and blockchain_fk identified as the optional filter. The one gap is that api_key's scope/format is only restated ('allocated to your application') rather than clarified.

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

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

The opening line states a specific verb+resource: listing assets available to this wallet, filterable by blockchain. That is enough to distinguish it from write-oriented siblings like wallet_card_remove or withdraw_to_bank. However, it never differentiates itself from the close siblings wallet_accounts_list and wallet_accounts_list_verbose, which also list wallet-scoped resources.

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 asserts 'for display only' and 'every wallet may still make use of any asset', which hints at read semantics, but there is no statement of when to use this tool versus wallet_accounts_list, wallet_accounts_list_verbose, wallet_card_list or wallet_voucher_list. No prerequisites or exclusions are given.

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