Get Pairing URI

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.