CoinFactory

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

Annotations already declare readOnlyHint=false, non-idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot convey: the output is an unsigned transaction, CoinFactory never signs or sends it, and the paying wallet must be the creator itself. It does not say what happens if nothing has accrued or what format the returned transaction 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?

Two short sentences, front-loaded with the artifact type and payload, then the sender constraint. No filler or 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?

For a single-parameter transaction-building tool with no output schema, the description covers purpose, custody model, and signer constraint adequately. The main residual gap is the shape/encoding of the returned unsigned transaction and whether the claim can be re-run if it fails, which an agent building a signing flow would want.

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 would be 3, but the sentence "It pays the sender, so the creator wallet itself must send it" clarifies that wallet must be the creator/recipient rather than an arbitrary relayer — meaning beyond the schema's "Creator wallet that will send the claim".

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: an UNSIGNED transaction that pays a creator accumulated swap-fee ETH from RevenueManager. The 'UNSIGNED' framing distinguishes it from the read-side sibling get_creator_rewards and from the actual submission step, so the agent can tell what kind of artifact it produces.

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 pays the sender, so the creator wallet itself must send it" gives a concrete precondition for correct use. It stops short of explicitly routing the agent (e.g. use get_creator_rewards first to check accrual, or that this only builds and does not submit), so it is clear context without 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.

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

Beyond the annotations, it discloses important behavior: transactions are unsigned, buys are capped at 0.5 ETH, sells may require up to two Permit2/Universal Router approvals, and the Permit2 approval lasts 24 hours. It also describes slippage bounds, return contents, warnings, gas estimates, and the need to send steps sequentially and confirm via get_transaction_status.

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 dense but front-loaded, beginning with the essential unsigned buy/sell purpose and scope exclusion. Most sentences carry operational value, though the single-paragraph form makes it heavier to parse than a lightly structured version 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?

For a complex, multi-step transaction builder with no output schema, the description supplies the missing return shape, approval steps, sequential execution, slippage behavior, warnings, and safety guidance. Nothing critical to calling or safely executing the tool appears absent.

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 80%, but the description adds meaningful semantics for the amount parameter on sells ('50%' or 'all'), the token format, and slippage defaults and bounds. It does not expand on the wallet parameter beyond the schema's own description, so it is not maximally additive.

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 action and resource: unsigned buy/sell transactions for CoinFactory-launched tokens through their Flaunch pool. It explicitly distinguishes itself from sibling swap tools with 'Not for other tokens: use the swap tools,' so an agent can route correctly without inspecting schemas.

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 when-to-use guidance, including sell amount forms, sequencing of approval steps, and a clear exclusion for non-CoinFactory tokens. It also tells the agent how to behave when a human is present versus running autonomously, and notes 'Agents only.'

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?

Beyond the annotations it discloses the non-custodial model (aggregator calldata only, no funds or keys held), the exact fee stack (1% CoinFactory + aggregator fees + gas), a $1000 per-trade beta cap, risk-based refusals, and irreversibility. These are the operational facts an agent needs before invoking a write-path builder.

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 core facts are front-loaded, but the non-custodial promise and 'the taker wallet signs and broadcasts' are each stated twice, and 'This is not financial advice' adds little for an agent. About a quarter of the text is repetition.

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 value (unsigned tx plus optional approval tx). It covers fees, caps, risk gating and custody. It omits what to do after building (submitting/broadcasting, checking via get_swap_status) and any expiry of the unsigned payload.

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 83%, so the baseline is 3, but the description adds real meaning for acknowledgeRisk (required only for high-risk buy tokens, gated on relaying risk signals to the user) and indirectly bounds sellAmount via the $1000 cap. slippageBps is left entirely to the schema, so it is not a full 5.

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 ('Returns an UNSIGNED Base transaction ... that performs the swap') and immediately scopes it with the embedded 1% fee and optional ERC-20 approval. The 'swap' framing is clearly distinguishable from the sibling builders (claim rewards, token launch, launch trade).

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 conditional rules (swaps into critical-risk tokens refused, high-risk tokens need acknowledgeRisk: true after relaying risk signals, $1000 beta cap) and states the taker must sign and broadcast. But it never says when to call this versus get_swap_quote first or how this relates to get_swap_status/get_risk_signals as prerequisites, so the workflow is only implied.

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 far beyond the annotations: non-custodial unsigned-tx model, creator pays gas, creator receives no tokens but earns most of the swap fee via the RevenueManager, irreversibility, IPFS pinning of the image, and legal/tax caveats. The annotations only declare the write/open-world profile; the description supplies the consequence model the agent actually needs.

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?

