three.ws pump.fun MCP

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: the on-chain source account (pump program bonding-curve account, not a PumpSwap pool), the field-renaming caveat, SOL denomination, and the v3 buy edge case where a final buy is not capped at realTokenReserves. This is exactly the kind of behavioral disclosure 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 core purpose, then progressively adds caveats. It is dense and the field-renaming paragraph borders on tangent for tool selection, but the content is mostly relevant and the sizing is defensible for a tool with tricky semantics.

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 described, and the description still supplies the interpretive context (reserve naming, denomination, graduation transition) an agent needs. Nothing essential to 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 0% (2 params, neither documented). The description never explains what 'mint' or 'network' mean or their expected format/values, so it fails to compensate for the coverage gap despite strong surrounding domain context.

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 ('bonding curve analysis: real reserves, virtual reserves, and graduation progress') and explicitly scopes it to pre-graduation coins. It also distinguishes itself from the pumpfun_quote_swap sibling, so an agent can tell them apart without opening a schema.

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

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

Explicit when-to-use ('read graduation progress or the curve spot price of a coin that has not graduated yet') and when-not-to-use ('once complete=true ... use pumpfun_quote_swap from that point on'). The alternative is named and the selecting condition is given.

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/openWorld/idempotent=false/destructive=false, so the bar is lower. The description adds genuine context beyond them: signals are scoped to an 'observation window', outcome labels only exist once a coin is 'old enough', and the data is time-varying (supporting the non-idempotent hint). It doesn't discuss auth, rate limits, or latency.

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 and the call-to-action are front-loaded, and the feature enumeration is dense rather than padded. It runs long and reads as a feature list, but each clause carries a distinct signal name an agent would want, so little 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 an output schema present, the description need not explain return values, yet it helpfully summarizes them. Combined with a clear usage trigger and mutation-free annotations, an agent has enough to call it correctly; only the undocumented network parameter and the absence of alternative-routing guidance leave a gap.

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

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

Schema coverage is only 50%: the mint parameter is documented in the schema but network (an enum with a default) is not. The description adds marginal meaning by narrowing the mint to a 'pump.fun mint', but says nothing about the network parameter, so it only partially compensates for the coverage gap.

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

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

The description states a specific verb+resource ('Full Coin Intelligence snapshot for a pump.fun mint') and enumerates exactly what the snapshot contains — bundle verdict, cluster connectivity, smart-money, dev behaviour, risk flags, quality score. An agent can distinguish this from generic siblings like get_token_details or get_bonding_curve 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?

It gives explicit decision context ('the single highest-signal read for a trade decision', 'Call this before entering any position'), which strongly signals when to reach for it. It does not, however, name alternatives or say when NOT to use it (e.g. versus get_oracle_conviction or get_token_details), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context by framing results as time-sensitive first-minutes launches, but says nothing about volatility, ordering, or how many items come back by default. Useful addition, not a rich 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?

Two short sentences, zero filler. The core purpose is front-loaded and the routing alternative follows immediately, which is the right order for an agent scanning for a 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?

For a read-only listing tool with annotations covering safety and no output schema, the definition supplies purpose, timing rationale, and sibling routing. Only the parameter behavior and result ordering are unaddressed, which is a minor gap at this complexity.

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 never mentions the limit parameter, its default of 10, or its 1-50 range. With one undocumented parameter, the description fails to compensate for the schema gap; it inherits none of the burden it should 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 resource and scope: 'most recently launched pump.fun tokens'. It also names the sibling it is not (get_trending_tokens), so an agent can distinguish 'newest launches' from 'largest by market cap' without opening either schema.

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

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

Gives an explicit when-to-use condition ('catch launches in their first minutes') plus the alternative tool and the condition that selects it ('for the largest coins by market cap call get_trending_tokens instead'). This is close to textbook routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral context: the four intelligence pillars (pedigree, structure, narrative, momentum), the tier thresholds, and the comprehensive return payload. It does not disclose potential rate limits or caching, but goes well beyond annotation basics.

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 moderately long but every sentence adds value: purpose, components, return details, usage guidance, and sibling pairing. It front-loads the core function and follows with specifics. It could be slightly tighter, but it is well-organized and free of 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?

