pumpdata

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

Beyond the readOnly/idempotent annotations, the description discloses pricing ($0.005 per call in USDC on Solana via x402, or a free key) and the payment handshake — omitting payment returns the offer as error content and _meta['payment-required']. It also defines measurement semantics (a crossing is a first trade inside the band; peak is highest cap in the following 3h; USD valued at the trade hour's SOL price), which materially affects how results should be read.

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

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

The core metric set is front-loaded in the first sentence, with cost and protocol details trailing where they belong. It is dense — several clauses chained with semicolons — 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 5-param analytics query with no output schema, the description covers the metric definitions, the band-snapping behavior, the truncated-window caveat, and the payment flow. The return shape is only implied ('the answer says the band used'), which 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?

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by defining what a 'crossing' is (and that a coin jumping the band in one trade has none), how USD conversion is done, and that the snapped band is echoed in the answer. It does not expand on the venue or payment parameters 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 names a concrete computation: counts of coins whose first trade fell in a market-cap band, how many then hit 2x/5x/10x/20x within 3h, and the median peak. That is specific verb+resource. It never names or contrasts a sibling tool, so it stops short of full sibling differentiation.

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 'For:' clause gives concrete motivating questions ("what are the odds a $20K coin does 10x, how often does it happen anyway"), which clearly signals the intended use. There is no explicit when-not guidance or pointer to an alternative tool for related questions.

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, closed-world and non-destructive, so the safety profile is covered. The description still adds real value with 'Free' (cost behavior) and a full inventory of what the response contains (answer sentences, named flags, rules_say, launch record), which matters because there is no output schema. It does not state latency or whether results are cached.

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

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

Front-loaded with 'Free' and the core action, and no sentence is filler. The flag enumeration makes the middle dense and run-on, but each listed flag is a distinct output an agent would otherwise not know to expect.

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, non-paginated tool with no output schema, the description covers input meaning, cost, and the shape of the return value in enough detail to call and interpret it. Nothing an agent needs to invoke 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 there is only one parameter, so the baseline is already high. The description still adds meaning by glossing mint as 'contract address, CA', bridging the term a user would say to the field name the schema requires.

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: 'the pre-buy check of one pump.fun coin by its mint ... in one call,' and enumerates what comes back. The 'in one call' phrasing implicitly separates it from facet-level siblings like deployer_record or launch_record, but it never names an alternative, so the differentiation is inferred rather than explicit.

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

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

The 'For:' clause gives concrete user intents ('check this coin', 'is this a rug', 'should I buy this', 'is this coin bundled') that map cleanly onto invocation triggers. It lacks any when-not guidance or pointer to the cheaper facet tools when only one signal is needed.

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, non-destructive, closed-world behavior, and the description still adds substantive context: the data is read from chain, the bonding curve and pool vaults are excluded from the totals, the response flags wallets holding identical amounts (one bag split across wallets), and program holdings are broken out. It also warns that count=true is a slower read.

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

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

The key qualifier ('Free', top 20, chain-read, exclusions) is front-loaded and every clause carries information. The prose is dense and heavily parenthesized, making it slightly harder to scan than it could 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 only two parameters, full schema coverage, and no output schema, the description carries the burden of describing returns itself — and it does, covering holder shares, exclusion rules, duplicate-amount detection, program holdings, and the optional count. 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 both the mint address and the boolean count flag are already documented, including the 'slower read' caveat. The description restates that count adds the holder count without adding new meaning, so the baseline 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?

States a specific resource and scope: the 20 biggest wallet holders of a pump.fun coin, read live from chain, each with its supply share. It explicitly carves out what is excluded (bonding curve and pool vaults) and names the sibling to use next (wallet_records), so it is distinguishable from top_wallets and wallet_trades.

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 'For: who holds this coin, top holders, is the supply concentrated' clause gives concrete trigger questions, and the closing sentence routes follow-up work to wallet_records. It stops short of an explicit when-not-to-use or a contrast with the sibling top_wallets, so 4 rather than 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?

Beyond the annotations (already covering read-only, idempotent, non-destructive, closed-world), the description discloses freshness semantics that materially affect how results should be trusted: near-real-time (within 10 seconds) for coins traded in the last 12 hours, otherwise an hourly fill. It also states the data source, the 50-coin ceiling, the 'Free' cost, and that values are returned in both SOL and USD.

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 plus a short 'For:' list, front-loaded with 'Free.' and then the core capability. Nearly every clause carries information (source, staleness, cap, currencies), though the freshness clause is packed tightly enough that it takes a second read.

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 takes on the job of saying what comes back: market cap and price, in SOL and USD, with a freshness qualifier. What it omits is edge behavior — what is returned for mints that never traded, unknown/invalid mints, or how missing entries appear in 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 coverage is 100% and the single parameter is documented in-schema (base58 mint addresses, min 1 / max 50). The description repeats the 'up to 50' limit but adds no new meaning about input format, ordering of results, or how partially-invalid mint lists are handled. Baseline 3 applies when the schema already carries the parameter burden.

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 precise verb-and-resource pair: it returns current market cap and price for up to 50 pump.fun coin mints, and it names the underlying data source (bonding curve last trade or the coin's own PumpSwap pool). That is far more specific than the tool name alone. It does not, however, distinguish itself from coin-related siblings such as check_coin or find_coin, so an agent must infer 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 'For:' clause gives concrete triggering questions ('what is this coin's market cap', 'price of these coins', 'is it still trading'), which is a genuinely useful routing cue. It stops short of naming a when-not condition or an explicit alternative tool, so the agent gets positive guidance but no 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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds the piece annotations cannot: a paid endpoint at $0.005/call, settled in USDC on Solana via x402, with a free-key alternative, plus a factual (not scored) output stance — useful disclosure that changes how an agent plans the call. It does not mention rate limits, latency or failure modes beyond payment.

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

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

Front-loaded with the resource and its contents, and every clause carries information — no filler. It is a single dense run-on stitched with semicolons, which costs some parseability, but with no output schema the enumerated return contents are earning their space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating the returned fields and the 90-day outcome buckets in detail. Combined with full schema coverage of both parameters and explicit payment/cost mechanics, an agent has everything needed to call it correctly and predict what comes back.

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%: the address parameter (base58 wallet address) and the payment/x402-signature parameter are fully documented in the schema, including the offer-on-omission behavior. The description only restates 'by wallet address' and 'no coin needed', adding nothing the schema does not already say, 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 pump.fun deployer's record by wallet address — and then enumerates exactly what the record contains (launches, graduations, best run, launch gaps, 90-day outcomes, newest launches, base rate for next launch). 'No coin needed' explicitly distinguishes it from the coin-keyed siblings like check_coin and find_coin, so an agent can route without opening a 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?

The 'For:' clause gives concrete query intents — 'this dev's history', 'a serial deployer', 'has this creator rugged before', 'the deployer's track record' — which map well onto how an agent would phrase a request. It stops short of naming an alternative sibling or stating when not to use it (e.g. vs. wallet_records or base_rate).

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, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value: it is free to call, it indexes only the ~300K coins that completed their bonding curve, and it returns a specific field set including deployer stats, graduation flag, and market cap snapshots.

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 with useful information but delivered as one run-on sentence with a dangling opening fragment ("Free.") and an awkward embedded field list. Every fact roughly earns its place, but the structure does not front-load the action and is harder to parse than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by naming the returned fields and ordering. The coverage limitation and free-call status round out what an agent needs; only the empty-result behavior is unaddressed, which is minor for a simple lookup.

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

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

Schema coverage is 100%, so both q and limit are already fully documented, including the $KIMCHI/KIMCHI forms and the default of 20. The only semantic addition is that passing a mint returns that coin's name, which is marginal beyond the schema; 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?

It states a specific verb and resource — look up pump.fun coins by ticker, name, or mint, newest first — and names the sibling to follow with (launch_record on the mint). The opening clause is grammatically broken ("The pump.fun coins a ticker or name means"), which costs clarity but not comprehensibility.

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?

Concrete use cases are enumerated ("what is $KIMCHI's CA", "which Kimchi is the real one", "find this coin by name") plus a routing hint to launch_record once the mint is known. The key exclusion is also stated — coins still on their bonding curve are not covered — though no alternative is offered for those.

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, closed-world), and the description adds real context on top: 'Free' discloses there is no cost/quota, 'as they land' indicates a live feed rather than a batch, and it bounds availability to the last three UTC days. It does not disclose result caps, ordering, or pagination, which limits it to a 4.

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 dense but purposeful sentences: capability first, then return-field notes, then use cases. The telegraphic 'For: ...' construction is slightly awkward and the 'same_second' aside is parenthetically crammed in, but nothing is padding.

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 returns and does so for the distinctive fields (seconds from launch, same_second flag, deployer record on day mode). It omits result ordering, volume, and any cap on number of coins returned, which leaves a real gap for a list-style 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 100% and the schema already spells out the YYYY-MM-DD day window and the unix-seconds 'since' semantics, so the description largely restates rather than extends it. The one clarification it adds is the either/or relationship between 'day' and 'since' and the default ten-minute window, which is also already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource precisely: pump.fun coins whose bonding curve completed, with two mutually exclusive retrieval modes (last hour via 'since', or a whole UTC day of the last three via 'day'). An agent can tell this is a graduation feed rather than a launch feed, though it does not explicitly name the sibling it is not (launches_since).

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 'For:' sentence gives three concrete triggering questions (what just graduated, how many graduated today, which graduated in the same second) and names the follow-up tool (check_coin on a mint). No explicit exclusion such as 'use launches_since for pre-graduation coins', so it falls 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?

