Agent Data API

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

With no annotations provided, the description carries the full burden and does well: it discloses that the data is public, that the output includes warnings and comparative host data, that this is not a verdict, and that the call costs $0.005 in USDC via x402. It does not cover rate limits or error behavior, but the key behavioral traits are present.

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 front-loaded with the core question, then efficiently covers accepted inputs, returned data, caveats, and price. Every sentence carries useful 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?

Given the simple one-parameter schema, absence of annotations, and no output schema, the description is complete enough: it explains the input options, summarizes the returned record, notes the limitations of the signal, and discloses the paid-call cost.

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's schema description already says it accepts an endpoint URL, host, or payTo address. The tool description repeats those accepted input types without adding format examples or additional semantics, 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 clearly frames the tool as a pre-payment check on an x402 seller and specifies what the Bazaar record includes. It is specific about the resource and intent, though it does not explicitly differentiate itself from closely related siblings such as x402_seller_customers or x402_payer_profile.

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 opening question establishes a clear use case: deciding whether an agent should pay a given x402 seller. It also notes the result is 'signals, not a verdict,' which sets expectations, but it does not name alternatives or state when not to use this tool.

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?

With no annotations, the description carries the behavioral burden and discloses useful traits: ~2 s latency, no API key, x402/USDC pricing at $0.01 per call, and data sources including DNS records. It does not explicitly discuss permissions, rate limits, or data freshness, but it is far more transparent than a bare mutation/read label.

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 front-loaded with the core capability and packs useful output examples, latency, price, and payment details into one dense sentence. The long enumeration of fields is justified by the absence of an output schema, though it could be structured more scannably.

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?

Because there is no output schema, the description usefully enumerates returned fields, including firmographics, socials, contacts, pages, and SaaS stack. It is complete enough for an agent to understand the value, though input format and error behavior are not covered.

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

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

The schema has one required string parameter with 0% description coverage, so the description must compensate. It only repeats that the input is a domain; it does not specify whether a bare domain, URL, or subdomain is expected, nor give format examples.

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

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

The description states a specific verb and resource: company enrichment from a domain, with firmographics and tech stack. It is clearly distinct from the sibling tools in practice, but it does not explicitly name or differentiate alternatives, so it falls short of the top 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?

The description implies usage by saying enrichment is keyed off a domain and noting speed and price. However, it gives no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as web_search or email_verify.

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?

With no annotations, the description carries the burden and does well: it discloses the check categories, that results come as a risk band plus findings, that it is advisory only, and the billing model ($0.01 per call via x402/USDC). It omits latency, rate limits, and what happens on unsupported chains, 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?

Front-loaded with the core purpose and tightly packed with relevant detail; no filler sentences. The dense semicolon-heavy phrasing slightly hurts scannability but 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?

No output schema exists, yet the description conveys the return shape (risk band + findings) and per-chain scope, which is adequate for a single-parameter tool. Missing only edge-case behavior (unsupported chains, error/empty results).

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 with 0% schema description coverage, so the description must compensate. It implies the input is a crypto address and that chain is inferred from the address (18 chains listed), but never states address format or behavior for unsupported/ambiguous addresses.

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 (sanctions screening and AML risk for a crypto address) and enumerates exactly what is checked per chain: OFAC sanctioned match, Bitcoin one-hop exposure, Solana account profile fields. This distinguishes it from siblings like solana_wallet_profile and token_safety without needing their schemas.

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 subject matter (screen an address for risk), and the caveat 'Screening aid, not a verdict' hints at how to treat results. However, there is no explicit when-to-use vs alternatives (e.g., solana_wallet_profile for deeper Solana-only analysis) and no stated exclusions or prerequisites.

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?

With no annotations provided, the description carries the full burden and does so well: it discloses the verification checks, the valid/risky/invalid verdict with score, the absence of SMTP probing and sending, the batch limit, runtime, and pricing. These are exactly the behavioral details an agent needs before invoking it.

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 dense but front-loaded: the core purpose comes first, followed by the checks performed, verdict model, operational caveats, and pricing. Nearly every phrase carries useful information for selection or invocation.

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 the simple one-parameter schema, lack of annotations, and no output schema, the description is complete: it explains what is checked, what verdict is returned, what is not done (SMTP/mail), and the cost. There is no material gap for an agent deciding whether and how to call it.

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 input schema has 100% description coverage and already documents that the parameter accepts 1-20 comma-separated emails. The description repeats the 20-address cap but adds no meaningful syntax or formatting detail beyond the schema baseline.

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 gives a specific verb and resource ("Email verification / validation API") and enumerates exactly what is checked: syntax, MX, provider, disposable domains, free webmail, role accounts, typo suggestions, and verdicts. This makes it clearly distinguishable from sibling tools such as company_enrich or prompt_injection_check.

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 establishes a use context for lead lists and states the per-call limit and runtime, but does not explicitly say when to choose this tool over alternatives or when not to use it. The usage is implied rather than framed as explicit decision 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?

