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

Annotations only declare destructiveHint and openWorldHint; the description adds genuinely new behavior: funds come from this server's wallet, the trade is simulated and only sent if it would succeed, and it is capped by PUMP_MAX_SOL_PER_TRADE. It still leaves open what a partial fill or a slippage breach does, so not 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?

Three tight sentences, each carrying distinct weight: what it does, the human-confirmation safety gate, and the simulate-then-send plus cap mechanics. The money warning is placed up front where it matters.

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 real-money mutation with no output schema, the description covers safety, execution path, and the spend cap well, but omits slippage semantics and what the agent gets back (fill amount, tx signature, failure detail) – meaningful gaps for a trade 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 0% and the description does not define any of the three parameters. mint and sol are loosely implied by 'buy a coin with SOL' and 'confirm the coin and the amount', but slippage_pct (0.5-50 range, presumably a percentage) is never mentioned or defaulted.

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 (buy a pump.fun coin with SOL) plus the wallet source and the two venues (bonding curve vs. its DEX pool after graduation). The direction of the trade makes it trivially distinguishable from the pump_sell sibling.

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 precondition: confirm the coin and amount with the user because it is REAL MONEY. It does not explicitly name pump_sell as the opposite action or say when NOT to use it, but the context for when to call 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 destructiveHint=true and openWorldHint=true, so the risky, external-facing nature is signposted; the description adds which wallet is credited and that only self-launched coins count. It still does not say this submits an on-chain transaction (gas cost, signer requirement), nor what happens when nothing is claimable or what is returned.

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

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

A single front-loaded sentence with the verb, resource, and scoping qualifier in one pass; nothing redundant, nothing padded.

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 tool with annotation coverage and no output schema, the description is nearly sufficient. The one remaining gap an agent would want is whether calling it actually broadcasts a transaction and how the claimed amount is reported 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the schema shows. Baseline 4 applies for a parameterless tool.

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?

Specific verb (claim) plus specific resource (pump.fun creator fees), with scope narrowed to fees owed to this server's wallet for coins it launched. No sibling tool (buy/sell/launch/status) overlaps with claiming accrued creator fees, so an agent can route here 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?

Usage is only implied: an agent infers it should call this when fees are owed, but nothing says whether there is a minimum threshold, how often it can be called, or what to do if no fees are available. No alternatives or exclusions 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?

The readOnlyHint already covers safety, but the description adds real behavioral context beyond it: results adapt to lifecycle stage (bonding curve vs. graduated DEX pair) and live activity is only present 'if it launched while this server was watching.' That caveat is exactly the kind of limitation an agent cannot infer from annotations or 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?

One front-loaded sentence naming the resource and key, followed by a compact list of returned data. It is long but every clause maps to a distinct output field or caveat, so it earns its length; a lighter split into two sentences would read better.

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, so the field inventory (metadata, price/market cap, curve or DEX pair, volume, holder concentration, dev wallet/holding) carries the return-value burden and does so well, including the watching-server caveat. Only minor gaps, such as behavior for an unknown or graduated mint, remain.

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 already documents 'the coin's mint address (CA).' The description repeats the same concept in the same words without adding format or validation detail, so the baseline of 3 applies.

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

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

States a specific resource (a single pump.fun coin) and the keying dimension (mint address / CA), and the enumeration of returned fields makes the scope unmistakable. It does not explicitly name a sibling to contrast with, so it falls just short of the top mark.

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

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

Usage is only implied: 'by its mint address' signals this is the lookup-by-CA path, which indirectly separates it from pump_search and pump_new_launches. There is no explicit when-to-use or when-not-to-use statement, nor any prerequisite noted.

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?

readOnlyHint=true already covers the safety profile. The description adds useful context that results come from *recent* on-chain history (so the list is partial) and enumerates the outcome states, but it omits what happens when neither wallet nor mint is supplied, despite zero required parameters.

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 tight sentences; the resource and its status categories are front-loaded and the argument modes follow. No filler, though the argument sentence is slightly elliptical ("or a coin's mint") about mutual exclusivity.

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 the right work by describing the return contents (launched coins and their current lifecycle state). For a read-only 3-param tool this is nearly sufficient; only dual-argument behavior and result size/limits are unaddressed.

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

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

