WalletConnect session state

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

Annotations already declare readOnlyHint=true, and the description confirms this while adding the returned field set and signer-mode context, which is genuine added value. The sentence 'It dispatches transactions in DEXE_SIGNER_MODE=walletconnect' sits in a read-only status tool and is ambiguously scoped — an agent could misread it as this tool dispatching transactions, so the extra behavioral detail is present but not cleanly attributed.

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 safety profile front-loaded and the return fields packed into one parenthetical, so there is no wasted wording. The second sentence is the only weak spot — its referent ('it') is unclear and its placement after the field list muddies an otherwise clean structure.

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, the description carries the burden of explaining returns and it does so by naming every field the agent will receive. For a zero-required-parameter, read-only status tool this is nearly sufficient; only the ambiguous dispatch sentence leaves a small gap in understanding what the call actually reports.

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 chainId parameter is already documented in-schema as 'Unused; reserved.' The description adds nothing about it, which is acceptable given the parameter is inert; baseline 3 applies since the schema does the full job.

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 (read WalletConnect config plus live session state) and enumerates exactly what the agent gets back: connected?, account, chain, topic, peer wallet, last error. That field list distinguishes it from the sibling session-lifecycle tools dexe_wc_connect and dexe_wc_disconnect without requiring the schemas be opened.

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 lead-in 'Read-only' and the note about DEXE_SIGNER_MODE=walletconnect being the default give useful context for when this state is relevant. However, there is no explicit routing guidance telling the agent to use dexe_wc_connect when no session exists, or to prefer this tool over dexe_get_config for configuration questions — the when-to-use decision is only implied.

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