Goes well past the annotations by disclosing freshness/latency ('launches newer than the hourly fill come within the minute (source live, bundle not yet read)'), result ordering (oldest first), and that the call is free. These are exactly the operational traits an agent needs to decide polling cadence and whether enrichment fields are trustworthy.

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

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

Front-loaded and waste-free in intent, but the sentences are heavily packed — the parenthetical '(launches, graduations, seconds since its last launch)' and 'Free.' as a fragment take parsing effort. Nothing is redundant, though; trimming would cost real information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five optional params and no output schema, the description carries the return-shape burden and does so partially: order, enrichment fields and freshness are covered, but the fill-in of check-style metrics is not spelled out, and nothing is said about behavior on empty ranges or the 24-hour window boundary.

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 the cursor contract that the input schema cannot express: the returned next_since is what should be fed back into t. It stays silent on the `check` vs check_coin naming overlap, which is the one place extra clarity would have helped.

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 and scope: 'Every pump.fun launch after a moment in the last 24 hours, oldest first', plus what each row carries (deployer record, first-10-second bundle). An agent can tell this is a paged, raw launch feed rather than a per-coin lookup (check_coin) or a stats/odds tool.

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

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

Explicit use cases ('what launched just now', 'new coins from devs with a record', 'watch new launches') and an explicit routing rule: poll with t = next_since and reserve check_coin for coins worth a look. What is missing is differentiation from close siblings like live_events, replay or today_live, which an agent must still guess between.

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, non-destructive behavior. The description adds meaningful behavioral context beyond that: pricing ($0.005 per call, USDC on Solana over x402 or a free key), how payment offers are returned if the payment field is omitted, and that the output is facts with no verdict. There is no annotation contradiction.

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, very long run-on sentence with many nested parentheticals and a duplicated phrase ('whether one or one or two wallets'). It front-loads the basic purpose but lacks structural separation and is hard to scan, despite containing useful detail.

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 return-value burden and does so exhaustively: deployer record, bundle at creation, insider share, curve progress, market cap, SOL reserve, holders, top traders, and comparable-launch outcomes. It also covers payment flow and use contexts, leaving little an agent needs 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%, and both parameters are documented in the schema: mint as the base58 coin mint and payment as the x402 PAYMENT-SIGNATURE. The description adds only the shorthand 'contract address, CA' and reiterates the payment model, so 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?

