A.U.G.U.R Foresight

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial non-structured context: pay-per-call pricing ($0.003, 10 free/day, x402 payment-required result), error behavior (isError, not charged), and the crucial semantic caveat that 'ok:true' means no red flags were found, not that the coin is safe. This discloses behavioral traits well 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-loaded with the core purpose before the rule details, and most content (skip rules with back-test numbers, pricing, error semantics) is genuinely load-bearing. It is dense and somewhat long, with the enumerated skip rules reading like a spec list, but almost 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?

An output schema exists, so return values need not be explained in prose. Given a single required parameter, rich annotations, and an output schema, the description supplies everything extra an agent needs: scope, verdict semantics, cost model, and failure 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?

There is a single parameter with 100% schema description coverage that already documents the Base58 mint format, so the schema carries the burden. The description adds only the qualifier that pump.fun launches get the full bundle view, which is scoping context rather than parameter syntax; 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: 'Who bundled a Solana pump.fun launch,' then enumerates the exact analyses performed (block-0 labelling, supply held, serial-dev check, top-10 concentration, RugCheck, back-tested verdict). It explicitly distinguishes itself from launch_scan ('for a scored launch verdict use launch_scan'), so an agent can route between them 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?

Has an explicit 'When to use' section that names the scenario (see WHO bundled a launch, get the skip/pass rug guard) and names the alternative (launch_scan) with the condition that selects it. Nothing about selection is left 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?