Given an output schema exists, the description doesn't need to enumerate return fields, but it still details the tier ranges, pillar breakdown, trader roster, and narrative read. It covers complexity well and tells the agent exactly what to expect, making it complete enough for selection and invocation.

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 50%: mint is described, network is not. The description names the mint implicitly ('for a pump.fun mint') but does not explain the network parameter or its options. Since network has an enum and default, the schema carries some meaning, but the description does not compensate for the missing parameter description.

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 uses a specific verb—'get'—and resource—'pump.fun mint'—and clearly states the tool's output: a fused 0-100 conviction score, tier, per-pillar breakdown, reasons, roster, and narrative. It distinguishes from sibling get_coin_intel by positioning itself as a synthesis of raw signals into one actionable score.

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 states when to use: 'Call this when you need the highest-confidence trade signal.' It also provides an alternative/raw-signal counterpart: 'Pairs with get_coin_intel for raw signals,' implying when-not to use it (when you just need raw data). This meets the bar for explicit context.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds the categories of data returned (metadata, market cap, curve status), but says nothing about freshness, caching, rate limits, or failure behavior for an unknown mint. It adds context but is not rich beyond the annotation baseline.

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 sentences, no filler, and the core purpose is front-loaded ahead of the disambiguation clauses. Every clause earns its place by either defining scope or routing to a sibling.

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

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

For a one-parameter read tool with no output schema, the description covers both what the tool takes and what it returns at a category level, plus alternatives. Minor gap: it does not say what happens when the mint is unknown or whether results are cached/live, which an agent might need for a fresh-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?

There is a single parameter (mint) and schema description coverage is 0%, so the description carries the burden. It clarifies that the parameter is a token mint address rather than, say, a symbol or pair address, which is genuinely useful — but it gives no format, validation, or example (e.g. base58 length), so it only partially compensates.

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 (retrieve full details), a specific resource (a pump.fun token), and the lookup key (mint address). It also names the two sibling tools it must not be confused with, so an agent can distinguish it 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?

Explicitly states the precondition ("when you already have a mint") and what you get (metadata, market cap, curve status), then routes the agent away with two named alternatives: get_token_holders for holder concentration and get_token_trades for recent fills. When-to-use and when-not-to-use are both covered.

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, openWorld, non-destructive. The description adds that results are on-chain and include concentration analysis, which is useful context beyond annotations. However it doesn't disclose return shape, limit cap (schema shows max 20), or pagination/data freshness, so it's modest value over 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?

Two tight sentences: purpose first, then routing to the alternative. No filler; every clause 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?

Given annotations cover safety and the tool is a simple read with 1 required param, the description is nearly complete. Minor gaps: limit cap and network option are only in schema, and no output schema exists, but for a read tool of this simplicity that's acceptable.

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 compensate. It clarifies the 'mint' target (a token) and the nature of results (holders + concentration), and 'limit' is inferable as count of top holders from 'top holders'. Network/limit semantics are not fully spelled out, so not a 5.

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 (top holders of a token) with an added analysis dimension (concentration), and explicitly distinguishes from get_token_details (price/volume) by name. An agent can pick between them without opening either schema.

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

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

Gives an explicit use case (check concentration before buying) and names the sibling + condition for the alternative (price/volume → get_token_details). Explicit when-to-use and when-to-use-instead.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds only the implicit 'recent-only, not full history' framing; it says nothing about freshness, rate limits, pagination, or how far back 'recent' reaches.

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 sentences, zero waste: the scoping statement comes first and the routing hint second. Every clause 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?

Safety is covered by annotations, but with no output schema the description never says what a trade record contains, and both inputs are undocumented in schema and prose. Adequate for routing, thin for correct invocation.

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 name 'mint' or explain 'limit' (default 50, max 200). 'One coin' weakly implies the mint parameter but gives no format or identifier guidance, so the description fails to compensate for the coverage gap.

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

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

States a specific resource and scope ('Recent buy/sell history for a token'), and explicitly distinguishes itself from the sibling pumpfun_watch_whales. An agent can tell it apart from other token-data tools 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?

