BotSharper

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds value by enumerating the specific metrics and the population-size component, but says nothing about return format, aggregation period, or sourcing.

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

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

A single, dense sentence with no filler, and the key content (the five quintiles) is front-loaded. It is slightly jargon-heavy ('measured operators', 'multiple') but not verbose.

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-value burden; it names the metrics but not the shape (per-quintile records? aggregate totals?), so the agent knows the topic but not the structure. For a parameterless read-only tool this is adequate but not complete.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level value could be added or omitted here.

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

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

The description is a specific noun phrase naming the metrics returned (quintile shares of wins/losses, multiple, population size), so an agent can infer it returns benchmark statistics. However, it lacks an explicit verb ('returns'/'computes') and gives no hint of what distinguishes it from sibling data-report tools like botsharper_token_sheet or botsharper_pump_weather.

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

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

There is no statement of when to use this tool, when not to, or which sibling to prefer for related queries. The agent must infer from the noun phrase alone that this is the benchmarking/reference-data endpoint.

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=false, so the safety profile is covered. The description still adds real behavior beyond that: hourly refresh cadence, a fixed 7-day evidence window, and an explicit 'facts, not advice' disclaimer. It stops short of detail on rate limits or response shape.

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

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

Dense but front-loaded: the primary classification comes first, then the secondary 'launch team' signal, then usage, then freshness caveat and disclaimer. Every clause carries information, though the opening 'Protection filter for trading bots' is slightly redundant framing.

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

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

There is no output schema, so the description must convey what comes back; it does list the derived facts (serial-creator status, dump frequency, migration count, launch-team behavior) and states the data window and refresh rate. It omits the exact response shape/field names, which is a minor gap for a no-output-schema 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 description coverage is 100% and the schema already documents the single address parameter as a base58 public Solana address for a creator or wallet. The description's mention that the address can be a creator or a wallet mirrors the schema rather than adding new 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 ('tells whether a Solana address is a serial pump.fun creator ... and/or a wallet that repeatedly buys in the launch block'), with concrete qualifying criteria (3+ launches in 7 days, dumps within 5 minutes, migration counts). It is clearly a static-lookup protection filter, distinguishable from the sibling simulation/testing tools (botsharper_simulate_bot, botsharper_test_my_bot).

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 usage context: 'Check a token's creator before buying.' That tells the agent exactly when to reach for it, but it names no alternative tool or when-not-to-use condition relative to siblings like botsharper_jeton or botsharper_reperes.

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 behavior, and the description adds valuable context: data is refreshed hourly and the metrics are retrospective ('Past facts, not a forecast'). It doesn't state rate limits, caching, or latency, but for a read-only aggregate tool this is strong.

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 definition with a specific refresh cadence, then lists metrics compactly, then gives the usage clause last. It's dense but each clause carries information; it could be split for readability but nothing is waste.

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

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

For a zero-parameter read-only tool with no output schema, the description fully covers what the agent will receive and when to call it. The only missing piece is any note on freshness guarantees beyond 'hourly' or failure modes, which is minor.

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 are zero parameters, so baseline is 4. No parameter semantics are needed; the description instead spends its space describing the return content.

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 (pump.fun weather) and enumerates exactly what it returns: launches/hour, pre-prepared share, dumping share, migrations, winning positions, entry-speed profitability, serial teams. It's clearly distinguishable from siblings like simulate_bot or check_wallet, which concern a bot or a wallet rather than market state.

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: 'before tuning a bot' and 'when someone asks what is happening on pump.fun now.' It also clarifies the boundary 'Past facts, not a forecast,' which tells the agent this is retrospective data, not predictive.

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), so the bar is lower, and the description still adds substantial behavior: fees, priority fee and price impact are included, fills are pessimistic, and the simulation is normalized to 3 SOL capital at 0.1 SOL per trade and 30 trades/day. It also explicitly disclaims 'past data, not a forecast, not advice.' It omits runtime/latency and data-window specifics, keeping it out of 5 territory.

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 content is front-loaded and ends with a clear usage clause, but the opening sentence is a ~110-word run-on covering mechanics, assumptions and return fields at once. It is information-dense rather than wasteful, yet it would be far more scannable split into short lines.

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

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

There is no output schema, and the description compensates by enumerating the return values: median final balance, share of replays that ran out of SOL and after how many days, per-trade results, share of winning trades, the median real result of comparable bots, and a chart link. Combined with stated fixed assumptions and the explicit non-forecast disclaimer, an agent has everything needed to call it and set expectations.

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%, with each parameter fully documented with defaults and grids, so the baseline is 3. The description only echoes parameter families ('entry delay, take profit, stop loss, holding time, filters') without adding syntax, ranges, or trade-off guidance beyond what the schema already provides.

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

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