With no annotations, the description carries the burden; it does disclose the cost profile ('FREE') and enumerates what the response contains (price, input example, endpoint URL), which is real behavioral value. It does not state that this is a read-only, side-effect-free listing, nor whether the catalog is live or cached, so gaps remain for a zero-annotation 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 compact sentences with the highest-value token ('FREE') front-loaded and zero filler. The second sentence is a dense noun phrase without a verb, which is slightly telegraphic but not wasteful.

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 no-parameter listing tool with no output schema, the description states the full shape of what comes back (tool, price, example, HTTP endpoint), which is what an agent needs to decide to call it. It could add one line on how this catalog relates to the recommendation/payment siblings, but otherwise it is sufficient.

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

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

The tool takes zero parameters, so the schema baseline is 4 and there is nothing for the description to compensate for. No parameter semantics are needed or missing.

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 clear resource and payload: every tool with its price, input example, and the equivalent plain-HTTP x402 endpoint. An agent can tell this is a discovery/catalog tool rather than one of the operational siblings. It lacks an explicit verb (e.g. 'Lists') and never names itself as a meta/directory tool, which keeps it 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 leading 'FREE.' signals a cost-based reason to call it and implies it is a safe lookup, but there is no explicit when-to-use or when-not-to-use guidance and no reference to alternatives such as recommend_x402_api, which overlaps with this discovery purpose. Usage is implied rather than stated.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that the tool is FREE and that it is a read operation, but it omits permissions, rate limits, error behavior, and whether/how alerts are paginated or formatted.

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 front-loaded and free of filler, with 'FREE' first and the core purpose immediately after. It is appropriately terse, though that terseness contributes to the missing parameter and behavioral detail handled in other dimensions.

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 two-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It leaves the 'since' parameter unexplained and provides no detail about what alerts contain or how the watch identifier should be supplied.

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 explain both parameters. It only hints that 'watch' refers to a watch from memecoin_watch, without specifying identifier format, and it never mentions the 'since' parameter at all.

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

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

The description states a specific verb and resource: reading alerts associated with a memecoin watch. The parenthetical '(from memecoin_watch)' partially differentiates it from the sibling that likely creates or manages the watch, though it does not contrast with the other memecoin analysis tools.

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 phrase '(from memecoin_watch)' implies this tool is used after a watch exists, but there is no explicit guidance on when to use this versus related tools such as memecoin_watch or memecoin_exit_check. Usage is therefore implied rather than clearly prescribed.

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?

With no annotations, the description does real work: it discloses simulation assumptions ('1-minute bars, stop first'), that returns are net of fees, and that the tool is a paid x402 endpoint at $0.01/call in USDC. Missing are execution traits like latency, result caps, or what happens on insufficient payment, but the core behavioral profile is unusually well covered.

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 purpose leads, followed by mechanics, output, and pricing in a tight three-sentence block with no filler. The middle sentence is dense with parenthetical enumerations, but every clause carries information an agent would otherwise have to discover by calling.

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

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

There is no output schema, and the description compensates by naming the returned metrics (win rate, avg/median return after fees, exit reasons, per-day results, best/worst trades). The simulation basis and pricing are covered. The significant remaining hole is the five completely undocumented input parameters, especially which are optional and what shape 'exits'/'strategy' objects take.

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 five parameters (including two nested objects), so the description must compensate and it only partly does. It explains the concepts behind 'exits' (take-profit tiers, stop, trailing, time stop) and hints at 'strategy' (screen filters) and 'costPctPerSide' (fees), but it never maps these to the parameter names, and 'entryAt' and 'days' are left entirely unaddressed.

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

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

