Highwire

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the description's job is to add context beyond that — and it does: it discloses that the New school creator's third of locked-LP fees is settled off-chain by higher.fun and only *reported*, not claimed, and that a sign_url is returned only when there is something to claim. That conditional-return behavior is genuinely useful and non-obvious.

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 clauses that each carry information: the two claim sources, the off-chain caveat, and the return contract. It is front-loaded with the action and avoids repetition, though the dense domain jargon ('New school coins') adds some parsing cost.

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 burden and does so concisely: sign_url when there is something to claim, plus the reported-but-not-claimed portion. For a one-parameter, single-transaction builder, that covers what an agent needs before invoking 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 coverage is 100% for the single wallet parameter, and its pattern/signing role is documented in the schema itself. The description adds no additional meaning about the wallet argument, 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?

The description uses a specific verb+resource pair ('show what a creator can claim and build the unsigned claim transactions') and then enumerates the two fee sources it covers: curve creator fees (one vault across all coins) and post-graduation Raydium CPMM pool creator fees. This is specific enough that an agent can distinguish it from read-only siblings like get_coin_fees or get_creator_coins.

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 purpose ('claim' fees) but the description never states when to pick this over get_coin_fees, get_creator_coins, or get_wallet_positions, nor any prerequisites or exclusions. An agent must infer the routing from the tool 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?

Goes well beyond the annotations by disclosing that the launch fee is verified against higher.fun's on-chain fee wallet and cap, that the metadata upload needs a wallet sign-in Highwire cannot perform (with a documented fallback), that the idempotency key pins the mint across server instances, and that the response contains transactions plus a sign_url. The key-based dedupe is consistent with idempotentHint=false, since it only holds for identical keys, not for arbitrary repeat calls. Minor gap: nothing about failure/partial states or expiration of the returned unsigned transactions.

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?

Dense but front-loaded: the core action comes first, then prerequisites, then retry safety, then the confirmation gate, then the return value. A couple of sentences are run-ons carrying two ideas at once, but no sentence is 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 15-parameter mutation tool with no output schema, the description covers the critical unknowns: the fee cap check, the metadata prerequisite and fallback, idempotency, the confirmation gate, and a one-line statement of what is returned. What is missing is failure behavior (e.g. what happens if metadata_uri is present but invalid, or if the fee cap is exceeded).

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 already 87%, so baseline is 3; the description adds real meaning on top by mapping the enum values to product language ('classic = Old school, rewards = New school'), explaining the metadata_uri dependency and its fallback, and stating the approval semantics behind confirm_launch and the mint-pinning role of idempotency_key. It does not add anything for dev_buy_sol, creator_lock_pct, or max_slippage_bps beyond what the schema already says.

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?

Opens with a specific verb and resource: 'Build the unsigned transactions that launch a coin on higher.fun from the user's wallet,' and immediately enumerates the sub-actions (create on fee mode, pay launch fee, optional first buy, optional creator lock). This clearly separates it from build_trade and build_claim_creator_fees, which are the other 'build unsigned tx' 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?

Gives concrete gating conditions: set confirm_launch only after the user approved the launch, its cost and its fee mode; supply metadata_uri or the tool falls back to returning metadata JSON to host; reuse idempotency_key on retries. It stops short of naming alternatives explicitly (e.g. quote_trade or check_ticker as prerequisites), so it is clear context rather than full when/when-not routing.

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 only say this is a non-read-only, non-idempotent, open-world call; the description goes far beyond by disclosing the pipeline (checked instruction by instruction, simulated), the return shape (base64 tx, plain-language summary, sign_url), and the custody model ('Highwire never signs and never needs a private key'). That last point is exactly the reassurance an agent needs before asking a user to sign. No conflict with destructiveHint=false, since signing happens in the user's own wallet.

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?