Schema coverage is only 33% (only `scan` is documented), so the description must carry the rest. It does explain the meaning of `wallet` and `mint` at a high level and that `scan` bounds the lookup, but gives no exclusivity rule, format hints (address format), or guidance on choosing a scan depth.

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 (coins a wallet launched on pump.fun) plus the returned dimension (graduated / on the curve / dead), which tells an agent exactly what it gets. It doesn't name or contrast any sibling (pump_wallet, pump_coin), 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?

"Pass a wallet, or a coin's mint" gives two concrete invocation modes and their intents (list a wallet's launches vs. check a specific coin's dev). It doesn't say when to prefer pump_wallet or pump_coin instead, and doesn't state whether both args may be supplied together.

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 flag openWorldHint and destructiveHint, and the description adds real value on top: it is public, spends REAL MONEY, requires a PINATA_JWT environment variable, and performs an implicit dev buy. It stops short of saying how much SOL the dev buy costs or what happens if the launch fails midway.

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 with the action first and the risk warning second; no filler, and the most decision-relevant facts (real money, public, confirm with user) are front-loaded.

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

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

Given a destructive, money-spending, open-world tool with no output schema and 87% of params undocumented, the description is adequate on risk but incomplete on mechanics: it never says what the tool returns (e.g. the new mint address) or what the social/optional params do.

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 only 13% — just the image param is documented — so the description must compensate and largely doesn't. It gestures at image/metadata and the dev buy, but says nothing about symbol/name length limits, the social fields, or the default 0 SOL dev_buy_sol and its cost implication.

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?

Specific verb+resource ("Launch a new coin on pump.fun from this server's wallet") with the full pipeline spelled out: IPFS upload, coin creation, dev buy. It clearly separates itself from siblings like pump_buy or pump_coin by describing an end-to-end launch.

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?

States the operating context and a hard precondition ("needs PINATA_JWT") plus an explicit procedure ("confirm every field with the user first"). It doesn't name sibling alternatives (e.g. use pump_buy for buys after launch), but the when-to-use signal 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?

The readOnlyHint annotation covers the safety profile, and the description still adds real behavior: data comes live from the chain, is bounded to the server's watch window, and 'hot' is defined precisely as net SOL inflow from buyers other than the dev over the last 5 minutes. It does not disclose pagination or result-size behavior, so it falls 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?

The returned fields are front-loaded and the sort modes come last, which is the right priority order. The first sentence is long and dense, but nearly every clause maps to a field the caller will otherwise have to guess at.

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 spends its budget describing what comes back, down to dev holding, dev-sold status, and bundle buys in the launch block. It is only incomplete on the two filtering/paging parameters the schema leaves bare.

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

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

Schema description coverage is 0%, so the description must carry the load. It defines the sort enum values well, including the non-obvious 'hot' metric, and the mention of 'whether the dev sold' hints at hide_dev_sold. But limit and min_mcap_usd are never explained, leaving half of the parameters undocumented.

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 (coins launched on pump.fun) and a precise scope (since this server started watching, live from the chain), and enumerates the metrics returned. It never names a sibling tool, so an agent must infer on its own that pump_search or pump_coin answer different questions, which keeps this out of 5 territory.

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

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

Usage is only implied: the phrase 'since this server started watching' quietly tells the agent this is a live feed, not a historical archive, which matters for deciding between it and pump_search. There is no explicit when-to-use, when-not-to-use, or alternative 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 cover the safety profile (readOnlyHint=true), and the description adds real context beyond that: results are ranked by liquidity, and it discloses the returned fields (market cap, volume, age) plus the upstream data source. It doesn't mention result limits or what happens on no-match, but the added value is solid.

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 tight sentences with zero waste; identity and input forms come first, return semantics second. Nothing is repeated from structured fields.

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 fills in the return shape (liquid-ranked matches with market cap, volume, age). What's missing is minor: result count limits and behavior when nothing matches.

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 0% and the single 'query' parameter is undocumented in the schema, so the description carries the burden — it does so by specifying that the query may be a name, ticker, or address. That is concrete and directly useful, though no format examples (e.g. mint address format) are given.

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 ('Search Solana coins') and the accepted identifier forms, plus the backing source (DexScreener). It is distinguishable from detail-oriented siblings like pump_coin, though it never names that distinction explicitly.

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 word 'Search' plus the name/ticker/address hint implies when this tool applies, but there is no explicit guidance on when to prefer it over pump_coin or pump_new_launches. Usage is inferable rather than stated.

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

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