The description states a specific verb and resource ('Backtest a memecoin strategy') and enumerates exactly what is replayed (screen filters + exit rules on graded pump.fun tokens or a preset's live signal ledger), so the function is unambiguous. It does not name the sibling it contrasts with (e.g. memecoin_exit_check for live exits, memecoin_screen for filtering), so an agent must infer the boundary itself.

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?

'before you trade it' implies a pre-trade validation context, and the two data sources (all graded tokens vs. a preset's signal ledger) hint at a mode choice. However, there is no explicit when-to-use/when-not or routing statement relative to memecoin_screen, memecoin_exit_check, or memecoin_track_record, leaving the selection 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?

With no annotations, the description carries the burden and does disclose real behavioral facts: it is a paid x402 call at $0.003 USDC per invocation, it is stateful relative to a supplied entry point, and it should be polled repetitively. It omits rate limits, failure behavior, data latency, and whether repeated polls are billed each time, which are material for a paid polling 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?

Purpose and inputs are front-loaded in the opening clause, then output options, then the polling instruction, then price. The long parenthetical rule list is dense but each item carries distinct meaning. Slightly overpacked into one sentence but 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?

For a tool with no annotations, no output schema, 0% schema coverage, and nested `entry`/`rules` objects, the description covers the verdict space and pricing well but leaves the entry object's required fields and `alreadySoldPct` unexplained. An agent could still call it, but would be guessing at the entry payload format.

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% with five parameters including two nested objects, so the description must compensate. It does a good job enumerating the rule triggers (take-profit tiers, stop-loss, trailing stop, time stop, dev sell, sniper dump, sell pressure, holder concentration, liquidity drop, verdict flip), but the shape of the `entry` object, the meaning of `chain`, and the role of `alreadySoldPct` are never explained.

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 capability: take an entry price plus exit rules and return hold / sell X% / exit now with reasons, based on the token's path since entry. That is concrete enough to separate it from pre-entry tools like token_pretrade_check or token_safety. It never names a sibling explicitly, so a 4 rather than 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?

'Poll it while you hold' gives a clear usage window (post-entry, ongoing position management) and the framing 'from the token's real path since your entry' reinforces that entry data is required. There is no explicit when-not guidance or named alternative for, say, a pre-entry check, which keeps it below 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?

With no annotations, the description carries the burden and does well: it discloses the 2-hop trace limit, the returned categories (shared-funder clusters, dev-linked wallets, fresh wallets, holdings, coordination-risk %), and the $0.02 x402/USDC pricing. It omits auth/payment failure behavior and rate limits, 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?

Front-loaded with the core question, then the analysis method, outputs, and price — every clause earns its place. The single dense paragraph is slightly run-on compared to a structured breakdown, but there is 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?

Given zero annotations, no output schema, and 0% param coverage, the description is complete on purpose, outputs, hop limit, and pricing but leaves parameter behavior and payment-failure semantics unexplained. Adequate, with clear remaining gaps for a paid 3-param 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%, so the description must explain all three params. It hints at depth ('up to 2 hops') but never ties that to the depth parameter or its range; it says nothing about what 'buyers' controls (how many early buyers are sampled) or what format 'token' expects (mint address vs. symbol).

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?

A specific verb (trace) applied to a specific resource (early memecoin buyers' funding) on a specific chain/venue (Solana pump.fun), framed around a concrete question: independent buyers vs. one operator. That analysis is distinct from siblings like memecoin_token_report or memecoin_exit_check, so an agent can route without opening schemas.

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 opening question implies the use case (bundle/insider due-diligence before trading), and the list of outputs signals what decisions it supports. However, it never states when to prefer this over memecoin_exit_check, memecoin_pretrade_check, or crypto_address_risk, nor any exclusion; guidance remains implied rather than explicit.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose valuable traits beyond the schema: real-time data sources, cursor-based polling, and a $0.01/call x402 USDC payment requirement. It omits rate limits, error behavior, and whether results are read-only snapshots, leaving meaningful gaps for a paid live-data 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?

Front-loaded with the core purpose, then data coverage, filterable fields, presets, polling, and pricing—each clause adds information. Dense but well-organized, 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?

For a 7-parameter, nested-filter tool with no output schema, the description covers intent, data scope, cost, and polling but leaves the mechanics of most parameters and the shape of returned results unspecified. An agent can understand what the tool is but not fully how to construct a correct call.

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% across 7 parameters including a nested filters object, so the description must compensate. It hints at filters/sort (100+ fields, presets, time windows) and implies the cursor maps to a param, but never explains the format of sort, limit, chains, sources, or the structure of the filters object. Substantial gaps remain.

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: a memecoin screener over live pump.fun launches and Solana/Base DEX pools, with custom strategy and 100+ filterable fields. It is clearly differentiated from siblings like token_launches or memecoin_watch by emphasizing multi-chain live screening with custom filters, though it never explicitly names a sibling to prefer.

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?

"Poll with the cursor" and "Presets included" give partial usage cues, and the trading-agent framing implies the context. But there is no explicit when-to-use vs when-not, and no routing to alternatives like token_pretrade_check or memecoin_alerts for single-token or alert use cases.

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?

With no annotations, the description carries the full burden, and it does add two things structured data cannot: the payment model ('$0.02 per call (x402, USDC)') and a full inventory of what the report contains. It does not state latency, failure behavior, or whether a paid call can be re-run/retried, so a mutation-free read still lacks operational context.

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

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

One dense but well-ordered sentence that front-loads the deliverable and then lists contents, closing with the price. No filler sentences, though the parenthetical content list is long enough that a comma-heavy parse is slightly taxing.

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

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

Without an output schema, the description does the heavy lifting on return contents, which it handles well. The price/payment note is included. However, for a tool whose correctness hinges on supplying a valid token identifier and chain, the absence of any parameter guidance leaves a real 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 0%, so the description must explain both parameters. It partially compensates for 'chain' by enumerating supported networks (Solana pump.fun/DEX, Base, Ethereum), but never says whether chain is optional or what the default is. The required 'token' parameter — address, symbol, or pair — is never described at all.

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

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

The description names a specific artifact ('Deep memecoin report') and enumerates its contents precisely: safety verdict, rug-risk %, launch structure, holders, smart-money buyers, market windows, summary and card image. An agent knows exactly what the tool returns. It stops short of 5 because it never distinguishes itself from close siblings such as token_safety, token_pretrade_check or memecoin_screen.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives despite the sibling list containing several overlapping safety/screening tools. The word 'Deep' implies this is the comprehensive option versus lighter screeners, but that inference is left entirely to the agent.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the tool is FREE and describes the performance thresholds it reports, but it does not clarify data freshness, computation method, limitations, or how the 'blind score' is derived.

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 a single dense sentence, front-loaded with 'FREE' and then the core comparison. It is concise, though the parenthetical performance thresholds make it slightly harder to parse on first read.

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

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

For a zero-parameter analytical tool with no output schema or annotations, the description gives a reasonable sense of what is compared and reported. However, it leaves gaps around data recency, sample size, and the meaning of 'blind score' that would help an agent decide whether the tool fits the task.

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

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

The tool takes zero parameters, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description does not create confusion about inputs.

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 specifies the resource clearly: historical performance of memecoin screen presets' live signals versus all pump.fun tokens, plus the lookalike model's blind score. It is more specific than a generic 'track record' tool, though it does not explicitly distinguish itself from sibling tools like memecoin_backtest.

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 does not state when to use this tool, when not to use it, or which sibling tool to choose instead. An agent must infer from the name and description that this is for evaluating preset/model performance rather than running screens or backtests.

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?

With no annotations, the description carries the full burden and does substantial work: it discloses polling intervals (5m/15m/30m/1h/4h/1d, plus 1m for positions), a sell-burst dump detector, three alert delivery paths, that alerts are free to read with the watch id, and an explicit price of $0.05 per call via x402/USDC. The payment/auth requirement and cost are exactly the kind of context annotations would otherwise supply. It stops short of stating watch lifetime/expiry or what happens on payment failure.

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?

Purpose is front-loaded in the opening phrase, and every clause contributes real information (intervals, delivery, price). However, it is a single dense run-on sentence stitched together with semicolons, which makes the mode split and pricing harder to extract than separate sentences would.

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 6-parameter tool with nested objects and no annotations or output schema, the description covers the operational picture (cadence, delivery, cost, two watch modes) reasonably well. What an agent still cannot determine is the valid value set for the required 'type' field and the structure of the strategy/position/notify objects, which are essential to a correct call.

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% across 6 parameters including two nested objects, so the description must compensate. It partially does — it implies the interval values, names webhook/Telegram/Discord channels (likely mapping to notify/webhook), and explains the strategy vs position mode split (likely the required 'type' field). But it never maps meaning onto parameter names or describes the notify/strategy/position object shapes, leaving most of the schema undocumented.

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

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

The description names a specific resource and behavior: a 24-hour memecoin watch that re-runs either a screen strategy or position exit rules on a schedule and alerts. That is distinguishable from siblings like memecoin_screen (one-shot screen) and memecoin_alerts (read alerts), though it never explicitly names those alternatives.

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

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

Usage is only implied: you use this when you want continuous monitoring rather than a one-off check, and the two modes (strategy watch vs position exit watch) are described. There is no explicit when-not-to-use guidance and no reference to sibling tools like memecoin_exit_check or memecoin_alerts by name.

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?

No annotations exist, so the description carries the full burden and does well: it discloses the pricing ($0.003 per call via x402, USDC), the payment/auth mechanism (x402), the real-time feed nature, and the seller-labeling behavior. It omits rate limits and page/limit semantics but covers the high-value behavioral facts.

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, front-loaded with the core purpose then the trigger framing, polling instruction, and price. Every sentence earns its place 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?

No annotations and no output schema, so the description must carry the load; it covers cost, payment, polling, and the return content (payments labeled with x402 seller). It leaves the 'limit' parameter undefined and gives no sense of result volume or pagination behavior.

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

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

With 0% schema coverage, the description must document all three params but only partly does. It explains 'since' as a cursor for polling and implies 'address' is a Base address, but 'limit' is entirely unaddressed in both schema and 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?

States a specific resource and scope: a real-time USDC payment feed for any Base address, returning new in/out payments since a cursor, labeled with the x402 seller when applicable. The verb/resource are unmistakable. It does not explicitly contrast itself with siblings like x402_payer_profile or x402_seller_customers, 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?

Gives concrete polling guidance ("Poll with since=<cursor> to get only new ones") and notes it is "a trigger for agents," which implies intended use. However it never says when to reach for this versus the many x402 siblings or its prerequisites beyond the payment itself.

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?

With no annotations, the description carries the full burden and does well: it discloses the paid x402/USDC pricing model ($0.002 per call), the output classification tiers, and the detection surface including invisible Unicode and base64 decoding. It omits whether submitted text is logged/stored, size limits, and latency, which matter for a tool that receives potentially sensitive page or email content.

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?

Purpose and trigger are front-loaded in the first clause, with the detection list and price following. It is a dense run-on sentence, but nearly every listed detection category adds actionable information rather than 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?

With no output schema or annotations, the description still tells the agent what comes back (safe/suspicious/malicious, 0-100 score, evidence) and what it costs, which covers the two biggest unknowns. The remaining gap is the exact relationship between the `text` and `html` inputs.

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 that `text` is the content under inspection and that supplying `html` enables hidden-element scanning ("base64 payloads and (with html) hidden elements"), but it never says whether `html` is a separate full-document input or a supplement to `text`.

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

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

The description names a specific verb and resource — prompt injection detection — and enumerates the exact threat classes it catches, so an agent knows precisely what it does. It never names a sibling tool, so it is clear but not explicitly differentiated from neighbors like web_read or web_fetch.

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?

"check text you are about to read (pages, emails, tool output)" gives a concrete triggering context, which is a real usage guideline. There is no when-not-to-use clause (e.g., trusted/own content, already-scanned text), 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?

With no annotations, the description carries the full burden and does substantial work: corpus size (36k+ endpoints), freshness (re-indexed every 6h), ranking signals (relevance, 30-day unique payers/calls, recency, price), dedup rule (max 2 per seller), dead-URL removal, and cost/payment rail ($0.005/call via x402 USDC). It omits rate limits and no-result behavior, which keeps 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?

Front-loaded with the decision question and purpose, followed by one dense but well-ordered sentence covering corpus, ranking, filters and price. Nearly every clause earns its place, though the run-on structure packs a lot of facts into a single 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 4-param tool with no output schema and no annotations, the description covers the return shape (method, price, networks, ready-to-send example call), cost, and freshness. The only real gap for correct invocation is the undocumented 'limit' parameter.

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 25% – just 'need' is documented – so the description must compensate. It does explain the two filter parameters (max_price, network) in a 'Filters:' clause, but leaves 'limit' entirely undefined and adds no format guidance for network values.

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: recommends/ranks x402 API endpoints from the Bazaar given a plain-language need. The opening question plus 'API recommender / discovery for agents' makes it unmistakably distinct from siblings like list_tools_and_prices or web_search.

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 framing question 'Which x402 API should I call?' and 'describe the need in plain words' give a clear trigger condition for calling it. It stops short of naming when not to use it or pointing to alternatives such as list_tools_and_prices, so it is clear context without explicit exclusions.

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?

No annotations are provided, so the description carries the burden. It usefully discloses the $0.01 per-call price and x402/USDC payment mechanism, but does not state what the tool returns, how invalid tool/input combinations are handled, or whether calls are idempotent.

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 action and resource, then adds discovery path and pricing. The long parenthetical category list is dense but informative; nothing is seriously 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?

For a meta-dispatcher with a nested input object, no output schema, and no annotations, the description covers discovery and cost but leaves return values and failure behavior unstated. Adequate to start, but not fully complete for reliable 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%, so both parameters depend on the description. It explains that "input" is the selected tool's JSON input and directs agents to list_tools_and_prices for examples, which partially compensates, but it does not describe the tool enum or the nested input shape 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 ("Run") and resource ("one of our 70 data tools"), enumerates representative categories, and distinguishes itself from list_tools_and_prices by being the paid execution path rather than the free listing path.

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?

Clearly points agents to list_tools_and_prices to discover each tool's JSON input example, which is essential context before calling this dispatcher. It stops short of explicit when-not conditions or error-handling guidance, but the primary usage path 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the cost ($0.01 per call via x402/USDC) and that non-Shopify domains are not charged, but it omits auth requirements, rate limits, error behavior, and latency, which are important for an agent to know 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?

The description is two sentences with no wasted words; the core value proposition (what data is returned) is front-loaded, followed by the pricing note. The list of data fields is long but necessary to convey the tool's breadth.

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 data-retrieval tool with no annotations or output schema, the description does a good job of enumerating the returned data, effectively serving as a return-value summary. However, it lacks parameter format guidance and operational transparency (auth, rate limits), which are necessary for reliable 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?

The single 'domain' parameter has zero schema description coverage, so the description must compensate. It implies the domain is for a Shopify store but does not specify the expected format (e.g., 'example.myshopify.com' vs 'example.com') or any validation rules, leaving a meaningful 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 clearly states it retrieves the live tech stack of a single Shopify store and enumerates the returned data, making the verb and resource unambiguous. However, it does not differentiate itself from the sibling tool shopify_stores_search, which an agent might confuse for a similar 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?

There is no explicit guidance on when to use this tool versus alternatives like shopify_stores_search. The note that 'Non-Shopify domains are not charged' implies a scope limitation, but it is framed as a pricing condition rather than a usage rule and no alternative is 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?

With no annotations, the description carries the full burden and does substantial work: it discloses the result cap (10 per call), the sort order (most-visited first), the returned fields (apps, spend estimate, gaps, public contacts), the index population, and a per-call price of $0.01 via x402/USDC — an unusual and important cost signal. Deduction for referencing "page with offset" when no offset parameter exists in the schema, which muddies the pagination story rather than clarifying it.

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 that front-load the core capability before filters, result shape, and price — a sensible order with little filler. The price/payment clause and the pagination clause are both load-bearing, though the offset reference costs clarity rather than saving space.

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 6-parameter, annotation-free, output-schema-free search tool, the description does well on return shape, ordering, cap, and pricing. It is still incomplete on the questions that decide correctness: what separates `missing` from `exclude_app`, whether `app` and `q` are exact matches or fuzzy, and how to page when no offset field exists.

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 all six parameters depend on the prose, and the prose never maps to parameter names. Worse, the two closest-looking filters — `missing` and `exclude_app` — are never differentiated despite both appearing to mean "without an app," leaving the agent to guess. The description also describes paging via offset, a parameter that is not in the schema, which actively misleads.

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 verb and resource: "Find Shopify stores by the apps they run or lack," then enumerates concrete filter axes (app, missing app, country, niche keyword, spend). This is far more than a restatement of the name. It stops short of a 5 because the singular sibling shopify_store is never named or contrasted, so the agent must infer the split between store search and single-store 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?

Concrete example queries ("stores using Klaviyo, stores without a loyalty app") give the agent a clear sense of when this tool fits, and "From our index of high-traffic Shopify stores" bounds the population being searched. There are no explicit exclusions or pointers to alternatives when the query is about a known domain rather than a segment.

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?

No annotations exist, and the description does substantial work: it names the data provenance (on-chain RPC plus 'our trade data'), discloses the cost model ($0.005/call, x402/USDC), and defines the label taxonomy. It does not cover failure modes (invalid or non-Solana address, unknown wallet, partial data) or how the trade-data segment behaves for wallets with no history.

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

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

A single front-loaded sentence that leads with the resource, then the return payload, then the business terms. Nothing is redundant and the pricing disclosure is placed last where it belongs.

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 steps in by enumerating the return fields, which is the main completeness risk for this tool. The remaining gap is input validity handling for the address, which an agent needs before calling.

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 0% schema description coverage, so the description must carry format details — it only implies 'address' is a Solana address via the tool title, with no mention of base58 encoding, length, or whether program accounts are accepted. Helpful but not fully compensating for the empty 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 concrete verb and resource ('Solana wallet profile') and then enumerates exactly what is produced: account type, SOL balance, activity, failed-tx share, velocity, token trade record, and a discrete label set. That enumeration makes it clearly distinguishable from chain-agnostic siblings like crypto_address_risk or token_pretrade_check 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?

The content list implies the use case (wallet due diligence before interacting/tipping), but the description never states when to pick this over crypto_address_risk, x402_payer_profile, or token_pretrade_check, and gives no exclusions or prerequisites. Usage is inferable rather than instructed.

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?

With no annotations, the description carries the full burden, and it does disclose two things an agent critically needs: every call costs $0.01 via x402/USDC, and each record includes liquidity, early volume, buyers, momentum score and a go/caution/avoid verdict with reasons. It also describes the returned fields in lieu of an output schema. Missing are rate limits, pagination, and what happens on an unfunded or failed x402 payment.

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, front-loaded with the resource and its scope, then the payload contents, then the filter/poll/pricing facts. Dense but every clause carries information an agent needs, and nothing is repeated from structured fields.

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

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

For a paid, read-only feed with no output schema, the description covers return contents, chain coverage, filters and cost — the essentials for correct invocation. The gaps (two undocumented parameters, no payment-failure or rate-limit behavior) are real but secondary given the tool's read-only, list-shaped nature.

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% across six parameters, so the description must compensate and only partly does: it explains 'minutes' (last N minutes), 'chain' (Solana, Base, Ethereum, BSC), 'verdict' (go/caution/avoid) and 'min_liquidity'. 'limit' and 'since' are never mentioned, and there is no indication of allowed values, date format, or defaults.

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 gives a specific verb+resource+scope: a feed of newly created Solana/Base/Ethereum/BSC token pools in the last N minutes, sourced from pump.fun, Meteora, Raydium and PumpSwap. It is concrete enough to distinguish from generic search tools, though it never names or contrasts the overlapping siblings (token_pretrade_check, token_safety) that could serve the same pre-trade verdict need.

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?

'For sniping bots' and 'Poll it' give an implied use case and a polling instruction, and 'Filter by liquidity and verdict' hints at narrowing. But there is no explicit when-not-to-use, no mention of how this differs from token_pretrade_check for a single-token verdict, and no guidance on poll interval or how to avoid redundant paid calls.

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?

With no annotations, the description does real work: it discloses latency (~0.3-1 s), cache TTL (120 s), batch ceiling, the paid x402/USDC billing model ($0.01 per call), and exactly what is inspected (authorities, honeypot simulation/taxes, liquidity, holder concentration with pools excluded, buy/sell balance, age). It stops short of rate limits and failure behavior for bad addresses.

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

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

One dense paragraph with the identity and output verdict front-loaded, followed by chain coverage, checks, and cost. Every clause carries information, though the stacked parentheticals make it slightly harder 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?

No output schema exists, and the description compensates by naming the return shape (go/caution/avoid + reasons). Payment model, latency, and cache are all stated. Only error/edge-case behavior is unaddressed, which is a minor gap for a read-only batch check.

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 baseline is 3, but the description adds useful semantics: the supported chain surface (Solana with pump.fun/Meteora curves and Token-2022, plus Ethereum/BSC/Base) and the up-to-10 batch size. It does not explain address formatting or what happens when a token is unsupported on the given chain.

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 and resource: a pre-trade rug/safety verdict returning go/caution/avoid plus reasons, scoped to Solana and EVM chains. It clearly frames the audience (trading bots) and scope. It does not distinguish itself from the sibling token_safety or token_launches, so a 4 rather than 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?

"Pre-trade safety verdict for trading bots" implies the usage context well, and the batch limit (10 tokens/call) and 120 s cache give practical calling guidance. However, there is no explicit when-not-to-use and no reference to the overlapping token_safety sibling, leaving the agent to infer routing.

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?

With no annotations, the description carries the full burden and does well: it discloses the exact output shape (one 0-100 safety score + verdict), the scope of analysis per chain family, and the commercial/access model (x402, USDC, $0.01 per call) — genuinely useful context an agent cannot get from structured fields. Gaps remain: no default for the chain parameter, no error behavior for unsupported chains, no latency or rate-limit note.

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 purpose, then a compressed enumeration of what is checked, then the output, disclaimer and price. Nearly every clause carries signal. It is dense but not padded; a slightly cleaner separation of the chain list from the check list would help 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?

For a 2-param tool with no annotations and no output schema, the description covers purpose, chain coverage, analysis scope, return format (score + verdict), cost and disclaimer — everything needed to decide and pay for a call. The missing pieces are the chain default, address format expectations, and differentiation from the near-identical pretrade sibling.

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, and it partly does: it enumerates the supported chains (Solana incl. pump.fun, Ethereum, BSC, Base), which effectively defines valid values for the undocumented 'chain' param. But 'address' is never clarified as a token mint/contract rather than a wallet address (a real ambiguity given the solana_wallet_profile sibling), and no format hints (base58 vs 0x) or chain-default behavior are given.

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

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

The description names a specific resource and action: a honeypot/rug-pull safety check on a token, across Solana (incl. pump.fun), Ethereum, BSC and Base, returning a 0-100 score plus verdict. That is unmistakably a token-contract safety scan. It does not, however, distinguish itself from the sibling token_pretrade_check or crypto_address_risk, so the agent must infer which one applies.

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 enumerated checks (mint/freeze authority, holder concentration, LP locked, sell simulation) which tell the agent this is a pre-trade token due-diligence call. There is no explicit when-to-use/when-not statement and no routing against the very similar token_pretrade_check sibling. 'Signals, not advice' is a caveat, not usage 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?

With no annotations, the description carries the full burden and does well: it discloses the 5 MB cap, Cloudflare edge fetching with a fallback, that error statuses are free, and the per-call price. It omits timeout behavior, redirect limits, and auth mechanics beyond the x402 price mention.

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

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

Dense but front-loaded: purpose first, then formats, then return fields, then limits and pricing. Every clause carries information, though the run-on structure packs several distinct concerns into one long 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?

Complete for a two-parameter fetch tool with no output schema: it describes return values (final URL, status, content type, size), the format-dependent payload behavior, size limit, and cost model. An agent has enough to call it correctly and predict the response shape.

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%, so the description adds real meaning by mapping formats to outcomes (images/PDFs become base64 for multimodal input, alternatives include markdown, text, JSON). The 'auto' format value is not explained, and the required URL parameter gets no extra constraints.

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 (fetch) and resource (any URL) and clarifies it returns raw content rather than extracted text. That implicitly separates it from siblings like web_read and web_search_read, but no sibling is named and the 'web scraping' framing is slightly redundant.

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?

Clear conditions for use: when raw HTML/JSON/text, base64 for images/PDFs, or markdown is needed. There is no explicit when-not guidance or named alternative, so an agent must infer that web_read is the readability-extraction sibling.

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?

With no annotations, the description carries the burden and does so well: it discloses the Cloudflare edge fetch, ~0.5 s latency, that unreachable pages are not charged, and the $0.003 x402/USDC price. It also names the returned fields and the injection-scan coverage (visible, hidden HTML, comments, invisible Unicode), though it omits truncation and rate-limit behavior.

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

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

Dense but front-loaded: the core purpose leads, then metadata, then safety scan, then cost/latency. Every clause carries information, though the parenthetical and field list make it heavier than it needs to be.

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 and no annotations, so the description must double as the return-value contract, and it does by naming the metadata fields and the injection scan. The one hole is max_chars behavior and any truncation/failure semantics.

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 50%: url is documented as 'Public http(s) URL' while max_chars has no description anywhere. The description adds nothing about either parameter, so the undocumented max_chars semantics (truncation vs. error, units, default) remain a real 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 concrete verb and resource: converts a web page to markdown, main content only, and enumerates the metadata returned. It is clearly distinguishable in substance from search-oriented siblings, but it never names web_fetch or web_search_read, which is what a 5 requires.

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 'for LLM agents' and the prompt-injection scan framing, so an agent can infer this is the read-one-page-plus-safety-check tool. There is no explicit when-to-use/when-not or routing to web_fetch, web_search_read or prompt_injection_check.

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?

With no annotations, the description carries the full burden and does well: it discloses the auth model (no API key), the pricing and payment rail ($0.003 per call via x402 in USDC), and the result cap (up to 10 per call). It omits rate limits and error/failure behavior, which keeps 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?

Two dense sentences, zero filler, with the core capability, return fields, filters, cap, and cost all front-loaded in the order an agent needs them. Nothing is repeated and nothing extraneous is included.

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 enumerating the returned fields, plus it covers cost and the result cap. Only operational details like error handling and rate limits are absent, which is a minor gap for a paid search call.

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%, so the schema already documents q, time, and region; the description's main added value is clarifying that limit is capped at 10 results per call, and it repeats the region/time value lists. It adds some meaning but not enough to exceed the baseline for high-coverage schemas.

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 ('Web search API') plus the exact return shape (title, URL, domain, snippet, position) and scope ('any query'). It is clear what the tool does, but it never names or distinguishes itself from siblings like web_fetch, web_read, or web_search_read, leaving that inference to the agent.

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

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

Usage is only implied by the query-centric framing; there is no explicit statement of when to prefer this over web_search_read or web_fetch, nor any exclusions. The mention of 'no API key' and region/time filters hints at context but does not route the agent between alternatives.

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?

With no annotations, the description carries the full burden and does substantial work: it discloses the return shape (top 1-5 pages, main content only, title/URL/date/prompt-injection verdict), that fetching happens in parallel at Cloudflare's edge, and that each call costs $0.01 via x402/USDC. It does not explain failure modes, timeouts, or how the x402 payment step is actually satisfied, which keeps 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?

The capability and output shape are front-loaded in the first two clauses, followed by supporting details. It is a single dense paragraph with minor marketing filler ('Everything an agent needs to answer with sources') that could be cut without loss.

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 3-parameter tool with no annotations and no output schema, the description covers output format, cost, and the notable prompt-injection verdict, which is what an agent most needs to call it correctly. The residual gap is the payment prerequisite (x402/USDC) being stated as a price without explaining the flow an agent must 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. It explains the 'top' parameter indirectly ('the top 1-5 results'), but 'q' and especially 'max_chars' get no semantic explanation — what max_chars bounds, per page or total, and default behavior are all left to guesswork.

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

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

The description names a specific compound verb+resource: 'Web search + read top pages ... in one call', and clarifies it returns clean markdown with per-page metadata. The phrase 'in one call' implicitly separates it from the search-only (web_search) and read-only (web_read/web_fetch) siblings, but it never names them, so an agent must infer the boundary.

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 stated use case ('for RAG / answers with sources') gives a clear implied context, which is enough to know roughly when this tool fits. However, there are no explicit when-not conditions and no named alternative for cases like 'I only need links' (web_search) or 'I already have a URL' (web_read/web_fetch).

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?

With no annotations, the description carries the full burden and does disclose meaningful traits: it is Base-chain and real-time, returns a summary plus a nodes/edges graph, and costs $0.01 per call via x402 in USDC. It does not state error behavior, caching, or whether the call is strictly read-only, which keeps 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?

The single-sentence profile is front-loaded with the resource and expands into a clean enumeration of data returned. It is dense but every clause adds coverage; the trailing price note is useful 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 tool with no output schema and no annotations, the description does well on return content (summary plus graph) and operational context (chain, real-time, price). However, the three parameters remain undocumented, which is a real gap for an agent constructing the call.

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% across three parameters. The phrase 'upstream funding up to 3 hops' loosely corresponds to the depth parameter, but the description never explains 'days' or 'address', and it does not tie the hop limit to the schema constraint (minimum 1, maximum 3).

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

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

The description names the specific resource (x402 payer wallet profile) and enumerates the contents: purchases, behavior classification, funder, sibling wallets, and upstream funding. It implicitly separates payer profiling from the seller-oriented siblings (check_x402_seller, x402_seller_customers) but never names an alternative 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?

Usage is only implied by the 'x402 wallet tracker / payer profile' framing and the inclusion of 'Base, real-time.' There is no explicit guidance on when to choose this over solana_wallet_profile, crypto_address_risk, or the seller-side tools, nor any stated exclusions or prerequisites beyond the x402 payment model.

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?

No annotations are provided, so the description carries the full burden. It does disclose useful behavior beyond structure: it is real-time, Base-chain scoped, and costs $0.01 per call via x402/USDC. It does not say whether payment failure aborts the call, what the window defaults are, or any rate/size limits, which are meaningful gaps for a paid 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?

Single dense sentence block with the resource and output fields front-loaded, followed by input guidance and pricing. Every clause carries information; the parenthetical classification list is compact rather than padded.

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

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

With no output schema and no annotations, the description must describe returns, and it does: calls, USD, first/last seen, classification buckets, and daily revenue. Pricing and data freshness are included. Only the `days` default/limits and error behavior are left unstated.

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 2 parameters. The description compensates for `seller` by naming accepted forms (payTo address, endpoint URL, or host), which is genuinely helpful. `days` is only obliquely covered via 'every payer in the window' and 'daily revenue'; the default window and max range are never stated.

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: every payer of a given x402 seller, with calls, USD, first/last seen, an activity-based classification, plus daily revenue. That is far more than a restatement of the name. It does not explicitly name how it differs from siblings like x402_payer_profile or check_x402_seller, so sibling differentiation is only implied by the 'all payers, daily revenue' framing.

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?

'Who pays an x402 seller (know your agent customers)' implies the use case, and 'Give a payTo address, endpoint URL or host' tells the agent what to supply. However there is no explicit when-to-use vs when-to-use-a-sibling guidance, and no note on how this differs from x402_payer_profile, which is the obvious alternative.

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