Gives an explicit when-to-use ('read recent buy and sell flow on one coin') and names the alternative with the condition that selects it ('to see only large trades as they land, call pumpfun_watch_whales instead'). 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without description help. The description adds no further behavioral detail such as result ordering guarantees, snapshot vs. live semantics, or pagination, which matters given idempotentHint=false on a read tool. Adequate but thin 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?

Two sentences, purpose front-loaded, routing information second, zero filler. Every clause 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?

With no output schema and a single self-evident integer parameter, the description covers what an agent needs to decide to call this tool. The only shortfall is that the limit parameter is unexplained, but that is a minor gap for a low-complexity 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?

Schema description coverage is 0% for the single 'limit' parameter, so the description has to carry the burden and does not mention it at all. It never states what limit controls, the 1-50 bounds, or the default of 10, leaving the agent to guess from the parameter name.

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 tokens) plus the ranking criterion (market cap), which is exactly what distinguishes it from the other token-listing siblings. An agent can tell it apart from get_new_tokens and get_graduated_tokens 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?

Explicitly names the condition for this tool ('scan the largest coins on pump.fun right now') and routes to two named alternatives for the adjacent cases (fresh launches, graduated coins). This is a clean when/when-not/alternatives statement with nothing 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 safety profile (readOnly, non-destructive, open-world). The description adds valuable output context by naming the ranked fields (wallet, pnlUsd, winRate, trades, rank), which is especially useful because there is no output schema. It does not cover freshness, rate limits, or pagination, keeping it below 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 with zero filler. Purpose is front-loaded, followed by return fields and usage routing, making it easy to scan.

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 simple two-parameter read-only tool, the description covers purpose, return shape, and alternative routing well. The main gap is parameter explanation, but the schema's defaults and enum allow an agent to invoke it correctly, so it is nearly 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?

Schema description coverage is 0%, so the description must compensate, but it only vaguely refers to 'a given time window' and never mentions the limit parameter, its default, or the allowed window values (24h/7d/30d). The schema provides types, defaults, and an enum, but the description adds no semantic meaning beyond that.

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: ranks top KOL traders by P&L over a time window, and explicitly lists the returned fields. It also distinguishes itself from siblings by naming get_coin_intel and get_token_holders for the coin-holding question.

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 when-to-use guidance ('find which trader wallets are worth following') and names the alternative tools for a related but different need. The routing condition is clear and actionable.

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, non-destructive, openWorld), and the description adds genuinely useful operational context beyond them: it is always available and does not require PUMPFUN_BOT_URL configuration. It does not detail failure modes or what 'unhealthy' looks like, but the return shape is covered by the output schema.

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

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

Two tight sentences, front-loaded with what is returned, then availability, then the routing trigger. Every clause carries information with no 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?

Output schema exists so return fields need no explanation, and the description supplies the two things an agent cannot get from structured data: the no-config prerequisite and the diagnostic invocation trigger. Nothing needed to call this 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?

The tool takes zero parameters with an empty, fully covered schema, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter 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?

States a specific verb and resource: it returns the configuration and health status of the pump.fun indexer backend. This is clearly a diagnostic/health endpoint, distinguishable from the data-retrieval siblings like get_token_details or get_new_tokens.

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 when-to-use guidance ('use this first when ... fail or are missing') and names the alternatives it complements, which is exactly the routing an agent needs. Minor deduction because the referenced tools (search_tokens, get_graduated_tokens, get_king_of_the_hill, get_creator_profile) do not appear in the provided sibling list, so the cross-references may not resolve reliably.

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, openWorldHint=true, destructiveHint=false, so safety profile is covered. The description adds the meaningful behavioral trait that it returns only first-time claimers (a filtering behavior) and the return fields. It doesn't describe pagination or ordering beyond limit, which is a modest gap for a read tool.

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 dense sentences with the core scope front-loaded ('First-ever...claims in a time window: a cash-out signal') followed by returns and sibling routing. No filler, though slightly crowded into one long second sentence.

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 simple two-param read-only list tool with no output schema, the description covers purpose, returns, and alternative routing. Minor gap: limit behavior (max 50, default 20) is left entirely to the schema, and ordering/pagination isn't discussed, but overall it's adequate.

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 50%; limit has no description in the schema, but the description implies a count cap ('across all coins' and returns a list) though doesn't explain limit semantics explicitly. sinceMinutes is documented in schema as the lookback window, and description reinforces 'in a time window'. Baseline 3 given partial schema coverage and only marginal added param meaning.

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: 'First-ever pump.fun creator fee claims in a time window' and describes the returned fields (creator wallet, mint, lamports, timestamp). It clearly distinguishes itself from pumpfun_list_claims by naming 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?

