A.U.G.U.R Foresight · Bundle Forensics

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: per-call price with free-tier and x402 payment-required behavior, error semantics (isError, not charged on upstream failure), and the critical caveat that "ok:true" means no red flags found, not that the coin is safe. Back-tested skip rules and their held-out performance give the agent concrete behavioral grounding.

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 "Who bundled a Solana pump.fun launch" and every subsequent clause (skip rules, extra flags, ok:true caveat, when-to-use, price, errors) carries substantive information. It is dense and long, but not padded; the density is the only knock.

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, yet the description still supplies the one semantic detail that matters most for interpreting it ("ok:true" ≠ safe) along with cost and error behavior. For a single-parameter, read-only forensic tool, an agent has everything needed to call and interpret 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% and the only parameter is fully documented as a Base58 mint. The description adds genuine meaning beyond the schema by noting pump.fun launches get the full bundle view, implying non-pump.fun mints yield partial results — a behavioral nuance the schema does not carry.

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: labelling every block-0 wallet of a Solana pump.fun launch as sniper bot / bundle / dev-linked, plus concentration and a skip/pass verdict. It is clearly distinct in scope, but it does not explicitly differentiate itself from the listed siblings (bundler_profile, creator_launches, evm_bundle_forensics) — it only redirects to non-sibling launch_scan for a scored verdict.

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" sentence names the triggering condition (see who bundled a launch and get the skip/pass rug guard) and names the alternative (launch_scan on the A.U.G.U.R Foresight server) for the scored-verdict use case, complete with URL. Pricing and error conditions are also spelled out so the agent knows the cost/retry posture.

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, so the description's added value is cost and data provenance: $0.002 per call with 10 free/day and an x402 payment-required result, plus that errors return isError and are not charged, and the underlying 10-day block-0 registry window. Missing rate limits or latency expectations, but the pricing and error-charging semantics are genuinely useful context beyond 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?

The lead question and the kind taxonomy are front-loaded well, and the pricing/error sentences earn their place. There is some redundancy: 'Use it on wallets bundle_forensics lists' is repeated almost verbatim later in 'When to use: To check one wallet from bundle_forensics'.

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, yet the description still defines the four classification labels and their thresholds, which is key interpretation context. Data source, cost model, error behavior, and routing to alternatives are all covered.

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

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

Schema coverage is 100% and both parameters (wallet base58 address, limit 1-100 default 25) are fully documented in the schema. The description adds no additional parameter guidance such as what limit controls in the result set, 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?

Opens with a specific question about a specific resource ('Is this Solana wallet a bundler?') and then enumerates exactly what the profile contains: block-0 buys over 10 days, creators bundled for, and bot-vs-dev-wallet classification. This is clearly distinguishable from sibling bundle_forensics (which lists wallets) and creator_launches.

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

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

Explicitly says to use it on wallets returned by bundle_forensics or any wallet about to be copied, and names the alternative pump_wallet for trading performance, including that it lives on a different server. Both when-to-use and when-to-use-something-else are stated.

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

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

Annotations cover safety (readOnly, idempotent, non-destructive), so the description adds genuinely new behaviour: $0.002 per call with 10 free daily, a payment-required result carrying x402 options after the quota, and isError with a message (uncharged) for invalid input or upstream failure. It also explains what a repeat block-0 wallet means, which is interpretation an agent needs to read the output.

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 first sentence front-loads the payload and the operational details (when-to-use, price, errors) follow in a predictable order. The $-11% vs -5% economics recital earns its place as interpretation guidance but is longer than the agent strictly 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?

To call this correctly, the agent needs the data source, time window, parameters, cost, error handling, and what a bundle crew means. All of that is present, and the output schema exists so return values do not have to be described.

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 both `creator` (Base58, 32-44 chars) and `limit` (1-100, default 25) fully. The description adds no semantics beyond fixed facts like the 10-day window and never mentions limit, 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 states a specific verb and resource: every pump.fun coin a Solana wallet created, plus graduation counts and its repeat bundle crew. It also distinguishes itself from pump_dev, which handles graduation stats, so an agent can tell the two apart 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?

A dedicated 'When to use' clause gives the exact condition (a dev's launch count and repeat bundle crew) and names pump_dev for graduation stats. The exclusion is clear, but the three sibling tools on this server (bundle_forensics, bundler_profile, evm_bundle_forensics) are never mentioned, so the alternatives stay incomplete.

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 safety, yet the description adds a lot beyond them: full Transfer-log replay semantics, per-chain history budgets that change accuracy, launchpad/locker handling, fallback behavior for older tokens, pricing with free tier and x402 payment-required result, error/charging behavior, and an explicit 'pass is not a safety promise' caveat.

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 question and verdict, and every block (replay semantics, skip rules, routing, pricing, errors) carries real information. However it is one dense run-on paragraph where the skip-rule thresholds could be a list, which costs some scannability.

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; the description instead covers what an agent needs to call it correctly and interpret a verdict: accuracy limits by chain age, heuristic caveat, cost model, and failure mode.

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

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

Schema coverage is 100% and both params are documented with enum and address pattern, so the schema does the work. The description's chain list repeats what the enum already contains and adds no format or edge-case guidance beyond it – baseline 3.

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 question it answers ('Who bundled an EVM token launch') plus the evidence classes it returns (creation-tx airdrops, first-seconds buys, scripted cadence, dev/exchange holders, GoPlus flags) and a verdict. It is clearly distinct from the sibling contract-flags tool, which it names.

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

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

Explicitly says when to use it ('Bundles and who holds an EVM token launch, Base/BSC first-class') and routes contract-only questions to evm_token_security with its server URL. It also gives the concrete skip thresholds, so the agent knows what a 'skip' means.

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