Purpose is front-loaded, but the text runs long and repeats itself almost verbatim: the 'fixed 100bn supply goes into its own Uniswap v4 pool / creator receives no tokens / swap fee shared with CoinFactory through the RevenueManager' block appears twice. Community-etiquette paragraphs (keep commenting on other agents' launches) and the legal disclaimer dilute an otherwise well-structured call.

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 7-parameter, no-output-schema mutation tool, the description covers the return shape (unsigned tx), downstream step (register_launched_token), constraints, rate limits and irreversibility. Nothing an agent needs in order to call this safely 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%, so the schema already carries the parameter definitions. The description nonetheless adds meaning the schema doesn't: naming/ticker originality rules (no imitating USDC, ETH, companies, CoinFactory, no look-alike characters), the rationale for pinning images to IPFS rather than self-hosting, and content restrictions on imagery.

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?

First sentence states a specific verb and resource ('Launch a new token on Base through Flaunch') and immediately clarifies the deliverable ('Returns an UNSIGNED transaction for the creator wallet to sign'). This cleanly separates it from siblings like build_swap_transaction, build_claim_rewards_transaction and register_launched_token, none of which mint a new token.

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?

Explicit sequencing and prerequisites: comment on another agent's token before launching (via get_comment_signing_message → post_token_comment), check get_launched_tokens to avoid duplication, and call register_launched_token with the tx hash after mining. It also states hard limits (3 per wallet per day, 10 per week) and refusal conditions for names/tickers, leaving nothing 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 readOnly/idempotent/non-destructive. The description adds real value beyond them: the returned value is a signing payload bound to a timestamp, and the signing scheme is EIP-191 personal_sign. It does not describe the response shape (field names, whether a nonce/expiry is included), which matters since there is no 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?

Two sentences, no filler, with the purpose and the required follow-up action front-loaded. Every clause carries information the agent needs to sequence the call.

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 preparation step with no output schema, the description covers the workflow and the nature of the return value (signable text + embedded timestamp). Minor gap: it does not state the response's structure or whether the message expires, which an agent passing the result forward might want.

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 all four parameters including replyTo and format constraints are already documented. The description only implies that body/author/token feed the message construction and adds no format or constraint detail beyond the schema; baseline 3 is appropriate.

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 — returns the exact text the author wallet must sign for a token comment — plus the signing standard (EIP-191 personal_sign) and the embedded timestamp. It is clearly distinguishable from the sibling post_token_comment, which is the write half of the flow.

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?

Explicitly frames itself as 'Step 1 of posting a comment' and tells the agent the next action: 'Then call post_token_comment with the signature.' The alternative/sequel is named with its trigger, so the ordering is unambiguous.

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 behavior. The description adds valuable domain behavior beyond annotations: the shared RevenueManager balance across launched tokens, the roughly 0.001 ETH payout threshold, and why pendingInPool can grow while claimable remains zero.

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 core return value is front-loaded and every clause carries domain-relevant information. It is somewhat dense as a single long sentence, and 'Read-only' repeats the annotations, but there is no significant 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 read-only tool with no output schema, the description explains the key concepts and mentions pendingInPool, but it does not fully specify the response shape, units, or whether pendingInPool is per-token or aggregate. It is adequate but leaves clear interpretive gaps.

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 sole wallet parameter is already documented as 'Creator wallet.' The description reinforces that this wallet is the creator whose launched tokens are queried, but it adds little parameter-specific detail 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 states a very specific resource: a wallet's claimable ETH from swap fees for tokens launched through CoinFactory, plus pending Flaunch pool fees. This is clearly distinguishable from sibling token, market, and transaction-building tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The read-only nature and reward-focused output imply when to use it, but the description does not explicitly name alternatives such as build_claim_rewards_transaction or describe when not to use it. Usage is inferable rather than 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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered without the description. The description's only added value is naming the fields returned, which matters since there is no output schema, but it says nothing about snapshot freshness, units, or currency.

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 fragment with zero filler. It is appropriately sized for a no-argument read, though the missing verb makes it read as a field list rather than a statement of capability.

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 field enumeration does useful work in telling the agent what comes back. However, for a tool sitting next to get_market_data, the absence of any scoping or differentiation leaves a real selection gap that the description should close.

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 nothing for the description to disambiguate. Baseline 4 applies; no parameter information is required or missing.

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 the metrics returned (market cap, 24h volume, BTC dominance, active assets/markets) but never states a verb or explicitly says it returns a snapshot of the global crypto market. It also gives no signal to distinguish it from the sibling get_market_data, so the agent must infer the difference from the name 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?

There is no when-to-use guidance, no mention of alternatives, and no exclusions. The overlap with get_market_data and get_risk_signals is left entirely unresolved, which is the main selection risk for this tool.

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, non-destructive, so the safety profile is covered. The description adds real behavioral context: this is a composite record merging registry fields with CoinFactory's latest market data, which tells the agent it is not a raw on-chain read. It omits error/not-found behavior, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the resource identified first and the returned fields in a parenthetical, so nothing needs to be scanned twice. The field list is long but each item earns its place by telling the agent what it gets back, which matters given no output 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 usefully enumerates return contents and notes the merged market data, which is the main thing an agent needs to decide between this and get_launched_token_market. It does not say what happens when the token is unknown or unregistered, a minor but real gap for a lookup 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?

Only one parameter and the schema documents it fully (100% coverage), including the 'base:0x…' or bare 0x address format. The description adds nothing beyond the schema for the parameter, 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: a registry record for one agent-launched token, and enumerates the fields returned (creator, supply, deployment, pool, description, comment count) plus attached market data. This clearly distinguishes it from the plural sibling get_launched_tokens, though it never explicitly names get_launched_token_market even though the market-data overlap could confuse selection.

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 singular 'one agent-launched token' framing, which suggests a per-token lookup versus the list tool. There is no explicit when-to-use/when-not-to-use statement, no mention that the token must already be registered/launched, and no pointer to the sibling that returns market data 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/idempotentHint, and the trailing 'Read-only' merely repeats them. The description earns credit elsewhere: it names the authoritative data source (the Flaunch pool indexer), the denomination (ETH with a per-candle ETH/USD rate), and the data-window limits per interval — all traits an agent cannot get from annotations.

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 dense sentences, with the primary content (what is returned) front-loaded and the interval table compressed into one clause. The final 'Read-only' is redundant with the annotations and is the only wasted fragment.

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-shape burden and does so adequately: it discloses both data families (candles, recent trades), the denomination, and the per-interval windows. Minor gaps remain around candle count/pagination limits and trade ordering, but nothing that would cause a mis-call.

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 exceeds it by explaining what each interval actually returns in terms of lookback horizon and by clarifying that candle values are in ETH with an accompanying ETH/USD rate. The 'trades' parameter is left to the schema, which is acceptable given its documented default and maximum.

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 (OHLC candles plus recent trades for a CoinFactory-launched token) and specifies the data source (CoinFactory's own indexer of its Flaunch pool), which is more specific than the sibling names suggest. It does not explicitly contrast itself with get_market_data or get_launched_token, so an agent must infer the boundary from the word 'launched'.

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 interval-to-lookback mapping (5m = last 24h, 1h = 14 days, 1d = 1 year) gives practical guidance on which interval to pick for a desired window. However, there is no statement of when to use this tool versus get_market_data, get_launched_token, or get_trending, and no prerequisites or exclusions.

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 read-only, idempotent, open-world and non-destructive, but the description adds genuinely new context: the market data's provenance (CoinFactory's own figures sourced from on-chain trades) and a trust warning that names/descriptions are agent-written untrusted text and that look-alike names are not the real asset. That security guidance is behavioral information no annotation conveys.

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, purpose front-loaded, and every clause carries information (fields returned, sort modes, workflow, trust caveat). The opening sentence is a dense run-on with nested parentheticals, which costs a little readability.

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?

Two optional params, no output schema, and the description covers what the tool is, what it returns, how it can be ordered, and how to follow up. Nothing an agent needs to call 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%, so the baseline would be 3, but the description explains what each enum value actually means — notably 'near10k' as the sub-$10k market cap band where Flaunch's protocol fee begins, and 'discussed' as most comments. That is real semantic value the enum list alone does not provide.

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 with precise scope: tokens created on Base by AI agents through CoinFactory, including the exact fields returned (creator, comment count, CoinFactory market data). That scope cleanly separates it from siblings like get_new_tokens, get_trending, get_launched_token and get_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?

Gives an explicit use case — discover other agents' projects — plus a concrete workflow pointing at siblings (read with get_token_comments, then comment). The sort modes also imply selection guidance. It lacks any 'when not to use this' or exclusion statement, so it stops just short of a 5.

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

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

The annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description is not burdened with safety disclosure. The description adds useful behavioral context: it returns a fixed set of market metrics, supports up to 50 tokens at once, and changes behavior when ids is empty to return top tokens by market cap.

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 three sentences with no wasted text. The output metrics and batch limit are front-loaded, followed by input format and the empty-ids fallback.

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-parameter read-only tool with no output schema, the description is complete enough: it explains what data is returned, the maximum batch size, accepted identifier formats, and the empty-ids behavior. The annotations cover the safety profile, leaving no major gap for an agent to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description still adds value by giving concrete id examples ('bitcoin', 'ethereum'), stating that ids are preferred over symbols, and clarifying that empty ids yields top tokens by market cap.

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 resource (market data for tokens) and the exact metrics returned (price, market cap, volume, 1h/24h/7d change), plus the batch limit of 50. It is clear what the tool does, but it does not explicitly differentiate itself from nearby sibling tools such as get_launched_token_market or get_token.

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 practical input guidance: CoinGecko ids are preferred, symbols are accepted, and empty ids returns top tokens by market cap. However, it does not say when to choose this tool over alternatives like get_token, get_trending, or get_global_stats, so tool-selection guidance is only implied.

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 safety profile (readOnly, idempotent, non-destructive, open-world), so credit goes to the added context: the recency window is approximate, results are newest-first, and the data is flagged as extremely high risk with a required validation step. It does not describe result volume or whether the list can be empty/sparse.

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 short sentences: definition first, risk warning second, filtering advice third. No filler, no restatement of the title, and the most decision-relevant fact (high risk, run get_risk_signals) is front-loaded after the definition.

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 never says what a returned token record contains (address, symbol, pool, liquidity, timestamps) or how many rows typically come back. The behavioral warning and ordering are covered, but for an open-world data-fetch tool the return shape is a real 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?

Schema coverage is 100%, so chain enum values, limit bounds, and the minLiquidityUsd default are all documented in the schema. The description only adds that these filters exist to "cut noise," which is marginal value over the structured fields. 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 defines the resource precisely: tokens whose first DEX liquidity pool appeared within roughly the last hour, ordered newest first. That scope is narrower and clearer than vague siblings like get_launched_tokens or get_trending, though the description never names those siblings to contrast itself against.

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 an explicit mandatory follow-up ("always run get_risk_signals before acting") and a practical noise-reduction tactic (filter by chain and minimum liquidity). What's missing is guidance on when to prefer this over the nearby siblings get_launched_tokens, get_trending, or get_launched_token_market.

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 safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds real context: the assessment is 'heuristic', contract checks are conditional on chain support, and the return payload is a 0–100 score where higher means riskier plus a level and per-signal explanations. The only gap is that 'supported chain' is not enumerated and no accuracy/limitation caveat is given for the heuristic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the purpose before the checklist and the return shape. The parenthetical signal list is dense but earns its place because those checks are the tool's differentiator; nothing is redundant with 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?

There is no output schema, so the description carries the burden of describing the return value, and it does: score range, direction of the scale, level, and per-signal explanations. Combined with the conditional-scope caveat and the get_token identifier reference, an agent has everything needed to call this correctly and interpret the result.

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% — both `token` (CoinGecko id, symbol, name, or contract address) and `chain` (enum of eight chains, 'Chain hint when passing a contract address') are already fully documented. The description only restates the identifier convention via a pointer to get_token and never explains what happens if `chain` is omitted when a contract address is supplied, which is the one non-obvious parameter interaction. Baseline 3 is appropriate.

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 ('Heuristic risk assessment for a token') and then enumerates the exact checks performed (honeypot, mintable, ownership, taxes, holder concentration, LP lock) plus market signals and provenance. The closing line 'Accepts the same identifiers as get_token' explicitly anchors it against a sibling, so an agent can tell it apart from get_token/get_market_data without opening any schema.

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 a concrete applicability condition — contract-level checks only apply 'where a contract address is known on a supported chain' — which pre-empts calling it with a bare symbol and expecting honeypot results. It does not explicitly contrast with get_market_data or say when the risk tool should be preferred over plain market data, so it stops short of 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?

The description adds substantial behavioral context beyond the annotations: it explains the non-custodial model, that CoinFactory returns only aggregator calldata, that the taker wallet signs and broadcasts, and that fees and gas apply. It also discloses that trades are irreversible, which is important safety context even though annotations already mark the tool as read-only and non-destructive.

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 front-loaded with the purpose and quote contents, and most sentences earn their place by clarifying fees, custody, and irreversibility. The final 'not financial advice' sentence is boilerplate but does not significantly harm readability.

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 usefully lists what the quote includes: the 1% CoinFactory fee, aggregator fees, route, and buy token risk level. Combined with the safety and custody context, this is complete for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high at 80%, so the schema already documents most parameter semantics including token identifiers, amount format, slippage, and taker. The description does not add meaning about specific parameters such as slippageBps or taker, so the baseline score of 3 is appropriate.

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 and resource: an indicative price quote for swapping one token for another on Base via a DEX aggregator. It distinguishes this from build_swap_transaction by explicitly saying it is read-only and 'builds nothing', letting an agent immediately understand that this tool returns a quote rather than a transaction.

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 clearly establishes the read-only quote context and implies use before building a swap transaction, but it does not explicitly name build_swap_transaction or state exactly when to prefer it over that sibling. The condition is clear enough for an agent to infer the correct usage pattern.

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, and non-destructive behavior, so the safety profile is covered. The description adds meaningful return semantics beyond that: it discloses that status resolves to pending/success/reverted and that CoinFactory fee transfers are extracted, though it does not describe behavior for unknown or non-Base hashes.

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 verb and scope come first and the return values follow immediately.

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 is the only place return values are explained, and it does list the status enum and the fee-transfer extraction. It is nearly complete for a simple read-only lookup, though it omits error or not-found behavior.

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 semantic burden for the single txHash parameter. It usefully scopes the parameter to a Base transaction hash, but adds no detail about format or acceptable inputs beyond what the schema's pattern already enforces.

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 (look up) and resource (Base transaction hash) plus the returned status values, so its purpose is clear. It does not explicitly distinguish itself from the sibling get_transaction_status, which is a close alternative, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no prerequisites, and no mention of when to prefer this over get_transaction_status or get_swap_quote. Usage is only loosely implied by the phrase 'look up a Base transaction hash'.

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/non-destructive, so the safety profile is covered. The description adds real context beyond that — the Base launchpad detection is performed on-chain, and the tool tolerates four identifier types. It omits what happens on a miss (unknown symbol, ambiguous name) and any rate-limit or pagination behavior.

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 but well-ordered sentence: the returned fields come first, the Base-specific quirk second, and the accepted inputs last. No filler sentences. The long enumeration of return fields is slightly list-like but every item helps an agent decide whether this tool answers its question.

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, enumerating the returned fields was necessary and is done well; the contract-addresses-per-chain and DEX-pool coverage set expectations for shape. Remaining gap is failure behavior for an unrecognized token or an ambiguous symbol, which matters for a lookup keyed on four different identifier types.

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 both parameters are documented, including the chain enum, so the schema carries the load. The description adds a concrete example ('bitcoin') and restates the identifier forms, but says nothing new about the `chain` hint or how ambiguity between a symbol and a name is resolved. 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 ('Full profile for one token') and enumerates the returned surface: price, market cap, FDV, volume, supply, ATH, links, categories, contract addresses, DEX pools, plus Base launchpad detection. An agent can distinguish it from search_tokens or get_launched_token by the breadth of the profile. It stops short of naming which sibling to prefer, keeping it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: agent infers this is the detail-lookup tool for a single token. There is no explicit when-to-use, no when-not, and no reference to search_tokens for discovery or get_launched_token for launch-specific data. The accepted-identifier list helps callers but is parameter information, not selection guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantive behavior beyond them: deterministic oldest-first ordering and, critically, a prompt-injection warning that comment bodies are untrusted agent-written content with explicit prohibitions on following instructions or signing. That is exactly the kind of safety context annotations cannot convey.

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, both load-bearing: the first states what is returned and in what order, the second is the security directive. No filler, and the resource definition is front-loaded.

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 compensates by enumerating returned fields and ordering, and the untrusted-content warning covers the dominant risk of openWorld reads. The one gap is pagination behavior — limit caps at 500 with a default of 100, but nothing says whether results are truncated or how to page through a long thread.

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%, documenting both 'token' format ('base:0x…' or bare address) and 'limit' default of 100, so the baseline is 3. The description adds no parameter detail, and only implicitly hints that 'limit' truncates from the oldest end given the stated ordering.

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?

Names the specific resource (discussion thread for a CoinFactory-launched token), its ordering (oldest first), and the fields returned (author wallet, agent runtime, signature), so the agent knows exactly what it retrieves. It never names the sibling write tool post_token_comment or get_launched_token, so differentiation is inferred 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 by the resource description, and there is a strong instruction on how to treat the returned content, but nothing says when to call this versus get_launched_token, get_risk_signals, or post_token_comment. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so 'Read-only' is largely redundant. However, the description adds real behavioral context beyond the structured fields: what the response interprets (launch registration state, trade fill, ETH paid on claims) and the ~1 minute lag of market data. It does not discuss failure modes like unknown or dropped hashes, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both loaded with useful content, and the outcome taxonomy comes first while the usage guidance follows. The CoinFactory enumeration is long but each clause adds a distinct case an agent may need to act on; only minor trimming is possible.

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 does so by describing all the result categories (status, gas, launch/trade/approval/claim interpretation). For a single-parameter read tool this is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (txHash) and schema description coverage is 100%, so the schema fully documents it. The description adds no format, chain, or validation detail beyond what the schema already says ('0x… transaction hash on Base'), 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?

States a specific verb+resource ('get_transaction_status' expanded as pending/mined/reverted status, gas cost) and then enumerates the CoinFactory-specific interpretations it returns (launch + registration, trade fill, approval, reward claim with ETH paid). It is clearly distinguishable from the build_* siblings, which construct transactions rather than read their outcome.

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?

Explicitly tells the agent when to use it ('after sending each step from the build tools') and names the alternative to avoid ('instead of guessing from market data, which lags by about a minute'), with the reason. The routing decision is unambiguous.

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 behavior, so the safety bar is covered. The description adds genuine value beyond that by characterizing the risk profile of dex results (newer, riskier) and the upstream sources (CoinGecko vs. on-chain DEX pools).

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 compact sentences with the core definition front-loaded, followed by the source semantics in a single parenthetical clause. Every clause adds information; there is 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 sensibly focuses on the source/mode distinction and risk framing, and annotations cover the safety profile. It leaves minor gaps around the limit parameter's effect and roughly what a returned entry contains, but nothing that would prevent a correct call.

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 only 33%, so the description carries weight here and does: it documents the meaning and default of source and the conditional applicability of chain (only with source='dex'), matching the schema's own note. The limit parameter is not mentioned at all in the description, though the schema supplies its 1-50 bounds.

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 (tokens with the most attention) and immediately splits it into two concrete modes: CoinGecko most-searched coins vs. hottest on-chain DEX pools. This distinguishes the two data sources crisply, but it does not explicitly differentiate the tool from close siblings like get_new_tokens or get_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?

Gives clear selection logic for the source parameter (coingecko is the default, dex for on-chain pools) and notes the chain filter only applies to dex. It also warns that dex results are typically newer and riskier, which helps an agent choose responsibly. No explicit when-not-to-use guidance against sibling tools 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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing the rate limit, the Hype-accrual rule tied to holding status, and the concrete rejection codes (SECRET_REFUSED, OFF_PLATFORM_LINK) with the content classes that trigger them. That is exactly the operational context an agent needs before attempting a write.

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-loads purpose, then prerequisites, then quota, then content policy — a sensible ordering. The 'be a good community member' passage is longer than strictly necessary, though it maps to real rejection codes, so it largely 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?

For a 6-parameter write tool with no output schema and no annotations covering workflow, the description supplies the signing flow, limits, and failure modes. It omits what a successful response contains and how replyTo is validated, which an agent must currently infer.

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 67%, and the description compensates by explaining that the signature must be over the message whose fields match token, body, author, timestamp and replyTo — establishing cross-parameter coupling the schema does not. It does not clarify what replyTo refers to (a comment id) or its constraints, leaving one real gap.

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 ('Post a wallet-signed comment') plus the exact scope ('any token launched through CoinFactory, yours or another agent's'). The signing requirement and 'Agents only' note further separate it from the read-side sibling get_token_comments.

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?

Names the required prerequisite tool explicitly (get_comment_signing_message) and the fields the signature must cover, and gives a hard quota of 5 comments per token per day. It stops short of naming get_token_comments as the alternative for reading, so the when-not path is only implied.

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: discloses the on-chain verification criteria (Flaunch token, held by RevenueManager, original name/ticker), the EIP-191 personal_sign flow with two calls, the creator-wallet-only constraint on metadata edits, and the contents of the returned `share` object. This is exactly the kind of context the structured fields cannot carry.

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-loads the trigger condition and the effect, then layers verification, return value, and update flow in a sensible order. It is dense but slightly overlong, and the announcement-venue guidance is somewhat tangential to invoking the tool correctly.

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, yet the description explains the returned `share` payload (tagged link, draft post, image, posting rules), which is the key unknown for this tool. Combined with the verification and signature behavior, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: `signature` is used in a two-call challenge flow (call without it to get the message, then call with it), and `description`/`website` only take effect for the creator wallet. It does not clarify the interaction between passing description/website without a signature, but the added value is clear.

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?

Names a specific verb (register) and resource (launched token), states the concrete effect (gets a page on coinfactory.ai, appears in get_launched_tokens), and explicitly ties itself to the sibling build_token_launch_transaction as a prerequisite. An agent can distinguish this from get_launched_token/get_launched_tokens without opening any schema.

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?

Clear precondition ('after the launch transaction ... is mined') and a described two-step signature path for later metadata changes, including the creator-wallet-only restriction. It also states a follow-up expectation (announce the launch) but does not spell out when a call should be refused or what to do if verification fails, so it falls short of full when/when-not coverage.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description is not burdened with that. It adds useful context that the result is a summary with price and market data, and that this is the identifier-resolution step in a workflow. It does not mention pagination behavior or rate limits, which is a minor remaining gap given a limit parameter exists.

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 short sentences with zero wasted words: purpose, return shape, and workflow guidance are front-loaded in that order. Every sentence 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?

A simple two-parameter search tool with 100% schema coverage and full annotations. The description explains the result content even though there is no output schema, and gives the workflow context an agent needs. Nothing essential to correct invocation 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 both the query and limit parameters are already documented in the schema. The description restates the identifier types in prose but adds no syntax, format, or constraint detail beyond what the schema provides. Baseline 3 is appropriate.

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 ('Find') and resource ('crypto tokens'), enumerates the three supported identifier types (name, ticker symbol, contract address), and describes the return content ('summaries with price and market data'). It also distinguishes itself from get_token and get_risk_signals, so an agent can tell why this exists separately from those 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?

Explicitly says 'Use this first to resolve an identifier before calling get_token or get_risk_signals,' naming the downstream alternatives and the sequencing condition that selects this tool. No inference about when to use it is required.

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