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

Annotations already establish readOnly, idempotent and non-destructive, yet the description still adds real value: it previews the view contents (connection state, setup progress, verified buying power, proof-of-funds status, one recommended next step), specifies a privacy behavior (wallets summarized, never full addresses), and explicitly disclaims custody ('nothing here moves, sells, converts, or holds crypto'). Repeating 'Read-only' is redundant with readOnlyHint, keeping this 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?

Front-loaded with the action, then trigger conditions, then view contents, then safety scope. Efficient multi-sentence structure, though the closing crypto-custody sentence is somewhat defensive and partially redundant with the readOnly annotation and the preceding 'Read-only' statement.

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 an output schema present the description needn't explain returns, and annotations cover safety, so what remains — when to open it and what the user will see — is covered. The only gap is the undocumented realscore_report workflow value, leaving one invocation path 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 enum is self-documenting, so the baseline is 3. The description adds workflow intent ('open straight into one workflow') but enumerates only buying_power, verify_wallet, and proof_of_funds, silently omitting the realscore_report value that the schema actually accepts.

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 ('Opens the RealOpen home, the full-screen app in the ChatGPT sidebar') and immediately scopes what the resulting view shows. An agent can distinguish it from panel-level siblings like open_buying_power_panel because this is the home/overview entry point.

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 explicit trigger conditions ('Use it when the user asks to open RealOpen, open the RealOpen app or sidebar, or see an overview of where they stand'), which is strong positive guidance. It stops short of disambiguating against siblings such as open_buying_power_panel, which competes for the same buying-power intent and is only indirectly covered by the workflow parameter.

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