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

Annotations already declare readOnlyHint and openWorldHint, yet the description adds genuinely useful context: a ready token returns an unsigned transaction that anyone can broadcast for a fraction of a cent of gas on Robinhood Chain, and Pons tokens auto-open at 0.25 ETH raised. It also flags that token names/symbols are creator-set untrusted text, a real safety note not encoded anywhere in the schema. It stops just short of describing the full response shape or failure modes for unsupported addresses.

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 verb and the primary purpose are front-loaded, and each following sentence carries distinct payload (returned transaction, gas cost, Pons auto-open rule, untrusted-text warning). Slightly dense with four clauses in one opening sentence, 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?

For a single-parameter read tool with no output schema, the description covers what is checked, what the ready state returns, the cost of acting on it, and one automation rule plus a trust caveat. An agent has enough to call it correctly and interpret the result without further documentation.

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% with a documented pattern for the single address parameter, so the baseline is 3. The description adds only that the address is a launchpad token contract, not the wider range of addresses the tool might otherwise accept — a marginal clarification rather than new semantics.

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 states a specific verb ('Checks') and a specific resource ('any launchpad token address'), then enumerates the exact statuses it resolves: supported by OpenHooks, opened on Uniswap v4, graduated, or ready to open. It does not, however, distinguish itself from the similarly scoped sibling get_token, leaving the agent to infer the difference.

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?

'Checks any launchpad token address' implies the usage context of inspecting status, and it notes when the unsigned open transaction is included. But it never says when to prefer this over get_token or list_tokens, and there are no explicit exclusions or prerequisites beyond the token being on a launchpad.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful detail beyond that: it returns both the token balance and the pair-token (ETH) balance, in base units and decimals, which clarifies the output shape for an agent without an output schema.

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?

A single, front-loaded sentence with zero wasted words. It packs the resource, both returned balances, and the unit semantics into one compact 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?

There is no output schema, and the description compensates by naming the return values and their units (base units and decimals). For a simple two-parameter read tool whose annotations carry the safety profile, this is nearly complete; only explicit usage routing 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%, with both 'token' and 'wallet' fully documented in the input schema. The description restates their roles (a wallet's balance of a token) but adds no syntax, format, or constraint details beyond what the schema already provides, so 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?

The description clearly states a specific verb-resource: retrieving a wallet's balance for an opened token and its pair token (ETH), including units. It implicitly distinguishes itself from sibling token-inspection tools like get_token or check_token, but never explicitly names or contrasts with an alternative.

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: 'opened token' hints at a prerequisite (the token must be opened), but there is no explicit when-to-use, when-not-to-use, or mention of alternatives such as get_token or get_stats. An agent must infer the context from the sibling names.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds the content scope (fee wallet ETH awaiting buybacks, burn amount), but does not disclose freshness, caching, or any caveats about the sourced on-chain data.

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?

A single well-organized sentence with the resource front-loaded and the metric list cleanly parenthesized. No wasted text, though the one sentence carries a lot of enumeration.

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 must convey what is returned, and it does list the metrics (totals plus the $OPENHOOKS fee/buyback/burn figures). It stops short of describing the response structure or units, but is adequate for a zero-parameter stats tool.

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?

Zero parameters, so there is no parameter meaning to convey; baseline 4 applies. Nothing is required of the caller beyond invocation.

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 ('Totals across OpenHooks') and enumerates the exact metrics returned (tokens opened, on curve, graduated, swaps, volume, fee, buybacks, burned). This clearly separates it from the per-token siblings like get_token and list_tokens, though it never explicitly names that distinction.

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 by the enumerated aggregate metrics, but there is no explicit 'use this when you want protocol-wide totals vs. get_token for individual tokens' guidance, and no exclusions or prerequisites are stated.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description's genuinely additive contribution is the warning that token names/symbols are creator-set untrusted text, plus the note that swap data comes via OpenHooks. It does not say what happens for an unknown address or how many recent swaps are returned.

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 return contents, then a security note that earns its place. Slightly dense in one sentence, 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?

With no output schema, the description does list the main returned fields, which is the key gap-filler. But it omits failure behavior for an invalid/non-existent token and the extent of "recent swaps," leaving meaningful ambiguity for a read tool returning a composite object.

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 parameter already documents the contract-address format with a regex pattern. The description adds nothing about the parameter, 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 enumerates exactly what one token record contains (Uniswap v4 pool, bonding curve, progress, amount raised, recent swaps), which clearly separates it from the plural list_tokens sibling. It doesn't explicitly name that sibling or use a verb like "fetch," but the resource and payload 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?

There is no guidance on when to call this versus check_token, get_balances, or quote_swap, all of which sound related to a single token. The agent must infer that this is the detail-view tool from the name alone.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety baseline is covered. The description adds genuinely non-obvious context: status semantics (curve vs graduated into the launchpad's own Uniswap pool) and an explicit warning that token names/symbols are creator-set untrusted text, which is important prompt-injection guidance not present in structured fields.

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 sentences, front-loaded with the resource definition followed by capability and safety note. Every clause carries information; 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?

No output schema exists, so the description must imply the return shape; it says 'tokens opened' with filters, and the limit param bounds result size. It does not describe the fields returned per token, a minor gap for a read-only listing tool of this complexity.

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 75% with enums documented, so the baseline is already decent. The description adds meaning beyond the schema: it defines what 'curve' and 'graduated' actually mean, and confirms search spans name, symbol, or contract address, which the schema only partially captures.

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 concrete resource and scope: tokens opened on Uniswap v4 through OpenHooks, with filtering/sorting capability. It does not explicitly contrast with siblings like get_token or check_token, so an agent must infer that this is the list/browse tool rather than the single-token tool.

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 clear usage context by enumerating the ways to narrow results (status filter, search by name/symbol/address, sort) which maps directly to browse-and-filter tasks. It stops short of explicit when-not guidance or naming get_token for single-token lookup.

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?

Substantially exceeds the annotations: it discloses exact return contents (amount out after fees, minimum with slippage, unsigned transactions in send order), that approvals are one-time and sized to exactly the amount sold, that a 0.3% OpenHooks fee in ETH is already baked into the quote, and that nothing is broadcast. Crucially, 'Nothing is sent: the user's wallet must sign each transaction' is consistent with readOnlyHint=true, resolving the apparent tension of a write-shaped tool.

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 core action and routing logic, then returns, then the wallet caveat, then fee and signing disclaimers. Every clause carries information an agent needs — no filler and no repetition of the schema.

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 fully by enumerating the return payload and the required transaction ordering. For a 5-parameter, multi-transaction, open-world quote tool, nothing needed to call or interpret the result correctly 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 description coverage is 100%, so baseline is 3; the description adds genuine meaning on top by explaining why the optional wallet parameter matters ('to get approvals and balances checked for it') and by noting the returned 'minimum with slippage' relates to slippage_bps. It does not spell out units or rounding for amount beyond what the schema already states.

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 (quotes) and resource (buying/selling an opened token via Uniswap's Universal Router), and even distinguishes the two execution venues (bonding curve vs. launchpad's own v4 pool after graduation). No sibling tool does quoting/swapping, so an agent can route correctly from the name plus this description alone.

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?

Clearly frames the usage context — quote a swap for a token, and pass the wallet address so approvals and balances are checked for it. It does not give explicit exclusions or point to a pre-trade alternative (e.g. check_token or get_balances) for validating the token, so it stops just short of full when/when-not guidance.

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