Four tight sentences with the highest-value information (what it builds, quote-first requirement, what comes back) front-loaded. Slightly dense and the custody sentence, while useful, is the most compressible clause.

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 correctly describes the return payload and the safety model for an 8-parameter mutation-adjacent tool. It stops short of covering failure behavior (what happens if the simulation or instruction check fails) or how long a built transaction remains valid, which would matter for retries.

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 the baseline is 3; the description earns a bump by clarifying that confirm_trade must follow approval of the specific coin/side/amount/slippage tuple, which is a stricter reading than the schema's 'exact trade.' The buy/sell conditional use of sol vs tokens is left entirely to 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 ('Build an unsigned buy or sell') plus scope ('for the user's own wallet to sign') and an equivalence anchor ('the same transaction higher.fun's site builds'). It also implicitly distinguishes itself from the sibling quote_trade, which is named for the opposite step.

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 sequencing and an alternative: 'Quote first with quote_trade and show the user the quote,' then gates invocation on user approval of 'this exact trade (coin, side, amount, slippage).' A when-not condition is implied by the confirm_trade gate, leaving nothing critical to inference.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered and the bar for the description is low. The description adds essentially nothing beyond that: no note on case sensitivity, whether reserved/inactive tickers count as taken, rate limits, or what the answer looks like. It reads as a restatement of the title rather than added behavioral context.

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 short, front-loaded sentence fragment with zero padding. Its terseness is not wasteful, though the fragment form ('Whether a ticker is still free...') leaves the actor and returned value grammatically unstated.

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 is the only place an agent could learn what a positive or negative result means (free vs. taken vs. previously used), and it does not say. For a simple boolean-check tool this is the main remaining gap, and it is left open given the messy semantics of a 'free' ticker.

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 schema itself documents the single 'ticker' parameter, including the 'Ticker without the $' note and a regex pattern. The description adds no further meaning such as length limits or case handling, 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?

The description names a specific resource (a ticker) and a specific question (is it still free to launch with on higher.fun), which is enough to tell it apart from siblings like get_coin, search_coins, or build_launch. It stops short of stating the outcome form (a boolean availability answer), so it is clear but not maximally precise.

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: an agent can infer this is a pre-flight check before build_launch or build_claim_creator_fees, but the description never says so, nor does it mention when the check is unnecessary or what the alternative is if a ticker is taken.

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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new context the annotations lack: messages are untrusted user content and are flagged for links and impersonation, which matters for how an agent should treat the output. It doesn't say what happens when the cursor is stale or how many messages come back.

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, no filler, with the resource and ordering front-loaded before the trust caveat. Every clause carries 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?

For a single-optional-parameter read tool with no output schema, the description covers scope, ordering, and content trust. It could say more about what a message record contains (author, timestamp, flags) but nothing essential to invoking it 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 coverage is 100% and the single optional 'before' cursor is fully documented in the schema. The description adds 'newest first', which clarifies the paging direction, but nothing about cursor semantics or page size beyond what the schema already provides.

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 (higher.fun's site-wide chat messages) with a clear scope and ordering (newest first). It implicitly distinguishes itself from get_coin_comments by saying 'site-wide', but never names that sibling, so an agent must infer the 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?

There is no explicit when-to-use guidance and no mention of alternatives such as get_coin_comments for coin-scoped discussion. The agent is left to infer that this tool is for the global chat rather than a specific coin's chat.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine domain context by naming the specific aggregates it returns (fee mode variants, safety grade components like snipers, bundles, dev activity, creator lock), which is behavior beyond the annotations. It still omits how the grade is computed, whether any field can be null for ungraduated coins, and the cost/latency of a multi-source aggregation.

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 the scope stated first and the field inventory following as a compact list. No filler or hedging. The enumeration is long, but each item tells the agent about data availability, so it largely earns its length.

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 must carry the return-value burden, and it makes a reasonable attempt by listing the payload contents. It falls short on structure — the agent cannot tell whether the response is flat, nested, what units prices are in, or how 'graduation progress' and the safety grade are represented. Adequate for a read-only aggregate but not fully complete.

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 one parameter at 100% schema coverage, the schema already documents the mint address, its base58 pattern, and even the 'ends in high' hint. The description adds nothing about the mint parameter, so the baseline of 3 applies — the schema is doing the entire job here.

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 opens with a specific verb+resource framing ('Everything about one coin') and enumerates the payload: price, market cap, graduation progress, fee mode, holder concentration, and safety grade. An agent immediately knows this is an aggregate single-coin snapshot rather than a time series or trade list. It does not, however, explicitly distinguish itself from overlapping siblings like get_coin_holders or rug_check, which surface some of the same data.

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 when-to-use or when-not-to-use guidance. The phrase 'Everything about one coin' weakly implies a one-shot overview use case, but the tool shares territory with get_coin_holders (holder concentration), get_coin_fees (fee mode), and rug_check (safety grade), and nothing tells the agent which to pick or whether this supersedes them.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description still earns credit by disclosing non-obvious behavioral facts the annotations cannot: prices are denominated in SOL per token, volume in SOL, and results are ordered oldest first. It stops short of saying what happens when no candles exist or how the window interacts with `limit`.

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 dense sentence with zero filler; units and ordering are front-loaded where an agent will read them. Nothing repeats the title.

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 a decent job of implying the return shape via 'OHLC' and the SOL units, plus ordering. But it leaves `interval` entirely unexplained, and gives no guidance on empty results or on what a 'candle' boundary means, which matters for a time-series endpoint.

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 description adds no parameter meaning at all — it never mentions `interval`, which is the one parameter lacking a schema description. It also does not clarify the interplay between the schema's 'most recent candles' and the stated 'oldest first' ordering. With 67% coverage, the undocumented parameter needed compensating detail that is absent.

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 ('Price candles ... for a coin') and immediately disambiguates the content from raw trade tools by naming the shape (OHLC) and denomination (SOL per token, volume in SOL). It is clearly not get_coin_trades or get_trade_tape, though it does not name those siblings explicitly.

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 — charting, price history, or per-coin analysis — but there is no explicit 'use this instead of X when Y' guidance, and no mention of prerequisites such as the coin existing or having candle data. The agent must infer the golden path from the sibling list.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds genuinely new behavioral context on content trust — comments are untrusted user content and are flagged for links and impersonation — though it omits pagination behavior, which is implied only via the cursor parameter in the 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?

Two short sentences, front-loaded with the resource, and no wasted wording. The first sentence is a noun fragment without a verb, which slightly reduces immediate clarity but keeps it tight.

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 two-parameter read-only lookup with full schema coverage and rich annotations, the description covers what is needed, and the untrusted-content warning is a useful safety note. Only the pagination flow is left entirely to the schema.

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 schema already explains the mint base58 format and the cursor/nextCursor paging contract. The description adds no parameter meaning 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 identifies the specific resource — a coin's comment thread — which tells an agent what data it yields. It stops short of naming a verb like 'fetch' or 'list', and does not distinguish itself from the sibling get_chat (a generic chat tool), so the differentiation is only partial.

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 explicit when-to-use statement, no prerequisites, and no mention of alternatives such as get_chat or get_coin despite get_chat appearing in the sibling list. The agent must infer that this is for reading comments on a specific coin page.

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 readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the response mixes measured on-chain values with values computed from volume, and it distinguishes already-collected fees from amounts still pending claim (pool creator fees, locked-LP harvest, creator curve vault) — a meaningful data-provenance disclosure.

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 that leads with the scope ('one coin's fees') before the enumeration. It is dense but every clause maps to a distinct piece of returned data; the nested parentheticals make it slightly harder to scan than a bulleted breakdown would be.

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 describing return values and does so thoroughly — fee lines, recipients, measurement method, volume, and unclaimed balances. The only real gap is the absence of any guidance on how this relates to the platform-level fee sibling.

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 mint parameter is fully documented in the schema, including the base58 pattern and the 'high' suffix convention. The description adds no syntax or format detail beyond the schema, 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?

The description names a specific resource (one higher.fun coin's fees) and enumerates exactly what is included: curve and Raydium pool fee lines, recipient attribution, on-chain vs computed origin, volume, and unclaimed amounts. It is clearly distinct from a platform-wide fee tool, though it never names the sibling (get_ecosystem_fees) that an agent might confuse it with.

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 scoping phrase 'One higher.fun coin's fees' — the agent must infer this is the per-coin drill-down versus the ecosystem-level view. There is no explicit when-to-use, when-not-to-use, or named alternative, and no mention that a mint address is required input.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: infrastructure addresses (bonding curve, Raydium pool, LP lock) are labelled in the result so they aren't misread as whales — a real interpretation caveat an agent would otherwise get wrong.

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, return contents front-loaded, then the labelling caveat. No filler and nothing restated from the title or 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?

With no output schema, the description carries the burden of explaining returns and does so only partially: it says holders and supply share plus labelled infra addresses, but not ordering, how many holders are returned, truncation, or whether the list is paginated. Adequate but leaves real gaps for a data-returning 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?

There is a single required parameter with 100% schema description coverage, including a base58 pattern and the higher.fun 'high' suffix hint, so the schema does all the work. The description adds nothing about the mint address beyond what the schema already says.

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?

"Top holders of a coin with their share of supply" states a specific resource and the metric returned, which clearly separates it from siblings like get_coin (metadata) and get_coin_trades (activity). It stops short of naming those siblings explicitly, but the resource is 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?

Usage is only implied: an agent can infer this is the tool for inspecting holder concentration, but the description never says when to prefer it over rug_check or get_coin, nor any prerequisites. The second sentence is about interpreting results, not about tool selection.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds ordering and units, which is useful, but 'recent' is never quantified (no window or page size) and pagination behavior is left entirely to the schema's cursor field.

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 no filler; the scope, ordering and units all come first. It is efficient rather than padded, though it is thin enough that a clause about result size or pagination would have been worth the words.

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 some burden for return shape and does state units and ordering, which is genuinely helpful. However, the undefined 'recent' bound and the absence of any pagination note for a cursor-based, open-world endpoint leave an agent guessing how much data it will get.

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 both parameters are documented there, including the base58 mint format and the nextCursor convention, so the baseline is 3. The description adds no parameter-level meaning beyond what the schema already provides.

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: recent buys and sells for a coin, with ordering (newest first) and units (SOL and whole tokens). An agent can distinguish it from get_coin (metadata) or get_coin_candles, though it never names get_trade_tape, the closest sibling for trade data.

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 resource name and the 'coin' scoping; there is no explicit when-to-use, no prerequisite, and no statement of when to prefer get_trade_tape or get_coin_candles instead. Adequate but leaves the choice between trade-oriented siblings to inference.

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, idempotentHint, non-destructive and open-world, so the safety profile is fully covered. The description adds the pagination behavior ('page through'), which is useful, but says nothing about result ordering, page size, or whether all launches or only successful ones are returned — details an agent would want when iterating.

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 sentence with no filler, and the key information (enumeration scope, pagination, platform) is front-loaded. Nothing is repeated from the title or 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?

For a two-parameter read tool with full schema coverage and complete annotations, this is adequate but thin: with no output schema, the description could have told the agent what a 'coin' entry contains or how pages terminate. Ordering and empty-result behavior are left unstated.

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 the schema already documents both wallet and cursor, giving a baseline of 3. The description does add one piece of meaning — the wallet is interpreted as a creator address rather than an arbitrary holder — but cursor mechanics and any ordering guarantees remain unexplained beyond 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?

The description gives a specific verb-plus-resource combination ('page through every coin a wallet has launched') and names the platform (higher.fun), which is enough to distinguish it from get_coin (single coin), list_coins (all coins), and get_wallet_positions (holdings). It stops short of explicitly contrasting with those siblings, so it lands at 4 rather than 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?

Usage is only implied: an agent can infer this is the tool for enumerating a creator's launches, and 'page through' signals pagination. There is no statement of when to prefer it over list_coins or get_wallet_positions, and no note on prerequisites or edge cases (e.g. wallets that have launched nothing).

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 cover read-only, idempotent, non-destructive and open-world, so the bar is lower; the description still adds real value by disclosing data provenance – curve fees measured on-chain versus pool fees computed from volume – which tells the agent the two figures have different reliability characteristics. It does not mention freshness/caching or latency, which is the only notable gap.

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 that opens with the core purpose and then enumerates the payload, followed by one short line on methodology. Dense but every clause carries information; nothing is redundant with the title or 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 burden of describing return content and does so thoroughly by listing every section an agent will get. Missing only minor operational detail such as response shape or whether claimable amounts are wallet-specific versus global.

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 the schema already documents both 'top' (count, highest first) and 'sort' (ranking key). The description only alludes to ranking via 'the top coins' and adds no meaning about sort modes or how the top-N list interacts with the totals; 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 ('Every fee higher.fun's coins have paid and who got it') and enumerates the breakdowns returned (creators, higher.fun, Raydium, pools, phase, fee mode, claimable, rates, top coins). It is clearly an ecosystem-wide aggregate, which implicitly separates it from the per-coin sibling get_coin_fees, but it never names that sibling explicitly.

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 prescribed: 'The same numbers as highwire.fun/fees' tells an agent which view this mirrors, and the scope framing implies it is the aggregate counterpart to get_coin_fees. There is no explicit when-to-use/when-not-to-use guidance or reference to a named alternative.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile needs no restating. The description's contribution is the temporal qualifier 'right now', signalling a volatile snapshot, but it says nothing about what happens if no coin is featured or what the returned value looks like.

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 short sentence with no filler, and the distinguishing qualifier ('highest', 'home page', 'right now') is front-loaded. Nothing could be removed 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?

For a trivial no-argument read with full annotation coverage, the definition is nearly sufficient, but with no output schema it does not say what is returned (a coin identifier, a full coin object, or nothing when unset). That single missing detail is the main remaining gap.

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 tool takes zero parameters, so there is no parameter semantics for the description to elaborate; the baseline for a 0-param tool applies. Nothing in the description misleads about inputs.

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 identifies a concrete resource: the single coin that higher.fun currently highlights as 'highest' on its home page, which is distinct from a general coin lookup. It is a noun phrase rather than a verb+resource statement and never contrasts itself with close siblings like get_top_coins or get_coin, so an agent must infer that this returns one featured item rather than a ranked list.

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 explicit when-to-use guidance, no mention of alternatives such as get_top_coins or list_coins, and no stated prerequisites. The phrase 'right now' only weakly implies this is a live/current-value call rather than a historical query.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the content scope (traders vs creators, 24h vs 7d) but does not explain how ranking is determined or what the response includes, which is a modest additional gap.

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 description is a single compact sentence fragment with no wasted words, and the core scoping information is front-loaded. Nothing irrelevant is included.

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 simple two-enum-parameter tool with no output schema, the description is adequate but not complete. It says what the leaderboard covers, but does not mention the ranking metric or any result-structure expectations, leaving a small but meaningful gap for an agent invoking 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 0%, so the description must carry parameter meaning. It does map both parameters well in natural language: 'top traders or top creators' corresponds to kind, and 'last 24 hours or 7 days' corresponds to window, covering both enum dimensions without leaving an agent guessing.

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 the exact resource (leaderboard), the two leaderboard types (top traders or top creators), and the two time windows (24h or 7d). It is clear enough to distinguish this from siblings like get_top_coins, though it is phrased as a fragment rather than a full verb-led sentence.

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?

No explicit guidance is given about when to use this tool versus alternatives, nor any exclusions. The intended use is implied by the purpose statement, but an agent receives no help deciding between this and sibling tools such as get_top_coins or get_coin_holders.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description's added value is enumerating what the payload covers (fee modes, splits, graduation, program addresses), but it does not say whether values are live/fetched or static documentation, nor what format the response takes.

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 a dense but useful enumeration; each clause names a concrete content area rather than filler. Slightly list-like and lacking a lead statement of 'returns documentation', but nothing is 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?

For a zero-parameter, no-output-schema informational tool, the description covers the substantive content areas an agent would need to know it can consult here. It stops short of stating whether the returned data is live or cached and what the response structure looks like, which leaves a modest gap.

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 tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no input is needed by presenting itself as a pure informational lookup.

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 frames this as a reference/knowledge tool: 'How higher.fun works', followed by an enumerated list of topics (launch fee, SOL price, fee modes and splits, graduation, Raydium program and platform addresses). That is enough to distinguish it from the data-oriented siblings like get_coin, get_coin_fees, or quote_trade, though it never explicitly says 'this returns documentation, not market data'.

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 when-to-use guidance at all: nothing says to call this before build_launch or build_trade to understand fee mechanics, and no alternative or exclusion is named. An agent must infer the usage context purely from the topic list.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine behavioral context by disclosing the ranking metric (trading volume) and the two time windows, but it omits how many coins are returned, how they are ordered, and whether results are paginated or truncated.

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 short sentence with no filler or redundancy, and the key qualifiers (volume, time window, platform) are front-loaded. The only structural weakness is the missing verb, which makes it read as a label rather than a definition of an action.

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 one-parameter read-only tool with no output schema and full annotation coverage, the description is close to sufficient, but it should still state that it returns a ranked list and roughly how many entries or what fields. An agent can call it correctly but cannot predict the shape or size of the response.

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 0%, so the description must carry the parameter meaning, and it does partially: 'over the last 24 hours or 7 days' maps directly onto the window enum values. However, it does not name the parameter, state the default (24h), or clarify that omitting it yields the 24h window.

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 sentence names a specific resource and ranking metric (coins with the most trading volume on higher.fun), but it is a noun fragment with no verb, so it never states that the tool retrieves or returns a list. It also fails to distinguish itself from siblings like list_coins, get_leaderboard, or get_trade_tape, which an agent could easily confuse with this.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative is named. The only hint is the 24h/7d window, which implies a trending/volume-ranking use case, but the agent must infer that against list_coins and get_leaderboard on its own.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that the feed is 'live' and spans the whole platform, which is genuine context, but it says nothing about how many entries are returned, whether it is a snapshot or incremental stream, or how often to poll.

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 no filler. Scope ('across all of higher.fun') comes before the enumeration of event types, so the agent gets the most important framing first.

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 and no parameters, the description carries the burden of explaining the return value, and it only partly does so by naming the four event types. It omits anything about result size, ordering, or refresh cadence, which are the details an agent needs to use a live feed 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?

The tool takes zero parameters, so there is no parameter meaning for the description to add and the schema is fully trivially covered. Baseline 4 applies for a no-argument tool.

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 and its scope concretely: a live feed 'across all of higher.fun' containing 'buys, sells, launches and graduations'. That implicitly separates it from per-coin siblings like get_coin_trades, though the distinction is never stated outright.

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: an agent can infer this is for platform-wide recent activity rather than a single coin, and the word 'live' suggests real-time polling. No explicit when-to-use, when-not-to-use, or named alternative (e.g. get_coin_trades, list_coins) is 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuine context: prices come from the coin's last price, only on-chain-recognized higher.fun coins are counted so look-alikes are excluded, and the mints path is cheaper for large wallets. It stops short of saying whether all holdings are returned or how results are ordered/limited.

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 what is returned, then the recognition caveat, then the parameter shortcut — no filler. The parenthetical about the LaunchLab pool is slightly dense but earns its place by defining what counts as a higher.fun coin.

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 the return payload, and it does so (SOL balance plus per-coin balances valued at last price). The main remaining gap is whether results are paginated, capped, or sorted for wallets holding very many coins.

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 the baseline is 3, but the description adds meaning the schema does not: mints is a performance optimization for wallets with thousands of tokens, and the on-chain recognition note explains why some held tokens are absent. It does not restate the address format, correctly leaving that to 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?

The description names a concrete verb and resource ('a wallet's SOL balance and its balances in higher.fun coins') and states how values are computed (last price). It is clear what the tool returns, but it never names a sibling like get_wallet_profile or get_coin_holders, so the agent must infer the boundary from the 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?

It gives explicit conditional guidance for the optional parameter: pass mints to check only those coins, 'which is faster and works for wallets holding thousands of tokens.' That is real when-to-use advice, but there is no guidance on when to prefer this tool over the sibling wallet/coin tools.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower; the description still earns credit by disclosing what the payload contains — an aggregation of profile, created coins, earnings and locks — which is the key behavioral fact given no output schema. It stops short of stating pagination/limits on the coin list or behavior for wallets with no profile.

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 sentence, front-loaded with the resource and then the returned fields, with zero filler. Everything present earns its place.

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?

Read-only aggregate with no output schema, so enumerating returned fields in the description is the right move and largely covers the gap. Missing are result-shape details an agent would want before calling — whether the created-coin list is truncated, units/format of earnings, and what happens for an unknown wallet.

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?

Only one parameter, and the schema documents it fully (base58 Solana address with a regex pattern) at 100% coverage. The description adds nothing about the wallet argument, 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 pair ("a wallet's higher.fun profile") and enumerates the constituent data: display name, created coins, creator earnings (paid out/pending) and creator locks. That makes it distinguishable from get_wallet_positions and get_creator_coins, though it never names those siblings to sharpen the boundary.

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 "in one call" implicitly signals this is the bundled/aggregate lookup versus the narrower siblings, but there is no explicit when-to-use, when-not-to-use, or prerequisite (e.g., whether the wallet must have created coins). Usage must be inferred.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context such as pagination behavior, result freshness, or result-set shape; its enum explanations are parameter semantics rather than behavioral disclosure.

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 compact sentence with the resource stated first and the sort options enumerated compactly in parentheses. It is front-loaded and free of filler, though the nested parenthetical list is slightly dense.

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 would ideally indicate what a coin entry contains or at least that results are paginated. Pagination is only inferable from the cursor field, and no return-value information is given, leaving a notable gap for a discovery 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?

Schema coverage is 33%: only cursor carries a schema description. The description compensates meaningfully for the sort enum by defining what each mode ranks on (recent distinct buyers, latest launches, market cap, distance to Raydium graduation). It says nothing about limit or its 1-50 bounds, leaving partial coverage.

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 uses a specific verb and resource ("List higher.fun coins") and immediately enumerates the sort modes, so the agent knows it is a browsing/listing tool. It does not differentiate itself from siblings like get_top_coins, search_coins, or get_featured_coin, which also surface coins.

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 explicit when-to-use or when-not-to-use guidance, and no mention of when to prefer search_coins, get_top_coins, or get_coin instead. The agent must infer from the tool name and sort options that this is for unfiltered discovery.

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 readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new behavioral detail by enumerating what a quote returns (expected output, slippage floor, price impact, fee split by recipient under the coin's fee mode). Since there is no output schema, this return-shape disclosure is the main source of that information. It does not cover failure modes such as a coin without a live pool.

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?

Information is front-loaded correctly: what is quoted, then which side maps to which input, then venues, then return contents. It is one dense sentence plus a short read-only tag, which is efficient, though the middle clause about venues is heavier than it needs to be.

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 read-only quoting tool with no output schema, the description supplies the return fields and the side-to-parameter mapping, which is most of what an agent needs. The remaining gap is that the schema marks only mint and side as required, so the conditional requirement of sol vs tokens is left to inference from the prose.

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 the baseline is 3 and every parameter is already documented inline. The description does clarify the conditional usage of 'sol' for buys and 'tokens' for sells, which the schema alone leaves to the per-field text, but it adds no format or bounds detail 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?

The description names a specific verb (quote) and resource (buy/sell of a higher.fun coin) and pins down the venues it spans: the LaunchLab bonding curve and the Raydium CPMM pool post-graduation. It never names the obvious sibling build_trade, so the quote-vs-build distinction is only implied by 'Reads only' rather than stated.

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 prescribed: the price-impact/minimum-out language signals this is a pre-trade preview and 'Reads only' signals it does not submit anything. There is no explicit 'use this before build_trade', no exclusion for when get_coin_trades or build_trade is the better call, and no stated prerequisites.

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 this a read-only, idempotent, non-destructive open-world call, so the safety bar is met. The description adds genuine behavioral value by disclosing the verdict taxonomy the agent must interpret and the exact factors that roll into it, which no structured field conveys. It stops short of describing response shape or whether per-signal detail accompanies the verdict.

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?

It is a single sentence with a front-loaded purpose clause, waste-free despite the dense signal list. Readability would improve slightly if the verdict options were split out from the colon-delimited enumeration, but no sentence is 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 carries the burden of explaining returns and does so by naming the three verdict values. What remains unstated is whether the underlying signals are returned alongside the verdict or only the grade, which matters for how an agent should report results to a user.

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?

There is a single parameter at 100% schema description coverage, and the schema already explains the base58 mint address and the 'high' suffix convention for higher.fun mints. The description adds no additional parameter meaning, 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 a specific analysis action on a specific resource (a coin's mint) and enumerates the concrete signals inspected: mint/freeze authority, holder concentration, snipers, bundled wallets, dev selling, ticker flags. It also states the output taxonomy (CLEAN_ON_CHECKS / CAUTION / HIGH_RISK), which clearly separates it from data-retrieval siblings like get_coin or get_coin_holders.

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?

"Safety check before anyone trades a coin" establishes a clear usage context tied to the trade flow (build_trade, quote_trade). However, it never names an alternative or states when not to use it — e.g. that it is not a substitute for get_coin metadata or check_ticker — so guidance is contextual 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond them: it does not say how many results come back, whether matching is fuzzy or exact, whether results are ranked, or what happens with an unknown ticker.

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 short sentence, front-loaded with the verb and resource, with zero filler. Nothing can be trimmed 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?

For a one-parameter read-only search the definition is serviceable, and annotations cover safety. However, with no output schema the description should say that it returns a collection of matching coins (and roughly how matching behaves), which it omits.

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 description coverage and a single required query parameter documented as 'Name, ticker or mint', the schema carries the semantics. The description only restates those same three key types, adding no format hints such as whether a partial name or a case-insensitive ticker works.

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 a specific verb (find) and resource (higher.fun coins) and enumerates the three lookup keys (name, ticker, mint address). It is clear on its own, but it never distinguishes itself from close siblings like list_coins, get_coin or check_ticker, so an agent must infer which of these applies.

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: search when you have a partial identifier rather than an exact coin id (which would point to get_coin). There is no explicit when-to-use, when-not-to-use, or named alternative, and nothing says what to do when multiple or zero matches occur.

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