Annotations already flag destructiveHint and openWorldHint, yet the description adds the crucial facts an agent needs: it spends real funds from the server's wallet, requires user confirmation, and is simulated before being sent. That is meaningful context beyond the 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?

Three short sentences, front-loaded with purpose, then parameter format, then the money-safety warning. No filler; the most consequential warning is placed prominently.

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 real-money mutation with no output schema and zero schema coverage, the description covers safety and the amount parameter but omits what mint should contain (an address vs a symbol) and what slippage_pct does. An agent could still call it, but with avoidable ambiguity.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains the amount format well with concrete examples ("100%", "50%", "250000"), but leaves mint and slippage_pct entirely unexplained, including the 0.5–50 bounds and default of 100% for amount.

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 (sell) and resource (a coin), and scopes it to this server's wallet, which cleanly separates it from the sibling pump_buy. An agent can tell what it 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?

Provides a clear precondition — confirm with the user before executing because it involves real money — and notes it is simulated before sending. It does not mention when to prefer this over related siblings such as pump_coin or pump_wallet, but the operational guidance is concrete.

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?

readOnlyHint=true already tells the agent this is a non-mutating read, so the safety profile is covered. The description adds the informational surface (feed, RPC, wallet, trading state, limits) but says nothing about auth requirements, whether values are live or cached, or the shape of the response. Useful but not deep.

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 short sentence with zero filler, and the highest-value item ('whether trading is on and its limits') is placed at the end where it still lands. It is a verbless fragment, which slightly hurts scannability, but 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?

There is no output schema, so the description carries the burden of describing return values, and it does enumerate the five things returned. The enumeration is a bit terse ('the RPC' — a URL? a health status?), leaving some ambiguity for a tool whose only output is that data.

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, which is the baseline-4 case, and the description correctly presents the tool as parameter-free by framing it as a server-wide read. Nothing about parameters needs explaining.

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 resource (this server's configuration) and enumerates the specific facets reported: feed, RPC, wallet, trading enabled state, and limits. An agent can distinguish it from the action-oriented siblings (pump_buy, pump_sell, pump_launch) which are all mutations. It lacks an explicit verb ('returns'/'reports'), so it reads as a list of fields rather than a stated operation.

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

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

There is no explicit when-to-use or when-not statement. However, the mention of 'whether trading is on and its limits' strongly implies the natural use case of verifying trading availability before calling pump_buy or pump_sell. That inference is reasonable but left to the agent.

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, so the safety profile is covered. The description adds genuine context beyond that: holdings are valued using either curve price or DEX price depending on the token, and omitting the address resolves to the server's own trading wallet — a non-obvious default an agent must know.

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

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

Two short sentences, front-loaded with the return value and followed by the default behavior. The second sentence is a fragment, but it is tight and wastes no words.

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-optional-parameter read tool with no output schema, this covers what the tool returns, how values are priced, and what happens with no input. Return shape is unspecified, but with no output schema that is a minor gap rather than a blocking one.

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 0%, so the description must carry the address parameter, and it does: the address is optional and its absence means 'the wallet this server trades with'. That is exactly the semantic an agent needs and cannot get from the bare 'address: string' property.

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 the resource (a wallet) and exactly what is returned: SOL balance plus token holdings with their valuation (curve price or DEX price). This clearly separates it from coin-centric siblings like pump_coin or pump_new_launches, though it never names a sibling to route against.

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

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

Usage is implied by the resource — an agent would infer this is the tool for inspecting a wallet's holdings. The no-address default is explained, but there is no explicit 'use this when' framing and no statement of when a different sibling (e.g. pump_coin for a single token) would be the better choice.

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