Gives a strong positive use case ('spot creators cashing out for the first time across all coins') and an explicit alternative routing ('for one creator's history call pumpfun_list_claims'). No explicit when-not-to-use negative conditions, but the alternative selection is clear.

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 the safety profile (readOnly, non-destructive, open-world), and the description adds genuinely useful context beyond them: it notes the data is on-chain with no indexer needed, and explains the sweep_creator_fee mechanism so the agent understands that a claim only reflects already-swept fees and that pending fees appear in no claim. That is real behavioral insight, not restated 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 purpose, then return fields, then mechanics, then routing. The sweep explanation is dense and slightly long, but it carries real meaning and the opening sentences are crisp; only minor tightening is possible.

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 usefully enumerates the returned fields (signature, mint, lamports, timestamp) and explains the sweep semantics. It falls short only on parameter behavior (limit/network) and pagination, which are left 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 description coverage is only 33%: creator is documented in the schema but limit and network are not, and the description never mentions either. With low coverage the description should compensate, yet it adds nothing about pagination limits, the default/max of 20/50, or network selection, leaving two parameters ambiguous.

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 ('List recent pump.fun fee-claim events for a creator wallet') with clear scope, and explicitly contrasts itself with the sibling pumpfun_watch_claims, so an agent can distinguish them 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?

Explicitly names the use case ('audit how much a creator has already cashed out') and the alternative ('for only the claims inside a recent window call pumpfun_watch_claims'). Both the when-to-use and the routing condition are stated outright.

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 safety (readOnlyHint, destructiveHint=false), but the description adds real context: no signing/tx sending, the GRADUATED-only precondition, and the non-obvious pricing mechanics (effective quote reserves = vault balance + signed virtual_quote_reserves, commonly negative). That reserve methodology is exactly the kind of behavior an agent cannot infer from 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 purpose and hard constraints, and every sentence is substantive. It is on the long side and the i128 reserve aside is dense, but that detail is load-bearing for reproducing the quote rather than filler.

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

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

For a quote tool with an output schema, this covers preconditions, routing to the alternative, pricing mechanics, and a return-field summary. 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 80% and the amountIn/network/slippage semantics are already documented. The description adds one important constraint absent from the schema: one of inputMint/outputMint must be wSOL. This materially improves correct invocation but doesn't cover every parameter detail.

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 (quote) and resource (pump.fun PumpSwap AMM swap) with the read-only scope up front. It explicitly names the sibling to use for a different case (get_bonding_curve for coins still on the bonding curve), so an agent can distinguish it 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?

Gives explicit when-to-use (size a trade on a graduated coin, measure pool depth, before executing anywhere) and when-not (bonding-curve coins -> get_bonding_curve). The alternative and the selecting condition are both 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?

Goes beyond the annotations by disclosing the bearer-token/API-key auth requirement, the permanence of the returned ipfs:// link, and idempotency tied to identical content. Minor flaw: it states a 10 MB image cap while the schema says under 5 MB, an internal inconsistency that could mislead on payload limits.

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?

Four tight sentences ordered purpose -> workflow -> prerequisites -> return/SLA. Every sentence carries distinct, actionable information with no 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?

Output schema exists, so return values need not be re-explained, yet the description helpfully clarifies the uri meaning and downstream use. Coverage of auth and workflow is strong; the 10 MB vs 5 MB mismatch is the one completeness/accuracy gap.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including length/format constraints. The description's parameter content (name, symbol, description, image, HTTPS-or-base64 image) largely restates 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?

Specific verb (upload) plus resource (coin metadata) and outcome (IPFS-backed, pump.fun-ready metadata URI). It is immediately distinguishable from all read-oriented siblings and from the launch tools, naming the artifact it produces.

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 states when to call it ('before launching a coin') and where the output goes ('pass the returned uri to the launch-agent endpoint or the studio launch flow'). No when-not-to-use or named alternative is given, which keeps it from a 5.

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

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuinely useful non-obvious context: the returned publicKey/secretKey in base58, that the secret is never stored and must be saved immediately, and a 60 s hard timeout. It doesn't say what happens if the timeout is reached or how prefix+suffix combine, keeping it short of a 5.

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

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

Five short sentences, each carrying a distinct fact (what it does, what it returns, the ephemerality warning, the timeout, the usage window) with the core purpose front-loaded. No 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-shape detail is not strictly required, yet the description still names the returned fields. Combined with the timeout and save-immediately warnings, an agent has what it needs to call this correctly; only timeout-failure behavior and multi-param interaction 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 50%: prefix and suffix are documented in the schema, but maxAttempts and caseSensitive are bare. The description restates prefix/suffix behavior conceptually but adds no syntax, format, or interaction detail (e.g., whether both may be supplied, how maxAttempts relates to the 60 s cap), so it does not compensate for the uncovered parameters.

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: 'Generate a Solana keypair whose address ends/starts with a vanity pattern.' No sibling tool does anything comparable (the others are reads/quotes/metadata), so it is instantly distinguishable.

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 this before launching a coin when its mint address should carry a recognizable prefix or suffix' gives a clear situational trigger. It stops short of naming alternatives or when-not to use it, but no sibling overlaps this function.

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, destructiveHint=false, and idempotentHint=false, so the safety and repeat-call profile is covered. The description adds the polling/batch context ('after a delay'), but it is ambiguous about whether the tool blocks or streams, and says nothing about return volume or pagination. Useful but thin 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?

Two sentences, zero filler, with the core behavior front-loaded and the routing hint second. Every clause 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?

There is no output schema, so the description carries the burden of describing what comes back; 'all fee-claim events' is minimal and leaves fields, ordering, and volume unknown. The polling semantics of a 'watch' tool are also left implicit. Adequate for routing, incomplete for invocation detail.

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 67%: creator and durationMs are documented in the schema (including the default and 1800000 ms cap), while network has only an enum and default. The description names durationMs and its role, but adds no format or semantics beyond what the schema already states, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Return all pump.fun fee-claim events for a creator wallet.' The scope qualifier ('within a look-back window') plus the explicit contrast with pumpfun_list_claims lets an agent separate this from its nearest sibling without opening either schema.

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

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

Gives both a positive condition ('use this for batch collection after a delay') and a named alternative with the condition that selects it ('for a creator's full recent claim history call pumpfun_list_claims'). This is the explicit when/when-not/alternative pattern.

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, destructiveHint=false, idempotentHint=false), so the bar is lower. The description still adds real behavioral context: the call is a time-bounded live collection (max 10 s), which explains both the blocking nature and why the operation is non-idempotent. It does not mention rate limits or cost, 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 with zero waste; the purpose and window constraint are front-loaded and the sibling routing comes last. 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?

With no output schema, the description carries return-value explanation and does so ('returns all trades whose USD value meets minUsd'). For a read-only collection tool this is close to complete; the exact trade object shape is left unspecified, which keeps it from a 5.

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 every parameter is documented there, so the schema does the heavy lifting (baseline 3). The description restates the minUsd filter and the 10 s cap but adds no format, default, or edge-case detail beyond the schema.

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

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

States a specific verb+resource ('collect whale trades on a pump.fun token') plus scope qualifiers (short window, USD threshold). It is immediately distinguishable from the sibling get_token_trades, which the description names as the non-whale alternative.

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 states when to use it ('to see who is moving size on a coin right now') and names the alternative for the other case ('for the full recent tape call get_token_trades'). 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety and idempotency profile is fully covered by structured data. The description adds only what the result conceptually is (owner wallet address), and with an output schema present it need not describe return shape. Useful but thin 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?

Two sentences, zero waste, front-loaded with the core action and immediately followed by the routing rule. Every clause 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?

A one-parameter read tool with rich annotations, a 100%-documented schema, and an output schema. Purpose, trigger, and alternative are all stated, so 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% and the single 'name' parameter already carries the .sol example, so the schema fully documents the input. The description adds no format, normalization, or resolution-failure semantics beyond it.

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 (resolve) plus specific resource (.sol Solana Name Service domain) and the output it yields (owner wallet address). The description also names the sibling sns_reverseLookup as the inverse, so an agent can separate the two 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?

States the trigger condition explicitly ('when a wallet is named by its .sol domain and you need the address') and names the alternative tool plus the condition that selects it ('for the reverse direction call sns_reverseLookup'). Both when-to-use and the alternative are covered.

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, openWorld, non-destructive), so the bar is low. The description still adds a real behavioral detail in 'primary .sol domain name' — implying a wallet may own several domains but only the primary is returned — which is not encoded in the 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?

