Who launched it, what exit really costs, is the pool what it claims. Facts only, no advice.
Scored across 9 tools
Most tools map to a clearly distinct check (chain liveness, exit cost, pool yield safety, stablecoin peg, token safety), so an agent can usually select correctly. However, launch vs. launches (single token's creator vs. live feed) are easy to swap, and deployer-related data is duplicated across deployer, launch, launches, and safety, creating some boundary blur.
All nine tools use a consistent single lowercase noun convention with no style mixing, which is readable and predictable. The only weakness is that bare nouns omit the action verb, and launch/launches differ only by plural, which is a minor source of confusion.
Nine tools is well within the ideal 3-15 range and each covers a distinct pre-commit check, so the surface is sensibly scoped. There is mild redundancy in deployer-history coverage across several tools, but nothing that warrants trimming.
The domain of pre-commit safety checks on Solana assets is broadly covered: chains, tokens, pools, stablecoins, deployers, exit costs, and launch feeds are all present. A couple of gaps remain, such as an entry-cost counterpart to exit_cost and protocol-level risk beyond the 'known' notes tool.
Is this chain alive: TVL trend over 1y/6m/90d/30d. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.009 per call over x402 at /v1/chain
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain name as used by DefiLlama |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the free tier limit (3 calls/hour/IP, shared with the website), the paid path ($0.009 per call over x402 at /v1/chain), and the output stance ('facts and flags only, never advice'). It does not state the return data shape, which is the remaining gap.
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 the core purpose, then output stance, then cost/access. The pricing sentence is dense but directly relevant to invocation decisions.
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 description must cover returns; it names the time windows and the 'facts and flags' nature of the output and covers rate limits and paid access. An agent can call it correctly, though it does not specify the metric's format or edge cases for dead/illiquid chains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'chain' parameter is documented as DefiLlama chain naming, so the schema does the work. The description adds no naming or format detail beyond it, which is the baseline case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (chain) and the exact signal it derives: TVL trend over 1y/6m/90d/30d, framed as a liveness check. It is distinguishable from siblings like safety or stable, though it never explicitly names an 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?
The question form ('Is this chain alive') implies the calling context, and the rate-limit/pricing note tells the agent about cost constraints. There is no explicit when-to-use versus siblings such as safety, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full launch record of a Solana wallet from our own live recording: how many tokens it deployed, how many reached the exchange, its graduation rate against measured base rates, and whether it is a serial minter with no survivors. Data no feed reconstructs. Flags serial_minter, never_graduated. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.030 per call over x402 at /v1/deployer
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | Solana wallet address of the deployer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses concrete rate limits (3 calls/hour per IP, shared with the website), the paid path (x402 at $0.030/call), the flags produced (serial_minter, never_graduated), and explicitly scopes output to 'facts and flags only, never advice'. What is missing is whether the call is read-only/side-effect free, though the read-only nature is strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then flags, then guardrails, then pricing — a sensible order with no wasted preamble. The sales-y clause 'Data no feed reconstructs' is the one sentence that doesn't carry operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return content, and it does: counts, graduation rate against base rates, and named flags. Combined with the rate-limit and pricing disclosure, an agent has enough to invoke and interpret this correctly; only the exact response shape is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and its schema description already covers it at 100% ('Solana wallet address of the deployer'). The description adds no syntax, format, or validation detail beyond that, so the schema does the heavy lifting and a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: the full launch record of a Solana wallet, enumerating what it returns (deployed token count, exchange arrivals, graduation rate vs base rates, serial-minter status). It is clearly distinct from generic siblings like launch/launches/chain, though it never names a sibling 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 description never says when to reach for this tool versus siblings such as 'launch' or 'launches', nor any precondition beyond having a wallet. The only conditional content is commercial (free-tier limits and x402 pricing), which is not invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real cost of exiting a Solana position AT YOUR SIZE — live route, not theoretical slippage. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.030 per call over x402 at /v1/exit-cost
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana token mint address | |
| size | Yes | Position size in whole tokens — the quote is for YOUR size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses the free-tier rate limit, the paid x402 path, and the 'facts and flags only, never advice' framing. It also clarifies the quote is live route-based rather than a theoretical estimate. Missing auth setup detail for x402 and any latency behavior keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core value proposition front-loaded and access terms after. The pricing clause is dense but operationally useful; no filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should characterize the return. 'Facts and flags only' plus 'live route, not theoretical slippage' hints at a cost/route breakdown, and rate-limit and pricing terms are covered. A little more on the returned fields would make it complete for a tool with no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'mint' and 'size' fully documented, so the baseline is 3. The description reinforces that the quote is specific to the caller's size, but adds no syntax or format detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific outcome — the real cost of exiting a Solana position at a given size — using a live route rather than theoretical slippage. This clearly distinguishes it from siblings like chain, pool, and safety. It doesn't explicitly name a competing tool, 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?
The description gives pricing and rate-limit mechanics ('3 calls per hour per IP', '$0.030 per call over x402') but no when-to-use or when-not-to-use guidance. There is no mention of an alternative tool or the condition under which an agent should prefer this one, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Do we hold a research note on this asset, protocol, chain or role that no price feed or TVL number will tell you: dead redemption bridges, ticker collisions, ended points programmes, closed marketplaces, capital gates. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.060 per call over x402 at /v1/known
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Asset symbol, protocol name, chain name or contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does substantial work: it discloses a rate limit (3 calls/hour/IP), that the quota is shared with the website, the paid tier price ($0.060/call) and the x402 payment mechanism at /v1/known. It also characterizes output content as 'facts and flags only, never advice.' It does not mention auth details beyond x402 or pagination/response behavior, keeping it off 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 sentences, each with a distinct job: purpose/content scope, nature of the output, and access terms. The first sentence is dense and slightly awkward (the colon list interrupts the main clause), but nothing is redundant and the access constraints are placed last where they belong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must carry the return-behavior burden. 'Do we hold a research note' reads like an availability question while 'Facts and flags only' implies substantive content is returned, leaving the actual response shape ambiguous. Pricing, rate limits and input domain are covered, but the return semantics gap holds this to a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single parameter q (asset symbol, protocol name, chain name or contract address) is already fully documented. The description restates roughly the same list and adds 'role' as an accepted input type, which is a small semantic extension not present in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (held research notes) and enumerates concrete content types it covers: dead redemption bridges, ticker collisions, ended points programmes, closed marketplaces, capital gates. It distinguishes itself from data-oriented siblings by scoping to signals 'no price feed or TVL number will tell you.' It never names a sibling explicitly (safety, stable, chain could plausibly overlap), 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?
Usage is implied rather than stated: an agent can infer this is for qualitative/flag-level facts about an asset, protocol, chain or role. There is no explicit when-to-use/when-not, no named alternative among siblings, and no guidance on how this differs from safety or stable lookups. The implied context is clear enough for a 3, but nothing routes the agent decisively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who launched this pump.fun token and what happened to their previous ones: launch count, graduation record, and whether the creator bought their own bonding curve. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.015 per call over x402 at /v1/launch
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address of the pump.fun token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the free-tier limit (3 calls/hour per IP, shared with the website), the paid path ($0.015/call over x402 at /v1/launch), and the framing constraint 'facts and flags only, never advice'. It does not explicitly state that the operation is read-only or note caching/return shape, 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?
Front-loaded with the core question and its answer fields before the commercial details. Dense but every clause carries information; the pricing/URL tail is relevant but slightly heavy for a description.
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 description must convey return content, and it does (launch count, graduation record, creator buy behavior). Combined with rate-limit and cost disclosure for a one-parameter read tool, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema description coverage, so the schema already fully documents 'mint' as the Solana mint address. The description adds no syntax or format detail beyond that, which matches the baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific question it answers ('Who launched this pump.fun token and what happened to their previous ones') and enumerates the return fields: launch count, graduation record, and creator bonding-curve purchases. It is clearly a creator/launch-history lookup, but it never distinguishes itself from the very similar siblings 'deployer' and 'launches', leaving overlap unresolved.
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 guidance and no alternative tool is named, despite obvious candidates in the sibling set (deployer, launches). The only conditional information is pricing tiers, not usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live feed of pump.fun launches from the last 24h with creator context: who deployed each one, how many they launched before, whether they bought their own bonding curve. Poll with ?since= for only what is new. This history cannot be reconstructed afterwards. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.030 per call over x402 at /v1/launches
| Name | Required | Description | Default |
|---|---|---|---|
| only | No | Keep only launches carrying this trait. clean = no flags raised. | |
| limit | No | How many launches to return, newest first. Default 50. | |
| since | No | Unix timestamp; return only launches recorded after it. Pass next_since from your previous call to poll incrementally. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: a 24h window, immutability of the history, a no-advice content policy, a rate limit (3 calls/hour/IP shared with the website), and a paid x402 tier at $0.030/call. That is exactly the operational context an agent needs before calling.
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 scope, then polling, then constraints and pricing. Dense but every clause carries signal; the final sentence packs rate limit, cost, and endpoint into one long line, which slightly hurts scanability.
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, and the description compensates by naming the creator-context fields (who deployed, prior launch count, self-buying of the bonding curve). Combined with the disclosed rate limits, cost, and polling model, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with 'only', 'limit' and 'since' fully documented including the enum meanings and the next_since polling pattern, so the baseline is 3. The description's only addition is the '?since=' polling hint, which the schema already covers.
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: a live feed of pump.fun launches from the last 24h, enriched with creator context. It distinguishes itself from siblings like 'launch' (singular) and 'deployer' by framing itself as a time-bounded feed rather than a lookup.
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 clear usage context: use it as a live feed, and 'Poll with ?since= for only what is new' tells the agent how to consume it incrementally. 'This history cannot be reconstructed afterwards' implies timeliness pressure. It never names an alternative sibling (e.g. 'launch' for a single record) or states when not to use it, so it stops 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.
Yield pool safety: peg of every underlying asset, yield sustainability, emission dependence, exit depth. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.015 per call over x402 at /v1/pool
| Name | Required | Description | Default |
|---|---|---|---|
| pool | Yes | DefiLlama pool id (uuid), from https://yields.llama.fi/pools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses rate limits (3/hr shared with website), pricing ($0.015/call over x402), and the facts-only, non-advisory stance. It omits response format and error behavior, but the core behavioral contract is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads what is assessed before moving to pricing and access terms. One sentence covers scope and another covers commercial/limit details 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?
For a single-param lookup at 100% schema coverage with no output schema, the description supplies purpose, scope, usage stance, and access constraints. What is missing (response shape, error cases) is secondary for this profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already documents the DefiLlama pool UUID format and source URL. The description adds no additional meaning about the pool parameter, 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?
The description names the resource ('pool'), enumerates the specific checks performed (peg, yield sustainability, emission dependence, exit depth), and the tool is distinguishable from siblings like safety or stable.
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 clear context that this is for pool safety analysis and states 'Facts and flags only, never advice', which sets usage boundaries. It does not explicitly name when to prefer a sibling such as safety or exit_cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this Solana token safe to touch: mint and freeze authority status, top-holder concentration, Token-2022 transfer risks, and the deployer's full launch record from our own recording. Flags MINT_AUTHORITY_LIVE, FREEZE_AUTHORITY_LIVE, CONCENTRATED, TOKEN_2022, SERIAL_DEPLOYER, DEPLOYER_NEVER_GRADUATED. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.030 per call over x402 at /v1/safety
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana token mint address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses rate limits (3 calls/hour/IP, shared with the website), the paid escalation path ($0.030/call over x402 at /v1/safety), the scope boundary ('our own recording'), and a behavioral constraint ('facts and flags only, never advice'). It does not mention latency or failure behavior for invalid mints, but the operational context is unusually rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core question, then the evidence categories, then the emitted flags, then operational constraints. Each clause carries information, though the flag enumeration and the pricing/endpoint clause make it denser than a two-sentence ideal.
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 or annotations, the description compensates by enumerating the exact flags returned and stating the facts-only stance, which is enough for an agent to interpret results. Missing only edge-case behavior (invalid/non-existent mint) and the response container format, which are minor for a single-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter (mint) with 100% schema description coverage ('Solana token mint address'), so the schema already carries the semantics. The description adds no format, validation, or derivation detail beyond what the schema states, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific question form that names the exact resource (a Solana token mint) and enumerates the four check categories it covers: mint/freeze authority, holder concentration, Token-2022 transfer risks, and deployer launch record. It also lists the concrete output flags, so an agent can tell precisely what this tool returns and how it differs from siblings like deployer, launch, or pool.
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 context is implied rather than stated: an agent can infer this is the pre-trade safety gate, and the pricing clause hints at call budgeting. However, it never says when to choose this over the overlapping siblings (deployer, launch, known), nor when it is unnecessary. No explicit when-not guidance or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this stablecoin's $1 peg a hard anchor or a soft peg: does its price historically return to $1 (a redemption/arbitrage anchor) or sit below it (the market pricing risk), and is it dislocated right now. Flags SOFT_PEG, BROKEN_HISTORY, DISLOCATION. Facts and flags only, never advice. Free tier: 3 calls per hour per IP, shared with the website; unlimited access costs $0.030 per call over x402 at /v1/stable
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Stablecoin symbol (e.g. USDC) or CoinGecko id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it names the three emitted flags, declares the facts-only/never-advice policy, and discloses rate limits (3 calls/hour per IP, shared with the website) plus the paid path ($0.030/call over x402). This is exactly the behavioral context an agent needs and cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The operational content is front-loaded and the later sentences (policy, pricing) are terse. The opening sentence is somewhat convoluted with stacked parentheticals, but overall it is appropriately sized for the information conveyed.
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 no annotations, the description compensates by explaining what the returned flags mean and the cost/access model. It leaves minor gaps such as behavior on an unknown symbol, but an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented ('Stablecoin symbol (e.g. USDC) or CoinGecko id'). The description only refers to 'this stablecoin's' without adding format or resolution detail, so it adds nothing beyond the schema. Baseline 3 is correct.
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 precisely what the tool assesses: whether a stablecoin's $1 peg is a hard redemption/arbitrage anchor or a soft peg, and whether it is currently dislocated. The resource (stablecoin peg) and analytical output (SOFT_PEG, BROKEN_HISTORY, DISLOCATION) are specific. It does not explicitly differentiate itself from the sibling 'safety' tool, which is the only gap.
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 question the tool answers — reach for it when judging a stablecoin's peg integrity — but there is no explicit when-to-use statement, no when-not, and no named alternative among siblings like 'safety' or 'exit_cost'. The agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
deployersafetystablelauncheschainexit_costknownlaunchpoolRisk and structure facts on one Solana or Base token, never a trading signal. Paid per call by x402.
DeFi pool yield+security intelligence & token/contract risk scanner. USDC on Base via x402.
Is a trading bot legit? Sourced bot fact sheets, regulator scam records and on-chain results.
Who is behind a launch: bundles, insiders, airdrops, serial devs. Solana pump.fun + 18 EVM chains.
Add one secure layer between your agents and this server.