Goes well beyond the annotations (readOnly/idempotent/non-destructive): it discloses the fill model (bonding-curve reserves from the recorded tape, including curve fees and the copy's own price impact), the latency grid, the returned verdict categories, and pricing ($0.03/call, 10 free/day, x402 payment-required result). It also clarifies that upstream errors return isError and are not charged.

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 core question and the mechanism, then layers simulation details, output, verdict, and operational notes (cost, errors). Dense but mostly non-redundant; the motivating line about wallets that look great on their own PnL earns its place as rationale, though the prose runs long.

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?

Given an output schema exists, the description need not explain returns, yet it summarizes PnL/win-rate/ROI per latency and the verdict anyway. Combined with cost, error behavior, and the when-to-use hook, 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 description coverage is 100%, so every parameter is already documented with ranges, defaults and the exit enum. The description reinforces the meaning ('last 1-14 days', 'sells when the leader sells') but adds no syntax or semantics 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+resource (replays a wallet's pump.fun entries/exits) and frames it with a concrete question ('Would copying this wallet have made money?'). It explicitly distinguishes itself from sibling tools by naming pump_wallet and smart_money as the upstream steps, so an agent can place it in the workflow without opening the 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?

'When to use: After pump_wallet or smart_money, to check copying survives realistic delay' gives both the trigger condition and the alternatives it complements. It also states cost and error semantics, leaving no routing or invocation ambiguity.

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 establish readOnly/idempotent/non-destructive, and the description goes well beyond them by disclosing cost ($0.005/call), a free tier with a concrete limit (10/day), the post-quota behavior (payment-required result listing x402 options), and error semantics (isError on invalid input or upstream failure, not charged). These are exactly the operational traits an agent needs before invoking a paid external call.

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 tight sentences with distinct jobs: what it does, when to use it, and operational caveats (price/errors). The verdict is front-loaded and 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?

An output schema exists, so return-value detail is not required, and the description still hints at the return shape (risk level + reasons). With a single fully-documented parameter, annotations covering safety, and pricing/error behavior spelled out, 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?

Only one parameter and schema description coverage is 100%, so the schema already documents the Base58 pattern and length. The description adds the contextual framing that the wallet is a Solana counterparty, but no extra syntax or format guidance. 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?

Opens with a specific verb+resource+scope: 'One-call verdict on a Solana wallet', then enumerates the verdict classes (serial token launcher, fast dumper, trading bot, clean) and the data sources (pump.fun launch history + trading profile). This clearly separates it from siblings like pump_wallet, address_check, and token_risk.

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 'When to use: Before sending to or trading with a Solana wallet' states the trigger condition, and 'for full trade stats use pump_wallet' names the alternative and the circumstance that selects it. Nothing is left 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 cover the read-only/idempotent safety profile, and the description adds substantial context beyond them: data provenance (own discovery engine decoding DLMM instructions across high-volume/high-yield pools), refresh cadence (every few hours), cost model ($0.02/call, 10 free/day, x402 payment-required result), and error behavior (isError, not charged). This is exactly the extra behavioral context the bar rewards.

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 identity and ranking criteria, then provenance, then pricing, then error handling. Dense but every sentence carries distinct information; slightly packed for a single paragraph but no wasted 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?

An output schema exists, so return-value explanation is unnecessary, and the description fills the remaining gaps an agent needs: cost/quota, failure semantics, data freshness, and the source of the ranking. Nothing required for 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% for the single 'limit' parameter, including default and 1-25 range, so the schema already carries full semantics. The description adds nothing about the parameter, which is the correct baseline 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?

States a specific verb+resource (Meteora DLMM liquidity providers) and spells out the ranking dimensions (net USD, median multiple, win rate, hold time, size, recency). An agent can distinguish it from dlmm_pool, dlmm_positions, and smart_money purely from the description.

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?

Provides useful context ('these are the wallets our live copier watches') that implies a copy-trading/discovery use case, and pricing guidance is explicit. However, it never states when to pick this over siblings like smart_money or dlmm_positions, nor any exclusions. Usage is implied rather than directed.

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 readOnly/idempotent/openWorld, so the bar is low, yet the description adds substantial non-annotated behavior: $0.025 per call, 10 free/day, x402 payment-required result, and isError semantics with an explicit note that failures are not charged.

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 verdict and return contents, then usage, price and errors in distinct labeled clauses. Dense with parenthetical asides ('callable here by name' twice), but nearly every sentence carries actionable information.

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

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

For a single-parameter, fully documented, output-schema-backed tool, the description covers composition, cost, and error handling. An agent has everything needed to decide to call it and to interpret failures.

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% for the single mint parameter, including base58 pattern and length. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

Names a specific verb and resource ('one-call verdict on a pump.fun launch') and enumerates exactly what comes back: 0-100 score, positives/risks, graduation odds, dev record, snipers, holders, flow. It also distinguishes itself from the constituent tools by stating it bundles pump_token + pump_dev + pump_odds.

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?

An explicit 'When to use' clause positions it as the one-call verdict, and it states the alternative path explicitly: cheaper than calling pump_token, pump_dev and pump_odds separately. Both the condition to select it 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 read-only/idempotent/non-destructive, and the description adds real behavioral depth beyond them: the $1,000 liquidity floor, why dead-curve round-trip quotes are misleading, and that upstream failures return isError without being charged. That is exactly the kind of context annotations 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-loaded with the core capability, then rationale, routing, and cost/error notes in descending priority. Slightly dense in the middle sentence, but each clause (liquidity floor, dead-flag rationale) carries information an agent needs.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Input bounds, routing to the alternative, cost, and failure semantics are all present, leaving no gap for a single-parameter read 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?

With one parameter at 100% schema coverage, the schema already documents the base58 mint list and the 1-100 bound; the description's 'up to 100 Solana mints' is essentially a restatement. It adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The first sentence names the resource (Solana mints), the returned fields (USD price, 24h change, liquidity), the batch limit (up to 100), and a distinctive behavior (illiquid/dead flagging). It also explicitly distinguishes itself from the named alternative crypto_price by input type (address vs symbol). An agent can tell what this does without opening the 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 'When to use' clause gives a concrete routing rule: Solana mints by address here, majors/other chains by symbol via crypto_price. It also states cost ('Price: free') and error behavior ('returns isError ... not charged'), covering when-not-to-expect-success.

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 establish read-only, idempotent, non-destructive behavior, and the description layers on genuinely new operational context: $0.01 per call, 10 free/day, x402 payment-required results, and isError behavior for invalid input or upstream failure without charging. This is exactly the kind of detail structured fields cannot express.

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 front-loaded sentences: what it returns, then scope, then usage, then cost and error behavior. No filler, though the metric enumeration and pricing/error tail make it longer than strictly minimal.

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 an output schema present, the description need not explain return values, yet it still names the metrics and coverage window, and it covers pricing, error semantics, and sibling routing. Nothing an agent needs to select or invoke this tool correctly is missing.

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

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

Schema coverage is 100% and the single parameter is fully documented there, so the baseline is 3. The description adds real disambiguation by specifying the parameter must be the dev wallet rather than the mint address, which the schema's pattern alone cannot convey.

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 — a creator wallet's launch history — and enumerates the exact outputs (launches, graduation rate, cadence, sell speed, verdict). This is clearly distinct from siblings like pump_wallet, token_risk, or launch_scan.

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 'When to use' block tells the agent to pass the dev wallet, not the mint, and names a sibling (pump_token) that surfaces the dev of a mint. It also states the scope of coverage (since recording began, 15 most recent launches), so the agent knows when this tool is and is not the right fit.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes well beyond that with pricing ($0.002/call, 10 free/day, x402 options on payment-required results) and error behavior ('returns isError ... not charged') – non-obvious operational traits an agent 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?

Front-loads what the tool returns, then scopes usably with labeled 'When to use', 'Price', and 'Errors' sections. Dense but every clause carries information; only minor redundancy between the prose scope and the schema's limit cap.

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 discovery tool with an output schema, the description covers the important gaps: what aggregated data comes back, the cost/rate-limit model, and error semantics. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so limit and window_s are already fully documented with ranges and defaults. The description echoes the 'up to 50' cap and mentions the aggregated window but adds no syntax or interpretation beyond the schema, matching the baseline-3 case.

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 newest pump.fun tokens') plus the exact payload it returns (dev buy, early buyers/volume, curve progress, market cap, creator launch count). The 'up to 50 of the most recent launches' scope and the named sibling launch_scan clearly distinguish it from the other pump_* 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?

Explicit routing: 'When to use: To discover new mints; then use launch_scan for a verdict on one of them.' It names the alternative and the condition that selects it, 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?

With annotations already covering read-only, open-world, idempotent, and non-destructive behavior, the description adds meaningful context beyond annotations: it discloses the data source ('our own live recording of every pump.fun bonding-curve trade'), the cost ('Price: free'), and error behavior ('returns isError... not charged').

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 core metrics and data source, then usage, price, and errors. It is slightly longer than necessary because the 'Use it to decide...' sentence overlaps with the following 'When to use' sentence, but no sentence is purely wasteful.

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 no-parameter, read-only tool with an output schema and rich annotations, the description is complete: it explains the metric window, data provenance, use case, alternative tool, cost, and error handling. Return-value structure is appropriately left to the output schema.

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

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

The tool takes no parameters, so parameter semantics are not applicable; the baseline of 4 applies. The description does not need to explain parameters because the schema is empty and fully documented.

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 (pump.fun market pulse) and enumerates the exact metrics returned: trades/min, launches, graduations, graduation rate, and hottest tokens over a 15-minute window. It also distinguishes itself from alternatives by naming pump_history for longer-term trends.

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: 'Use it to decide whether the launch market is hot or dead before scanning individual tokens' and 'When to use: For the market right now; for trends over days use pump_history.' The alternative and its selection condition 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?

Annotations already declare readOnly/idempotent/openWorld, and the description adds substantive extras beyond them: the 20k trade analysis cap, pricing ($0.01/call, 10 free/day, x402 payment-required result), and error behavior (isError on invalid input or upstream failure, not charged). This is exactly the value-add 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-loaded with the payoff, then usage, alternatives, price, and errors in compact sentences. Slightly dense with the pricing/payment aside, but every sentence carries actionable information for an agent deciding whether and how to 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?

An output schema exists, so return-value explanation is unnecessary. Purpose, scope, sibling routing, cost, and failure modes are all covered; nothing needed to invoke 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 wallet and limit are already documented with pattern, range, and default. The description restates the 20k cap but adds no format or semantic detail beyond the schema. Baseline 3 for a fully-covered two-param schema.

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

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

States a specific verb+resource ('Any wallet's pump.fun trading record') and enumerates the returned fields: realized PnL, win rate, hold time, frequency, launched tokens. It also bounds the scope ('up to the last 20,000 curve trades'), so an agent knows exactly what it gets.

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 'When to use' clause plus two named alternatives with their selecting conditions: counterparty_check for a quick deal/no-deal verdict, copy_backtest to test copy-trading. 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 declare readOnly/idempotent/non-destructive, but the description goes well beyond by disclosing the $0.02-per-call price, the 10 free/day quota, the x402 payment-required path, the 30-minute rebuild cadence, and that invalid input or upstream failures return isError uncharged. It does not, however, describe the freshness/latency of the live feed beyond the window parameter. Strong behavioral disclosure.

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

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

The core output is front-loaded in the first sentence before the sortable/feed details, and the when-to-use, price, and error clauses are ordered usefully. It is dense and multi-clause, but nearly every clause adds a distinct fact rather than 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 an output schema present, return values need not be re-explained, and the description still covers pricing, quota, error behavior, refresh cadence, ranking basis, and the natural follow-up tool. 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 adds meaning by tying window_min to the buying_now feed ('last N minutes'), limit to the leaderboard ('top 50'), and sort to PnL/win-rate/ROI. It clarifies which param drives which half of the response, which the schema alone does not.

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 precise verb+resource (a wallet leaderboard ranked by realized PnL plus a live buying feed) and immediately scopes it: 'fully-closed curve positions (min 8 closed, rebuilt every 30 min)'. It is clearly distinguishable from siblings like pump_wallet and copy_backtest.

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 when-to-use ('To find wallets worth watching') and routes the agent to the next step with a named alternative ('then copy_backtest to test copying one'). Nothing about tool selection is left 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, openWorld, non-destructive, so the safety profile is covered. The description adds genuinely new context: data provenance (mainnet RPC performance samples, epoch info, prioritization fees), cost (free), and error behavior (isError returned for invalid input or upstream failure, not charged). That is meaningful beyond the annotations, though it says nothing about caching/staleness of 'right now'.

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 ('Solana right now') followed by the return payload, then usage, cost, and errors in a compact run of clauses. Dense but every clause carries information; the semicolon-chained list is slightly harder to scan than separate sentences.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Combined with the description's coverage of source, cost, and failure modes, an agent has everything needed to call this zero-arg 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing further for the description to disambiguate about inputs.

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

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

States a specific resource (Solana network status) and enumerates exactly what it returns: TPS total and non-vote, slot/block height, epoch progress and ETA, priority-fee percentiles, cluster version. It also names the sibling it is not (gas_now for EVM/BTC fees), so an agent can distinguish it 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?

Explicit 'When to use' clause scoped to Solana fees/TPS, with the alternative (gas_now) named by tool name for the EVM/BTC case. This is textbook routing guidance with no inference required.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well beyond them: it names the live data sources (on-chain contract state, largest accounts, DexScreener), the curve-liquidity semantics and the `curve` field, the merged pump.fun forensics, the $0.005/call cost with 10 free/day and x402 payment-required results, and the error contract (isError on invalid input or upstream failure, not charged). That is exactly the beyond-annotations context an agent 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?

The core purpose, data sources, usage rule, pricing and error behavior are all front-loaded and every sentence carries distinct information. It is dense rather than bloated, though the long em-dash inventory of risk dimensions and the parenthetical data-source list could be trimmed slightly 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?

For a read-only scoring tool with a full output schema (so return values need not be re-explained), the description covers what is scored, where the data comes from, how bonding-curve liquidity is interpreted, sibling routing, cost, and error semantics. 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?

There is a single parameter and schema description coverage is 100%, so the schema already fully documents `mint` including its Base58 pattern. The description adds no per-parameter syntax or format detail beyond that, so the baseline 3 applies.

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

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

The opening clause states exactly what the tool returns ('0-100 rug-risk score') and the resource scope ('any Solana token'), then enumerates the concrete risk dimensions (mint/freeze authority, Token-2022 traps, holder concentration, liquidity depth, pump.fun curve flags). It explicitly distinguishes itself from pump_token and evm_token_security by name, so an agent can route 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 'When to use' sentence gives an explicit inclusion rule ('For any Solana token, pump.fun or not') plus two named alternatives with their selecting conditions (pump_token for curve-stage detail, evm_token_security for EVM tokens). Nothing about tool selection is left 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, so the safety profile is covered; the description adds non-obvious behavior beyond them: per-call price ($0.003), a free tier (10/day), an x402 payment-required result after the quota, and that errors return isError and are not charged. That is precisely the context annotations cannot express.

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

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

Front-loaded with the core capability, then labeled 'When to use', 'Price', and 'Errors' segments — every sentence carries information. It is slightly dense with commercial detail, and the parenthetical 'callable here by name' is mildly noisy, but there is no true 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?

An output schema exists, so return structure needn't be re-explained; the description still sketches the payload at a useful level (status, fee, named programs, balance deltas, summary). Combined with pricing, quota, and error semantics, an agent has everything needed to call it correctly and anticipate the outcome.

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

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

There is a single parameter with 100% schema description coverage (base58, 64-90 chars, regex pattern). The description adds no format or syntax detail beyond the schema, so the baseline of 3 applies — the schema does all the work here.

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

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

States a specific verb+resource ('turns any Solana transaction signature into plain facts') and enumerates exactly what is produced: status, fee, named programs, per-owner SOL/token balance changes, summary. It also explicitly names the non-Solana case (0x hashes → evm_tx), so an agent can separate it from other sibling lookup tools without opening the 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?

Provides an explicit routing rule: 'For Solana signatures; for 0x hashes use evm_tx'. It also covers the failure path (works for failed transactions, includes error log lines), leaving no ambiguity about when this tool applies versus an EVM equivalent.

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, so the safety profile is covered. The description adds genuinely extra context: pricing ($0.003, 10 free/day, x402 payment-required result), the error contract (isError for invalid input or upstream failure, not charged), dual token-program reads, and empty accounts counted as reclaimable rent.

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 value proposition, then usage, pricing and errors in a compact sequence. Dense but every clause carries useful information; only slightly long for a one-parameter tool.

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?

An output schema exists, so return format need not be explained. Given that, the description covers domain scope, alternative routing, cost model, and error semantics — everything an agent needs 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?

Only one parameter with 100% schema coverage (pattern and Base58 format fully documented in the schema). The description adds no parameter-level detail beyond the schema, so the 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+resource+scope: 'Everything a Solana wallet holds — SOL, SPL and Token-2022 tokens — valued in USD and sorted by value.' It names the sibling alternative (evm_address) and its domain constraint, so an agent can distinguish it from the many other wallet/address tools in the sibling list.

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

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

Explicit 'When to use' section: Solana wallets here, EVM wallets via evm_address. Nothing is left to inference, and it even explains that evm_address is callable by name.

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