The description states a specific verb and resource: check a pump.fun coin by its mint, and enumerates the facts returned. However, it does not distinguish this aggregate from overlapping siblings such as check_coin, deployer_record, or similar_launches, so an agent cannot tell exactly when this tool is preferred over those.

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 explicitly lists use cases: check this coin, a rug check, is this coin bundled, who holds it, who made money on it, who deployed this token, is this dev legit. It gives clear positive context but no when-not guidance or alternative routing to the many siblings that cover subsets of the same data.

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, and the description adds real value on top: it is free, capped to a rolling one-hour window, ordered oldest first, and it reveals a 'next_since' cursor for polling that appears nowhere in the input schema or annotations. It stops short of describing rate limits or the response envelope.

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 front-loaded ('Free. The last hour's pump.fun events'), then detail, then use-cases, then the polling rule, with no filler sentences. The long parenthetical enumerations each carry distinct information about what an event record contains.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by describing the payload of each event kind. The one gap is the response envelope itself — it references a 'next_since' cursor without stating what else comes back or how the cursor field is named or placed.

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 workflow meaning the schema lacks: 'Poll with since = next_since' explains how the cursor is meant to be used across successive calls, and 'as they land, oldest first' clarifies the ordering that 'since' interacts with.

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 exact resource ('the last hour's pump.fun events as they land, oldest first') and enumerates all four event kinds and the fields each carries, so an agent can tell it apart from siblings like launches_since, graduations, or today_live 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?

The 'For:' clause gives concrete triggering questions (did the dev sell, which devs are dumping, what just launched or migrated) and the polling instruction tells the agent how to keep consuming the stream. It does not explicitly say when to prefer a sibling (e.g. launches_since for a wider window, graduations for older history), which keeps it below 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?

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuinely non-obvious traits: the data is yesterday's snapshot, "Dead coins count" (survivorship handling), a fixed three-hour horizon, and that the tool is free while base_rate is paid. It still doesn't describe pagination or output shape, but it discloses the behavioral quirks that matter most.

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

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

Front-loaded with cost and scope, and every clause (bands, metrics, horizon, dead coins, paid alternative) carries information. The "For:" sentence is a fragment and the first sentence is long, but no wording is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so: per-band counts, breakout shares at four thresholds, and median peak are all specified. Cost, data freshness, and horizon are covered; only result ordering/volume is 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The band range ($5k-10k up to $250k-1M) clarifies the population being aggregated even though it isn't a callable argument.

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 resource (yesterday's pump.fun odds by market-cap band) and the exact metrics returned: coins first traded per band, share reaching 2x/5x/10x/20x within three hours, and median peak. It also distinguishes itself from check_coin (per-coin odds) and base_rate (any window), so an agent can route without opening a 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?

The "For:" clause gives concrete triggering questions ("odds a pump.fun coin at $20k does a 2x") and it explicitly redirects to check_coin when the question is about a specific coin's deployer/early buyers, and to base_rate for arbitrary windows. When-to-use and alternatives are both 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?

It goes well beyond the annotations: the tool is a queued job returning {id, state: queued}, costs $2 USDC on Solana via x402, a failed run is rerun free on the same id, only graduates are filled, bonding-curve picks land in skipped_not_covered, and the most recent eight weeks are returned separately. The readOnlyHint is defensible for a pure simulation, but the description usefully discloses the job creation and payment side effects the annotation does not capture.

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 and inputs come first, then the queue/payment mechanics, then the polling instruction — good front-loading. The prose is dense and slightly convoluted in places ('what they made, pick by pick and in sum, every pick counted, the dead ones included'), but nearly every clause carries operational 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 5-parameter tool with a nested exit object and no output schema, the description covers the return shape ({id, state}), the follow-up tool, the payment handshake, coverage gaps, and cost. Nothing an agent needs to invoke 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 is 3, and the description adds real value by defining which picks are valid ('bonding-curve picks, and picks outside the archive, are counted in skipped_not_covered') and by tying latency_s to the fill ('filled at the PumpSwap pool as it stood after your latency'). It does not elaborate on the exit object's take/trail interplay, but the schema already documents those fields.

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 and resource ('Backtest pump.fun picks') and goes further to specify the fill model (PumpSwap pool after latency), fee handling, and coverage limits. An agent can distinguish it from replay_result, check_coin, or launch_record 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?

It gives explicit caller intents ('backtest my calls', 'would this strategy have made money', 'replay these picks with real fills') and routes the follow-up step by name: 'poll replay_result with the id'. The queue-job semantics and the payment prerequisite are stated up front, so the agent knows both when to use it and what happens next.

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=false, so the safety profile is covered. The description adds 'Free,' which discloses a cost trait not in annotations, and hints that this surfaces a job's state and completed replay. It does not explain behavior for jobs still running or error conditions, so the added value is modest.

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 short, but the middle clause ('the replay once done with the execution model it charged') is dense and ambiguous, forcing rereads. The 'Free' cost note is front-loaded usefully, but the overall phrase structure sacrifices clarity for terseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only lookup with no output schema, the description does enough: it names the returned concepts (job state, replay, execution model) and flags the free/cost trait. Missing details about pending-job behavior and error handling keep it short of fully complete, but an agent can 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% for the single parameter ('the id from replay'), so the schema already carries the semantic load. The description's 'the id is the receipt' reinforces that the id comes from the replay call, adding a little meaning but no format or sourcing 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?

The description indicates the tool returns a replay's result, including job state and the completed replay, which is enough to identify it as a result-retrieval endpoint. However, it never states a clear verb like 'get' or 'fetch,' and the phrase 'the replay once done with the execution model it charged' is opaque, making the exact purpose only loosely clear. The sibling tool 'replay' is referenced only obliquely through 'the id is the receipt.'

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: 'the id is the receipt' and the schema's 'the id from replay' together suggest this is called with an id obtained from the replay tool. There is no explicit statement of when to use this versus replay, nor any exclusion or prerequisite, so an agent must infer the call sequence.

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?

Adds substantial context beyond the annotations: free of charge, 2,000-character cap, automatic stripping of code/markup/key-like strings, human-read, and 'nothing comes back but a receipt' which explains the absence of an output schema. It also warns against including secrets or private keys, which the annotations (readOnlyHint=false, destructiveHint=false) do not 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?

A single front-loaded paragraph with no filler; the free/no-cost note and the report-worthy examples come before the sanitization and secrecy caveats, which is the right order for an agent deciding whether to call it.

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?

Covers everything needed for a write-only, no-output tool: what to include, length limit, content filtering, who reads it, that no response data is returned, and a privacy warning. Nothing an agent needs in order 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 75%, and the description still adds meaning: the message is plain text capped at 2,000 characters and gets sanitized, 'about' is implied by the 'a coin or wallet with no record' example, and 'contact' is implied by the note that nothing comes back but a receipt. The kind enum values are left to the schema, which is acceptable.

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 recipient: tell the people who run pumpdata.fun what you were trying to do and what was wrong or missing. The examples (missing coin/wallet record, needed field, wrong answer, failed call) make it unmistakably distinct from the data-lookup siblings like check_coin or wallet_records.

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 when-to-use triggers: a coin or wallet with no record, a field you needed, an answer that looked wrong, a call that failed. It does not name an explicit exclusion or point at an alternative sibling, but no sibling competes for this purpose, so the routing 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 the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real value beyond them: pricing ($0.005/call, USDC on Solana via x402), the payment negotiation flow, and the ranking logic (same deployer's prior launches first, then nearest of the last 90 days by deployer record, first-10s buyers, insider share, curve progress). That is substantial behavioral context an agent could not get from structured fields.

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

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

The scope statement is reasonably front-loaded, but the second sentence is an extremely long chain of nested clauses that is hard to parse on one read. The content is valuable but is not structured for scanning — bullet or semicolon separation would help.

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 returns and it largely does — outcome fields, the 'why it is similar' rationale, and the payment-required error path for omitted payment. Only the pagination/ordering of the returned list is left implicit.

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 all three parameters are already documented and the baseline is 3. The description earns one above baseline by defining what 'similar' actually means (deployer record, early buyers, insider share, curve progress), which gives the agent a mental model for the mint argument beyond the schema's 'base58 address'.

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 and resource — 'the pump.fun launches most like this coin at the same age' — and immediately lists what is returned for each (peak, close, dead or graduated). This is clearly distinct from siblings like launch_record, base_rate, or replay, which do not do comparable-set retrieval.

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?

'For: coins like this one, what happened to launches like this, comparables' gives explicit use cases, and 'Not a prediction: what launches that looked like this did next' draws a scope boundary. It never names a sibling alternative (e.g., launch_record for a single launch), so it stops short of full routing 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely non-obvious behavioral context: 'free' implies a paid tier boundary, `checks` lists numbers that failed a sanity check and must never be quoted, and `summary` is the quotable paragraph. It does not state rate limits or response size, which keeps it at 4 rather than 5.

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

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

Front-loaded with the resource and scope, and every clause maps to a real payload section. The long semicolon chain of contents is dense and slightly hard to scan, but no sentence is filler and the operational warnings (`checks`, `summary`) come after the payload inventory where they belong.

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 by enumerating the payload sections and flagging the two special fields (`checks`, `summary`) that change how an agent should report results. Only the precise key names and nesting of each section are left implicit, which is a minor gap for a read-only aggregate.

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 schema coverage is 100%, so the schema already defines the format and the 'default the latest' behavior. The description restates 'one UTC day' and the default but adds no syntax, edge-case, or timezone-caveat detail beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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 resource and scope precisely ('Pump.fun stats for one UTC day') and then enumerates the exact payload: launches, graduations, graduation rate, SOL/USD volume, traders, top coins by peak market cap and volume, deployer leaderboard, instant/fastest graduations, hourly rates, and dead launches. The final clause distinguishes it from the paid per-entity siblings (launch_record, deployer_record), so an agent can tell it apart without opening a 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?

The 'For:' clause gives concrete trigger phrasings ('pump.fun today or yesterday, how many coins launched...'), which is stronger than most. It also routes deeper follow-ups to launch_record and deployer_record. It stops short of naming when NOT to use it relative to other day/range siblings like base_rate or launches_since, so it falls short of explicit exclusion 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 and openWorldHint=false, so the safety profile is covered. The description adds non-obvious context beyond that: it is 'Free', the data snapshot is dated ('Nov 3'), and the observation windows (2 hours, 3 days, 14 days) are spelled out. It does not mention rate limits or latency, 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?

It is front-loaded well with 'Free. One ticker's crowd (Nov 3)', but the core sentence is an extremely long run-on that chains five distinct output categories together. The information is relevant, yet a bulleted breakdown would make the enumerated outputs far easier to parse and retain.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the return shape, and it does so comprehensively across every window and aggregate the tool returns. A couple of phrases ('the first and the biggest named') are slightly ambiguous, but an agent knows what it will get and when to call 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% and the schema already documents that the symbol may be given as '$KIMCHI or KIMCHI'. The description supplies background on what a ticker is (88.3% of launches reuse one) but adds no syntax, casing, or resolution rules for the parameter itself, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource ('one ticker's crowd') and enumerates exactly what the response contains: launches over the last three days by UTC day, graduations with timing, last-two-hour counts, 14-day deployer history, and all graduated coins for the ticker. It never names a sibling tool such as check_coin or launch_record, so differentiation is left to inference from the enumerated output shape.

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 a concrete decision context ('before buying a coin, see every coin with its ticker') and explicit use cases ('how many $KIMCHI launched today, did the first one or a later one run, is this a rerun'). It stops short of stating when not to use it or which sibling to pick for a single-coin lookup, so the agent must infer 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 already cover read-only, idempotent, non-destructive behavior, so the description's added value is the freshness model: values are counted from chain as trades land and therefore represent a partial, moving day boundary in UTC, with yesterday shown alongside for comparison. It also states 'Free', which matters for cost-aware agents. It stops short of describing latency, caching, or how the yesterday comparison is presented, but it adds real context beyond the 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?

Front-loads 'Free' and the live/UTC framing, then the metric inventory, then the matching user questions, then the handoff to `stats`. Structurally sound, though the metric run-on is dense and one clause ('distinct traders and coins traded') could be trimmed without loss.

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 parameters and no output schema, the description carries the burden of describing returns, and it does so by enumerating every metric plus the yesterday-comparison. Nothing essential to a correct zero-arg call is missing; only secondary details like ordering, refresh cadence, or units formatting are 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?

The tool takes zero parameters, so the baseline is 4. The description correctly does not invent parameter semantics and instead spends its words on what the parameterless call returns, which is the right allocation.

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 resource and scope: pump.fun metrics for today so far in UTC, counted live from chain. It enumerates the exact fields returned (launches, graduations, migrations, trades, SOL/USD volume, distinct traders, large trades, dev sells, graduation rate) and explicitly distinguishes itself from the sibling `stats` tool, which covers a settled day.

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 query intents ('how many coins launched today', 'volume today', 'how many graduated so far') plus an explicit exclusion routing to an alternative: 'For a whole settled day, use stats.' That is exactly the when-to-use / when-not-to-use / alternative structure an agent needs to choose between the two.

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 (read-only, idempotent), and the description goes well beyond them: it declares the tool free, the inclusion criteria (10+ SOL out, 1% net positive over 20+ coin-weeks, traded in the last ~20 days), the followability thresholds, and the withdrawal of the copyable ranking with the reason. It even previews what each row carries, 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?

The core identity is front-loaded, but the long parenthetical about the Oct 31 withdrawal is convoluted ('at them, copying the best-scored wallets 1 slot behind lost money in all seven weeks tested') and consumes disproportionate space. The information is real, yet the phrasing could be compressed without losing the warning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so: each wallet comes with why it qualified, SOL in and out, its coins, and recent pace metrics. Combined with universe and ranking rules, an agent has everything needed to call it and interpret results.

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 baseline would be 3, but the description adds real meaning: it spells out followable's concrete thresholds (under 20 trades/day, median hold of 2+ minutes, under half fast trades) rather than the schema's vague 'wallets a copier can keep up with', and explains when sort=own is forced. It says nothing about limit, but the schema documents that fully.

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 the specific resource and scope up front: the pump.fun wallet leaderboard ranked by each wallet's own profit. It explicitly distinguishes itself from pump.fun's own leaderboard ('which ranks recent profit') and points to wallet_records for per-wallet detail, so an agent can place it among siblings without opening a 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 literal use-case list ('who should I copy trade, the best pump.fun traders, smart money wallets'), names the alternative it is not, and routes to wallet_records for full records. It also discloses that the follower ranking is currently withdrawn, which prevents an agent from selecting a mode that no longer produces useful results.

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 the description still adds substantial behavior the agent could not otherwise know: the quality filters baked into every result, the meaning of the two lanes, that the wallet list is window buyers rather than holders, and a self-critical backtest caveat ('most listed coins were below their listed price an hour later'). That caveat plus 'Not a recommendation' is exactly the kind of expectation-setting that annotations cannot supply.

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

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

Front-loaded with 'Free.' and the core definition, and nearly every clause carries information (filters, lanes, returned fields, caveat). It is weakened by a single 40+ word run-on sentence with stacked qualifiers and a mildly redundant 'For:' restatement of what was already said.

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 compensates by enumerating the returned fields (net SOL in, window buyers, largest buy, market cap, age, early concentration, and the list's own backtest). Combined with the filter disclosure and lane semantics, an agent knows what it will get and how to interpret it before calling.

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

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

Schema coverage is 100% and each parameter already carries a default, so the baseline would be 3; the description earns an extra point by defining what the lane values actually mean ('new (launched inside the window, curve not finished) and hot (any age)') and by confirming the default window of 6h. It does not clarify the 'both' lane value or how limit applies per lane, leaving a small 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+resource+scope: 'pump.fun coins with the most SOL flowing in over the trailing window', then narrows with explicit inclusion filters (first-10s buyers <30%, <30% dust, real float, no launch-slot buyout) and two lanes (new/hot). It also distinguishes itself from the sibling check_coin by naming it as the follow-up rather than a substitute, so the agent can separate it from find_coin, launches_since and similar_launches without opening 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?

Gives concrete when-to-use triggers ('what is trending on pump.fun, what is hot right now, new coins with money coming in') and an explicit next step ('then check_coin on a mint'), which is real routing guidance. It stops short of contrasting itself with the closest list-generating siblings (launches_since, similar_launches, base_rate), so the agent must infer those boundaries.

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), and the description adds real context beyond them: batching cap of 50 addresses per call, $0.01 per-call pricing via x402 USDC, and the free-key alternative. It does not discuss failure modes for malformed addresses or latency, so it is strong but not complete.

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 in the first clause and the fields list follows, with pricing/limits at the tail so an agent can stop reading early. The long parenthetical defining every class is dense but justified because there is no output schema to carry those definitions elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by naming pnl_sol, put_in, took_out, coins, first_seen and recent, plus the class taxonomy. Payment acquisition and the batch cap are covered; the only gap is the exact response envelope and per-address error 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 coverage is 100%, so the schema already documents all three parameters including mint's effect on the 'new' classification and payment's x402 offer flow. The description reinforces the batching limit and the mint-relative notion of 'new' but adds no syntax or format detail beyond the schema; 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 definition opens with a specific verb and resource ("Check pump.fun wallets by address") and then enumerates both the classification it returns and the fields behind it, so an agent knows exactly what comes back. It is distinguishable from siblings like deployer_record and top_wallets by being address-keyed lookup, though it never explicitly names those siblings to route between them.

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?

"For:" enumerates concrete use cases — who is buying this coin, is this wallet a bot, a wallet's PnL, a holder check on the top buyers — which gives an agent a clear trigger condition. No explicit exclusions or named alternative tools are given, so it stops short of full routing 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, so the bar is lower, and the description still adds real context: it is free, hard-capped at 50 wallets and a 3-hour window, results are oldest first, and the default window is the last ten minutes. It does not say what happens at the 3-hour boundary or whether results are truncated beyond the 50-wallet 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?

Front-loads the cost signal ("Free") and packs scope, output fields, use cases and sibling routing into three sentences with no filler. The telegraphic style ("every size unless min_sol") is dense enough that it takes a second read, which keeps it just short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating the returned fields (coin, side, SOL, venue, time) along with ordering. Combined with the window limit, wallet cap, cost, and sibling disambiguation, 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 meaning beyond it by stating that trades of every size are returned unless min_sol is set and that ordering is oldest first. It does not elaborate on since formatting beyond what the schema already documents in unix seconds.

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 with full scope: pump.fun trades (bonding curve and PumpSwap) for up to 50 wallets over the last 3 hours, returned oldest first with named fields. It explicitly separates itself from the sibling wallet_records ("a record, not a signal"), so an agent can choose without opening either 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 concrete triggering questions ("what has this wallet traded today", "follow these wallets", "did this wallet sell") and names the alternative tool plus the condition that selects it (wallet_records for lifetime status). Both when-to-use and when-to-use-something-else are present.

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 closed-world, so the safety profile is covered. The description adds genuinely useful behavior: trades are read from the chain as they land (live, incremental), ordering is oldest first, and the call is free. No mention of rate limits or failure modes, which keeps it short of a 5.

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

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

Front-loads 'Free' and the scope in one dense sentence, then the wallet filter, then the use cases, then the handoff to siblings. The long first sentence is a run-on but every clause carries information; nothing 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 takes on return-value disclosure and does it well by enumerating wallet, coin name/symbol/mint, side, SOL, USD and market cap at trade. The time window and default threshold are also given. Only minor gaps remain, such as what happens when no trades match.

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 explains side, limit, since, wallet and min_usd. The description restates the wallet scoping and the $2,500/$1,000 threshold rather than adding new syntax or edge-case meaning, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: every pump.fun buy/sell of $2,500+ in the last hour, read from chain, oldest first, with the exact fields returned. An agent can immediately tell this apart from check_coin, wallet_records, or top_wallets.

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 triggering questions ('what are whales buying', 'did this wallet buy or sell') and explicitly redirects: 'A record of what wallets did, not a signal; then check_coin on a mint, wallet_records on a wallet.' Both the when-to-use and the alternatives are named.

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. Beyond that, the description discloses genuinely behavioral facts: the walk goes up to five hops back, terminates at wallets with more than 5,000 transactions (exchange/service/bot mark), returns amount, time and transaction per hop, reports where the walk stopped, and is free. It does not mention latency, rate limits, or what happens when no funding path is found.

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 purpose is front-loaded and every clause carries information, but the core sentence is a sprawling semicolon chain that is hard to parse on first read. The 'For:' block partially restates what the opening clause already implied, adding some redundancy to an already dense description.

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 real work by describing what comes back: each hop with amount, time and transaction, the walk's stopping point, and co-funded wallets sharing the same first funder. That is enough for an agent to know what to expect, though the response shape (field names, ordering, empty-result behavior) remains unspecified.

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 'address' parameter is documented in the schema as a base58 wallet address, so the schema already carries the parameter burden. The description adds only a mild clarification that the input can be 'any address', not just a known dev or buyer — a marginal but real addition over 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 specific verb and resource — tracing the first SOL funding of a Solana wallet — and immediately scopes it with examples ('a pump.fun dev, a buyer, any address'). It is clearly distinguishable from siblings like wallet_records, wallet_trades or deployer_record, which report activity rather than provenance.

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 use-case block ('For: who is behind this dev, where did this wallet's money come from, are these wallets funded by the same address'), which tells the agent exactly what questions this tool answers. It stops short of naming a sibling alternative or stating when not to use it, so it is clear context rather than full routing guidance.

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