Two short sentences, front-loaded with the action and resource, then the routing rule. No filler or redundancy.

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

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

For a single-parameter read tool with a full annotation set and an output schema, the description covers purpose, direction, and the sibling alternative. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and the single 'address' parameter is documented as a Base58 Solana wallet address. The description adds no format, encoding, or edge-case detail (e.g. behavior for addresses with no .sol name) beyond what the schema already supplies, so the baseline 3 applies.

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

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

States a specific verb (reverse-lookup) and resource (Solana wallet address → primary .sol domain name) in the first sentence. It also explicitly distinguishes itself from the sibling sns_resolve by naming the opposite direction, so an agent can route between them without opening either schema.

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

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

Gives both the when ('label a raw wallet address with its human-readable .sol name') and the when-not/alternative ('to go from name to address call sns_resolve'). The selection condition against the sibling is unambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context beyond them: the scoring is lexicon-based and therefore deterministic, and the tool performs no fetching of its own.

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: purpose first, then return shape, then the operational constraint. Zero filler and nothing buried.

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 (though the description helpfully names them anyway). With one well-documented parameter and no auth/rate-limit concerns, the definition is nearly complete; the only loose end is how the cashtag relates to the supplied posts.

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 'posts' array is documented in the schema, so the baseline is 3. The description only restates 'pass the posts in' without clarifying the cashtag reference itself, which appears nowhere in the parameters.

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 (score), resource (social-post sentiment for a cashtag), and method (deterministic lexicon) are all stated up front. It implicitly separates itself from retrieval siblings by noting it 'fetches nothing itself,' though it never names an alternative like social_x_post_impact.

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: 'to score posts you have already collected,' with the precondition that the posts must be passed in. Clear context, but no named alternative or when-not-to-use case.

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, openWorldHint, destructiveHint=false and idempotentHint=false. The description adds real behavioral context beyond those: the no-API-key oEmbed fetch, the exact pricing formula (virtual_quote_reserves / virtual_token_reserves), and critically the failure mode for graduated coins (it fails rather than returning a misleading zero). That failure disclosure is exactly the kind of context annotations cannot convey.

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

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

Two sentences, front-loaded with the core purpose, then the method and the crucial graduated-coin caveat. The parentheticals (pricing formula, failure behavior) are dense but each earns its place because they define correctness of the result.

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 an analytical tool with no output schema, the description explains what is computed (a price delta over the window) but not the shape of the returned result. It covers safety via annotations and the failure mode well, yet leaves the agent guessing at the response structure.

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

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

Schema coverage is 75% (network has no description). The description reinforces windowMin (±window around post time) and adds a real constraint on mint beyond the schema's base58 note: the token must still be on its bonding curve. network and the post-time semantics remain undocumented, but the added meaning for the analytical parameters is genuine.

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+resource: correlate an X post to a memecoin's price impact, and even names the mechanism (oEmbed for metadata, pump.fun bonding curve for pricing). No sibling tool (e.g. social_cashtag_sentiment or get_bonding_curve) overlaps with this single-post impact measurement, so an agent can identify it immediately.

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 condition ('measure how one X post moved a coin that is still on its bonding curve') and an explicit failure boundary ('a graduated coin has no curve, so the call fails'). It does not point the agent to an alternative tool for the graduated-coin case or for multi-post analysis, 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.