States a specific verb and resource — 'Simulate / backtest a pump.fun sniper or trading bot' — and immediately scopes it as a pre-deployment risk check. An agent can separate it from siblings like botsharper_test_my_bot or botsharper_check_wallet 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?

Gives an explicit trigger: 'Use it when someone asks whether a bot strategy or settings (entry delay, take profit, stop loss, holding time, filters) would make money.' It also frames the tool as pre-risk evaluation, but it does not name a sibling alternative (e.g. test_my_bot) or state when NOT to use it, 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 description correctly spends its budget on methodology: up-to-60-day window, fees included, unsold tokens valued at min(cost, market), and a past-facts-only framing. It does not say what happens for wallets with insufficient history, 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?

The action and resource are front-loaded, and the output enumeration is justified because there is no output schema. The middle sentence is dense with a long comma-separated list, but each element (period cap, fee handling, valuation rule) carries real decision value.

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 properly compensates by enumerating return metrics and the valuation methodology an agent would otherwise have to guess at. Minor gap: no statement about failure modes, empty history, or latency/cost of the analysis.

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

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

Schema description coverage is 100% and the single parameter is fully documented as a base58 public Solana wallet address the bot trades from. The description restates essentially the same thing ("the bot's public wallet address"), adding no format or validation detail beyond the schema, 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?

Opens with a specific verb set (test/improve/debug) and a concrete resource (Solana trading bot on pump.fun, PumpSwap, sniper, copy-trading), then enumerates the actual return values. It does not explicitly name a sibling like botsharper_simulate_bot or botsharper_wallet_report to disambiguate, so it stops short of a 5.

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

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

"Use it whenever someone asks how to improve, tune, evaluate or benchmark their crypto trading bot" gives a clear triggering condition, and "Past facts only, not advice" sets a scope boundary. It does not say when NOT to use it or which sibling to pick instead (e.g. simulate_bot for hypothetical runs).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context: the data is 'updated hourly' and contains 'past facts only' with 'no forecast, no advice.' It does not contradict the annotations and fills in freshness and scope information not present in 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 description is compact and front-loads the core purpose ('Token sheet for a pump.fun token') before listing the detailed metrics. The list of metrics is dense but justified by the absence of an output schema. The final caution sentence is brief and useful.

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?

Without an output schema, the description serves as the primary guide to what the tool returns, and it enumerates the key dimensions (buyer counts by time window, creator activity, top-buyer share, migration, volume, wallet-report participation). For a read-only, single-parameter tool this is largely complete, though it does not describe response format or 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?

There is a single required parameter 'token' with 100% schema description coverage ('Solana token (mint) address, base58'). The description mentions 'mint address' but adds no syntactic or format details beyond what the schema already provides. With full schema coverage, 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?

The description clearly states it returns a 'Token sheet for a pump.fun token (mint address) observed by BotSharper' and then enumerates the specific metrics included (launch time, buyer counts, creator activity, migration, volume, wallet-report participation). This is a specific resource with a clear scope, though it does not explicitly name sibling alternatives or use a leading verb like 'retrieve'.

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 closing sentence 'Past facts only, updated hourly: no forecast, no advice' implies when this tool is appropriate (retrieving observed historical token facts) and implicitly excludes predictive use. However, it does not explicitly compare to any sibling tool or state prerequisites or exclusions beyond that single line.

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 new context beyond annotations: the exact contents of the returned report and the explicit statement that results are historical facts with no forecasting or advisory component. It does not say what happens for an address that is not among the measured operators.

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

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

Two compact sentences: the payload comes first, the scope disclaimer second. The metric enumeration is dense but every item corresponds to actual returned data, so nothing is wasted.

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

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

With no output schema, listing the metrics is necessary and done well, and annotations cover safety. However, the description leaves open the overlap with botsharper_check_wallet and says nothing about behavior for addresses outside the measured population or about error/empty results, which matters for a single-address lookup tool.

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

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

Schema description coverage is 100% for the single 'address' parameter, so the schema already carries the base58 format detail. The description adds only the qualifier 'public' Solana address, which is marginal. Baseline 3 is appropriate 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 resource (a wallet's ranking among pump.fun operators) and enumerates exactly what the report contains: percentile, quintile, closed positions, win share, average multiple, loss share, quintile benchmarks. It is clear what the tool produces, but it never distinguishes itself from the sibling botsharper_check_wallet, which an agent could easily confuse with it.

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 clause 'Past facts only: no forecast, no advice' implies the boundary against predictive/advice-style siblings such as botsharper_simulate_bot, but it is an implied scope note rather than explicit when-to-use guidance. No alternative is named, and nothing says when to prefer check_wallet over this report.

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