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

With no annotations present, the description carries the burden well: it discloses the human-in-the-loop safety model ('Nothing is sent until the user confirms in their wallet'), the non-custodial handoff (local link, wallet-signed), and a hard refusal condition ('Refuses tokens flagged as honeypots'). It stops short of link expiry, fee/spend source, or 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?

Three compact sentences, front-loaded with the action and its output, then the safety guarantee, then the refusal edge case. Nothing is repeated from the schema or 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?

With only 3 fully-described parameters and no output schema, the description usefully compensates by explaining the return value (a local link) and who acts next (the user in MetaMask). Gaps remain around link lifetime, what happens if the user rejects or the quote goes stale, and whether any auth/wallet is needed 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?

Schema coverage is 100%, so token, amount_eth (with its 10 ETH cap) and slippage_percent (auto-raised to cover buy tax) are already fully documented in the schema. The description adds no parameter-level detail beyond restating that this is an ETH → token direction, 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 ('Prepares an ETH → token swap on Robinhood Chain') plus the concrete artifact returned ('a local link where the user connects MetaMask, reviews a fresh quote and signs'). This is clearly distinct from the quoting sibling (robinhood_swap_quote) and the polling sibling (robinhood_swap_status), since it produces a signable handoff rather than a quote or a status.

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 rather than stated: the mention of 'a fresh quote' and of refusing honeypot tokens hints that a quote/safety check is a precursor, but the description never names robinhood_swap_quote or robinhood_token_safety as the alternative, nor does it state prerequisites or when NOT to call this.

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?

The description adds real context beyond readOnlyHint=true: it discloses that the response contains expected amount, USD values, gas, a TypeAI fee, slippage, and safety warnings — a non-obvious behavioral trait. It stops short of noting quote volatility/expiry or whether warnings can block the trade.

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 clauses, front-loaded with what it returns and closed with the key non-mutation fact. No filler and nothing that could be cut without losing 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?

With no output schema, the description usefully enumerates return fields, which is the main completeness gap it could close. It leaves minor gaps: the accepted token identifier format and whether a quote expires before prepare_swap consumes it.

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 all three parameters documented, including the slippage default and automatic buy-tax adjustment. The description adds no parameter-level detail 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?

States a specific verb+resource ('Live quote for swapping ETH into a Robinhood Chain token') and enumerates the returned fields. It doesn't name robinhood_prepare_swap explicitly, so the differentiation from that sibling is left implicit, but the direction (ETH→token) and read-only nature are 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?

'Doesn't create anything' implies the read-only pricing step and hints that a separate tool performs the actual swap, but the description never names robinhood_prepare_swap or states when the quote should be refreshed. Usage is inferable rather than explicit.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It usefully discloses the state set (awaiting_wallet, awaiting_signature, submitted, confirmed, failed) and that a transaction link appears once sent, but says nothing about what those states mean for the caller's next action or whether any state is terminal.

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?

One sentence, front-loaded with the action and followed by the enumeration of outcomes and the transaction link. Every clause carries information the agent cannot get from the annotations.

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 return-value burden and does so by listing the possible states and the transaction link. It remains slightly incomplete in that it does not say which states are terminal or that the link is absent before 'submitted', but it is sufficient to call the tool correctly.

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?

With 100% schema coverage the single request_id is fully documented in the schema, including its origin in robinhood_prepare_swap. The description adds no further parameter meaning, but nothing is missing on the parameter side, so baseline 3–4 applies and the description's silence is not a defect.

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?

Identifies the resource (a prepared swap) and the exact information returned (status plus transaction link), and its reference to 'prepared swap' implicitly separates it from robinhood_prepare_swap and robinhood_swap_quote. It reads as a noun phrase rather than a verb+resource statement, keeping it just short of fully 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 phrase 'a prepared swap' plus the schema's 'request_id from robinhood_prepare_swap' imply this is called after preparation, so usage is inferable. However, there is no explicit statement of when to call it (polling cadence, whether to re-check until a terminal state) or any 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?

readOnlyHint=true already tells the agent this is a safe read, so the description isn't carrying the safety burden. It adds value by enumerating the returned data set, which is meaningful given there is no output schema. However, it says nothing about behavior on an unknown/invalid token, lookup cost, or whether the symbol/name lookup can be ambiguous.

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?

One sentence, front-loaded with the highest-value return fields and closed with the resource scope. Nothing is redundant or 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, the description usefully enumerates the return payload, which is the main thing an agent needs. It also pins the domain to Robinhood Chain. It could go further on behavior when a token isn't found or when a symbol resolves to multiple tokens, but overall it is sufficient to call correctly.

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 'token' parameter is well documented in the schema itself, including accepted forms (symbol, name, or 0x address) and an example. The description adds no parameter-level guidance beyond that, 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 the resource (a Robinhood Chain token) and enumerates exactly what data is retrieved: price, multi-window price change, market cap, liquidity, volume, holders, and metadata. That is a concrete, specific purpose. It does not distinguish itself from siblings like robinhood_token_safety or robinhood_trending_tokens, 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?

There is no statement of when to use this tool versus robinhood_token_safety (which presumably covers risk/safety) or robinhood_trending_tokens. The agent must infer that this is the 'general detail lookup' and the others are specialized. No exclusions or prerequisites 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the description's burden is lighter. It still adds real value by disclosing the shape of the result (0-100 score, level, red flags, good signs, plain-English verdict) — important because there is no output schema. Auth needs and rate limits are unstated.

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?

One sentence, front-loaded with the purpose, then the return contents, then the call-to-action. Dense but no filler. The parenthetical flag list is long yet each item clarifies the tool's detection scope.

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 appropriately spends its words on expected return contents, which is the main gap it must cover. Missing are failure modes (unknown token, ambiguous symbol) and whether the score is cached or real-time — minor for a read-only lookup.

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 single parameter has 100% schema coverage, including accepted forms (symbol, name, or 0x address) and an example, so the schema does the heavy lifting. The description adds nothing about the parameter beyond what the schema documents; the parenthetical example 'TORCH' belongs only in 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 and resource ('rug-pull check for a Robinhood Chain token') and enumerates exactly what the result contains: risk score, flags, good signs, verdict. This clearly separates it from siblings like robinhood_token_info, which reads as informational rather than risk-evaluating.

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 timing guidance ('Run this before any swap'), which effectively routes the agent away from robinhood_swap_quote/prepare_swap until this has run. It doesn't name an alternative or state when the check can be skipped, so it stops short of full when/when-not coverage.

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?

readOnlyHint=true already declares the safe read profile, so the bar is lower. The description still adds value by declaring that results are live, scoped to 24h, and carry specific fields (price, 24h change, market cap, volume, explorer link), which tells the agent what data to expect. Pagination, rate limits, and result-size limits are not addressed.

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?

One sentence, front-loaded with the resource, then the variants, then the returned fields. No redundant or filler text.

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 naming the returned fields in the description is the right compensating move, and the chain/24h scope is stated. For a single-optional-parameter read tool, nothing material 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?

Schema coverage is 100% and the single 'list' parameter already has an enum and description, so the schema carries the parameter burden. The description does add that gainers/losers are measured over 24h, but offers no further semantics beyond that.

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 resource (trending tokens) plus the three concrete list variants and the 24h window on Robinhood Chain, so it is clearly distinct from single-token siblings like robinhood_token_info and robinhood_token_safety.

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 this is the discovery screen for token lists, but it never says when to prefer it over robinhood_token_info or robinhood_token_safety, nor any exclusions or prerequisites. Selection guidance is left to the enum in the schema.

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?

readOnlyHint=true already declares the safety profile, and the description usefully clarifies that ETH is always returned while the token balance is additive when a token arg is supplied. It omits error behavior (invalid address, unknown token symbol) and chain caveats, which matter for a live-balance read.

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?

One sentence, no waste, with the primary result (ETH balance) front-loaded and the conditional token part trailing. Exactly the shape an agent 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?

There is no output schema, so the description carries the burden of saying what comes back beyond 'balance' — no indication of units, formatting, decimals, or how an unknown token is reported. For a simple 2-param read it is close, but the return shape is left uncovered.

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, including token accepting symbol/name/0x address. The description only reinforces that token is optional, adding little beyond the schema 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?

States a specific resource (ETH balance of a wallet) constrained to Robinhood Chain, plus an optional token balance, so the agent knows exactly what is retrieved. It does not explicitly name a sibling it is not, but the resource scope makes it distinguishable from token_info/trending_tokens/swap 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?

Usage is only implied by the phrasing: call it when you need a wallet's ETH balance, optionally a token balance. No explicit when-not conditions or pointer to alternatives (e.g. robinhood_token_info for token metadata) are given.

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