Agent Kiosk — 23-in-1 B2A Intelligence, Action & x402 API

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds real behavioral value by naming the upstream sources and enumerating returned data (citation counts, reconstructed abstracts, OA PDF links) in the absence of an output schema. It does not mention the masked-vs-unmasked dataset tiering, though the schema params do.

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, and the core purpose is front-loaded in the first clause. Every phrase (sources, return fields) 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?

For a 4-param read-only search tool with full schema coverage and rich annotations, the description is nearly sufficient; it covers purpose, sources and returns. It omits the paid/unmasked tier distinction and any note on result freshness or rate limits, which would round it out.

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

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

Schema description coverage is 100%, with limit, query, x_api_key and payment_signature all documented in-schema, so the baseline is 3. The description adds no parameter syntax or default details 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 (Queries) and two named resources (OpenAlex, arXiv), plus what it returns (citation counts, abstracts, authors, OA PDF links). This clearly separates it from siblings like social_search, web_extract, or b2b_company_dossier.

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?

"Deep scientific & academic research tool" implies the domain of use, and the query examples hint at suitable inputs, but there is no explicit when-to-use/when-not-to-use framing and no alternative tool is named. 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds a genuinely decision-relevant behavior that structured fields do not carry: the $0.10 USDC cost per call. It stops short of describing the masked-vs-unmasked result behavior (only implied via the schema's x_api_key/payment_signature descriptions), but the pricing disclosure is real added value.

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

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

Two sentences, value proposition front-loaded with price, components enumerated second. Nothing is wasted and the ordering is sensible for quick scanning. Marketing phrasing ('Complete 4-in-1') is mild and does not obscure the content.

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?

The schema fully documents parameters and annotations cover safety, so the basics are present. But for a composite, payment-gated tool with 5 params and no output schema, the description omits the key operational nuance an agent needs: that results are masked unless a prepaid pass or x402 payment is supplied, and how this overlaps the individual sibling tools. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters (domain, company, location, x_api_key, payment_signature). The description adds no parameter-level meaning beyond that; at best 'local business contact/phone leads' loosely hints at the location parameter. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a concrete deliverable (B2B sales/competitive intelligence dossier) and enumerates the four data domains it aggregates: DNS/MX/SaaS tech stack, website extraction, local contact/phone leads, and social mentions. An agent can form a clear picture of the output. However, it never distinguishes itself from the sibling tools that perform these same tasks individually (domain_intel, web_extract, maps_leads, social_search), so differentiation is missing.

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 guidance on when to pick this bundled dossier versus calling the individual sibling tools (domain_intel, maps_leads, web_extract, social_search) that cover the same ground. No prerequisites, no exclusions, no alternative routing. The agent is left to infer usage entirely.

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

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

The description's core verb is 'Mint' a purchasable pass and 'buy' (per the tool name), i.e., a creation/purchase action with a real financial side effect ($5.00 USDC). The annotations declare readOnlyHint=true, which asserts the tool does not modify its environment — a direct contradiction of what the description says it does. An agent trusting readOnlyHint would be misled into believing the call is a side-effect-free read.

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

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

Two sentences, front-loaded with the concrete action, price, chain, and mechanism, followed by the value proposition and audience. Every sentence earns its place, though the trailing parenthetical platform list leans slightly promotional rather than informational.

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 no output schema, the description should convey what the call yields; it partially does so ('ak_live_...' key, 30-day validity, X-API-KEY usage). It omits what the response actually contains beyond the key (e.g., expiry fields, error behavior on payment failure), but it is otherwise complete for the tool's complexity.

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

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

Schema description coverage is 100%, so all three parameters (x_api_key, agent_name, payment_signature) are already documented in the schema. The description mentions the 'X-API-KEY header' and the absence of 'per-call x402 signing', which loosely relate to the parameters, but adds no format or required/optional semantics beyond what the schema provides — the baseline 3 applies.

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

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

The description names a specific verb and resource — 'Mint a 30-Day Prepaid API Key Pass (ak_live_...)' — with concrete cost and chain ('$5.00 USDC on Base via x402'). It is clearly distinguishable from every sibling, which are per-call intelligence tools, since this is the sole purchase/credential-mint tool in the set.

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

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

It gives a clear usage context — 'ideal for LangChain, n8n, Make.com, OpenAI Actions, and Python/JS bots' — and implicitly contrasts with per-call usage ('without per-call x402 signing'). It does not, however, explicitly state when to prefer per-call payment over this pass, or name a specific sibling alternative, so it stops short of a full when/when-not statement.

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 annotations already covering readOnly/idempotent/non-destructive, the description adds real behavioral value: the $0.05 USDC cost, the specific screening providers and chain coverage, and the pre-transfer timing. It does not clarify the masked-vs-unmasked default result behavior, which is left to the parameter descriptions.

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

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

Two dense sentences with the core capability and cost front-loaded and no wasted filler. Slightly marketing-toned ('Institutional') but efficient and well-ordered.

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?

Annotations cover the safety profile and the schema covers inputs, but with no output schema the description never indicates what a screening returns (score, flag, report) or how masked vs unmasked output differs. For a paid, gating tool that is a meaningful omission.

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

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

Schema description coverage is 100%, so the schema already documents address, x_api_key, and payment_signature, including the masked/unmasked unlock semantics. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (screens) and resource (0x EVM address) plus the concrete checks performed (AML, OFAC sanctions, phishing, mixer, malicious counterparty) and the data sources (GoPlus Security Base + Ethereum, 4-chain RPC). It is clearly distinguishable in intent from security_audit or wallet_profiler, though it never names a sibling to sharpen 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 phrase 'before autonomous agents execute transfers' implies the trigger context, which is useful, but there is no explicit when-to-use vs alternative guidance and no when-not conditions. Usage must be inferred from the pre-transfer framing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds real value beyond that: a $0.05 USDC cost, the specific return payload shape, the supported chains, and the aggregator sources. It stops short of explaining rate limits or what the masked vs unmasked dataset difference means operationally.

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, cost, and return contract. Slightly packed with branded terminology, but nothing is wasted.

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

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

With no output schema, the description usefully enumerates the returned calldata fields and supported networks, and it flags the payment mechanics. It leaves the interaction between x_api_key/payment_signature and the paid $0.05 call somewhat implicit, but the essential call context is present.

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

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

Schema description coverage is 100%, so every parameter is already documented, and the description adds no per-parameter syntax beyond restating the supported chains. Baseline 3 is appropriate when the schema carries the parameter burden.

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 precise verb chain (queries aggregators, computes best route, returns calldata) and names the concrete resource: ready-to-sign EVM transaction calldata. The mention of LI.FI and ParaSwap plus the exact returned fields (to, data, value, gasLimit) clearly distinguishes it from siblings like defi_yields or evm_tx_simulator.

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?

Implies usage (build a swap/bridge route for signing) and surfaces the cost and payment/API-key unlock path, but never states when to pick this over evm_tx_simulator or how the quote flows into execution. No explicit when/when-not or named 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only the DeFiLlama provenance; it omits notable behavior such as the masked free dataset versus the paid/unmasked unlock path, which lives only in the parameter descriptions.

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, front-loaded with the capability and followed by the filtering scope. Minimal waste; phrasing is slightly marketing-flavored ('radar', 'powered by') but still informative.

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

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

For a read-only query tool with all six parameters fully documented in the schema and a complete safety annotation set, the definition is sufficient. The free-vs-paid data masking nuance is covered by the schema parameter descriptions, so the omission from the prose is minor.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's token examples (USDC, ETH, USDT, WBTC) and the chain/TVL filter mention largely restate what the schema already documents, adding no syntax or default guidance beyond it.

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

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

States a specific verb ('Finds') and resource ('top lending and liquidity pools') plus the data source (DeFiLlama), which cleanly separates it from siblings like defi_swap_quote or token_alpha. It does not explicitly name a sibling to avoid, but the resource is unambiguous.

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 when it is relevant ('for any token... filtered by blockchain and minimum TVL') but never states when to prefer it over alternatives or any prerequisites. Usage is inferable rather than spelled out.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint, so the safety profile needs no repetition. The description usefully discloses what is actually returned (resolved records, provider, tech stack, RDAP dates, subdomains), which annotations do not cover. However, it never mentions the masked-vs-unmasked output behavior or rate/credit costs that the schema's payment parameters imply, which is material behavior for this 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 sentences, front-loaded with the domain-scope summary followed by a compact capability list. Every clause earns its place by naming a distinct output. Slightly list-heavy but 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?

With no output schema, the description carries the return-value burden and does so by enumerating the five result categories. Combined with annotations covering the safety profile and fully documented parameters, an agent has what it needs to call it correctly; only the paywall/masking behavior is left to the schema fields.

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

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

Schema description coverage is 100%, so the domain, x_api_key, and payment_signature parameters are already documented with examples and the 'unmasked dataset' semantics. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

The description names a specific resource (B2B company & domain infrastructure) and enumerates concrete operations: DNS records (A, MX, TXT, NS), email provider identification, SaaS tech-stack detection, RDAP registration dates, and subdomain discovery. That is well beyond a restatement of the name and separates it from siblings like security_audit or b2b_company_dossier. It stops short of explicitly distinguishing itself from those overlapping siblings (e.g., b2b_company_dossier).

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 when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternative tools. The agent is left to infer that this is the DNS/infrastructure recon tool and that b2b_company_dossier or security_audit cover adjacent needs. Nothing routes the agent between this tool and the sibling that unlocks unmasked results.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and the description is consistent with it. Beyond that, the description adds genuine context: the $0.005 USDC cost, the x402 payment path, and the eth_call/eth_estimateGas mechanism, all of which help an agent understand the operation's nature and cost.

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

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

The core purpose is front-loaded, which is good, but the first sentence is a dense keyword-stuffed list of five capabilities plus a price tag that reads more like marketing than specification. The second sentence is tighter and more informative, but overall the structure sacrifices clarity for feature enumeration.

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

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

With no output schema, the description carries the burden of explaining return values, yet it never describes the shape of the simulation result, gas estimate, or decoded revert reason. Annotations cover safety and parameters are fully documented, but for a simulator tool the absence of any output description is a meaningful gap.

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

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

Schema description coverage is 100%, so the schema itself documents all ten parameters thoroughly. The description only loosely connects capabilities (allowance checker → token/spender, multi-chain → chain) but adds no syntax or format detail beyond what the schema already provides, 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 states a specific verb+resource ("Pre-flight EVM Transaction Simulator") and adds recognizable sub-capabilities (gas estimation, revert decoding, allowance checking, proxy detection). It also names the RPC methods used and the supported chains, making it distinguishable from siblings like wallet_profiler or defi_swap_quote. The keyword-stuffed feature list slightly blurs the single primary purpose, keeping it from 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?

"before signing" implies the usage context (pre-flight check ahead of submitting a transaction), which is useful. However, there are no explicit when-not conditions and no routing guidance against sibling tools such as defi_swap_quote (which also touches on swaps) or wallet_profiler. Usage is only implied, not stated.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the safety profile is handled. However, the description omits a significant behavioral trait visible only in the schema: results are masked unless an x_api_key or payment_signature unlocks the full dataset. With annotations carrying safety, a 3 is appropriate given the undisclosed paid/masked tier.

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

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

Two tight sentences, front-loaded with the resource and scoping the two modes in the second. Zero filler, though it is short enough that it could carry one more line of operational context at little cost.

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

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

For a read-only open-world intel tool with no output schema, the description is workable but leaves gaps. It hints at returns ('metrics and latest releases') but never addresses the masked-vs-unmasked dataset distinction or rate limits, which an agent calling this paid-tier tool would benefit from knowing.

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

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

Schema description coverage is 100%, so the schema already documents query, limit, and the two payment parameters. The description reinforces the dual interpretation of `query`, which is useful, but adds no syntax or format detail beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb/resource: GitHub repository and open-source competitive intelligence, and immediately names the two operating modes (owner/repo metrics vs. topic discovery). It is clear and distinguishable from siblings like domain_intel or package_audit, though the 'competitive intelligence' framing is slightly glossy.

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

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

Explicitly tells the agent how to select each mode: pass 'owner/repo' for deep metrics/releases, or a keyword topic to find fastest-growing repos. That is clear usage context, but it offers no when-not guidance or named alternatives among the sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the cost signal ($0.015 USDC), which is useful context, but it does not explain the masked/unmasked gating behavior or how the paid unlock flow works beyond what the schema already says.

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?

It is a single run-on sentence that front-loads the core purpose but is heavily keyword-stuffed ('Unified ... Aggregator and Cross-Venue Probability Spread / Arbitrage Scanner'). It is compact but the noun-piling reduces clarity rather than earning each word.

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 annotations fully cover the safety profile and the schema fully documents all four parameters (including the paid-unlock flow), the description is complete enough for an agent to decide and invoke. No output schema exists, but return masking is described in the schema, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents query, limit, x_api_key, and payment_signature fully. The description adds no parameter-level meaning (no syntax, ranges, or interaction notes), so the baseline 3 is appropriate.

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

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

The description states a specific action (aggregating prediction markets and scanning for cross-venue probability spreads/arbitrage) across named venues (Kalshi, Polymarket, Manifold). This is clearer than a tautology, but it never distinguishes itself from the sibling 'prediction_markets' or 'perp_funding_arbitrage', so an agent cannot easily tell which scanner to pick.

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 when-to-use or when-not-to-use guidance. With a sibling named 'prediction_markets' and another arbitrage scanner ('perp_funding_arbitrage'), the description should explain what situation selects this tool, but it offers nothing beyond a label.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds genuinely useful behavior beyond them: per-call pricing ($0.002 USDC), settlement via x402 on Base, and no account or API key required. It leaves out latency/rate-limit behavior, but the payment and auth traits are the important disclosures here.

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 tightly packed sentences with the core purpose front-loaded and payment/access details following. No filler; every clause carries information.

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

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

With no output schema, the description could have clarified the returned completion format, which it omits. However, it covers purpose, cost, auth, and the payment mechanism adequately, and safety is carried by annotations, so an agent has enough to invoke it correctly. The odd 'unmasked dataset' phrasing in the schema slightly muddies intent.

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

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

Schema description coverage is 100%, so the schema already documents model, prompt, messages, x_api_key, and payment_signature. The description's mention of zero-account access and x402 settlement lightly reinforces the optional auth params but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific resource and framing: an OpenAI-compatible LLM chat completions gateway, explicitly a drop-in replacement for /v1/chat/completions. An agent can immediately tell this generates model completions and is distinct from the data-intel siblings.

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?

No when-to-use, when-not, or alternative selection guidance. It implies a chat-call scenario but never routes the agent against send-a-prompt vs. some other tool, and gives no preconditions beyond the payment rail.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully lists returned fields (compensating for the absent output schema) but omits the significant behavioral fact that results are masked unless an x_api_key or payment signature is supplied — that gating lives only inside the parameter descriptions.

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

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

Two tight, front-loaded sentences with no filler; the verb and resource lead, and the field enumeration follows. "In any city worldwide" is mildly redundant with the location parameter.

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?

Listing the extracted fields partially compensates for the missing output schema, which is good. However, a paid, gated-data tool with no output schema should disclose the masked-vs-unmasked behavior and any cost implication in the description; leaving that to a parameter description leaves a real gap for an agent deciding whether 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?

Schema description coverage is 100%, so the schema already documents query, location, limit, and the two payment-key parameters. The description mentions only output fields, adding nothing about parameter syntax or format beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource: find local businesses/companies/places, and enumerates the extracted fields. It implies the lead-generation niche, which separates it from b2b_company_dossier and social_search, but it never names or contrasts those siblings directly.

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 lead generation and verification" hints at the intended use case, but there is no guidance on when to pick this over b2b_company_dossier, domain_intel, or web_extract, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description usefully adds the OSV.dev dependency and the scope of what is checked (vulnerabilities, deprecation, latest version), but it never discloses that results may be masked unless a paid key/signature is supplied — a material behavioral trait relegated to the parameter descriptions.

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

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

Two sentences, zero filler, front-loaded with the core identity and then the data source and coverage. Nothing is repeated from the title or schema.

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

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

With no output schema, the description does supply the return scope (vulnerabilities, deprecation status, latest stable version), which is the main thing an agent needs. It stops short of explaining result masking / paid-unlock behavior, so a small but real gap remains for a tool with payment-gated output.

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

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

Schema description coverage is 100%, so name, version, ecosystem, and the two payment parameters are fully documented in the schema itself. The description only restates the ecosystem set already enumerated in the schema and adds no syntax or default nuance beyond it, making the baseline 3 appropriate.

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

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

States a specific verb and resource — scanning npm/PyPI/crates.io packages for CVEs — and names the backing data source (Google OSV.dev). The combination of 'package' scope plus the declared ecosystems separates it cleanly from the broader security_audit sibling without needing to open either schema.

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

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

The phrase 'for coding agents' implies a usage context, and the listed ecosystems imply what can be audited, but there is no explicit when-to-use versus when-not, nor any pointer to alternatives like security_audit or compliance_check. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely non-redundant context: a per-call price of $0.008 USDC and the existence of a masked free tier that an API pass or EIP-3009 payment signature unlocks. It does not explain what the masked result omits, which keeps it out of 5 territory.

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

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

It is a single front-loaded sentence, which is structurally fine, but it is dense keyword-style copy ('Open Interest & Crowded Positioning Radar') with marketing cadence rather than tight prose. Every clause is topical, but the wording could be leaner.

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, but the description enumerates the key returned metrics (APR basis spread, open interest, crowded positioning), so an agent knows the payload shape. Annotations cover safety, and all parameters are documented in the schema, so the definition is largely complete; only return granularity/pagination and the masked-vs-unmasked difference are unspecified.

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

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

Schema description coverage is 100%, so limit, symbol, x_api_key, and payment_signature are already fully documented in the schema. The description adds no additional parameter semantics beyond echoing the pricing/unmasking concept. Baseline 3 applies.

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

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

Names a specific resource (cross-exchange perpetual funding rate arbitrage across Hyperliquid and dYdX v4) and enumerates the returned metrics (annualized basis spread APR, open interest, crowded positioning). This clearly distinguishes it from siblings like defi_yields, kalshi_polymarket_arb, and prediction_markets, which cover different venues/instruments. It stops short of 5 because it is a noun-phrase label rather than a stated verb+action.

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

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

There is no statement of when to use this tool versus alternatives such as defi_yields or kalshi_polymarket_arb, and no exclusions or prerequisites are given. The only implicit guidance is the price tag and the parameter descriptions, which is 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds useful context about the data returned (live odds, real-money implied probabilities), but omits behavioral traits like the masked-vs-unmasked dataset, rate limits, or latency, which live only in the parameter descriptions.

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

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

A single dense sentence that front-loads the verb, the resource, and the sources with no filler. Every clause earns its place.

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

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

There is no output schema, so the description must carry return-value meaning, and it does say what comes back (odds and implied probabilities in %). With full schema coverage on inputs, only the masking/unmasked-data nuance is left implicit.

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

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

Schema description coverage is 100%, so all four parameters (limit, query, x_api_key, payment_signature) are already documented. The description adds no parameter-level meaning (no default behavior, no note on what unlock actually reveals), so the baseline 3 applies.

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

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

States a specific verb ('Query') and resource ('live prediction market odds & real-money implied probabilities') with named data sources (Polymarket, Manifold Markets). However, it never distinguishes itself from the sibling kalshi_polymarket_arb, which also touches Polymarket, so the agent has no in-description cue about which to pick.

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: 'for any crypto, macro-economic, political, or technology event' sketches the topic scope, but there is no explicit when-to-use, when-not-to-use, or named alternative. The overlap with kalshi_polymarket_arb goes unaddressed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context by naming the external data providers (GoPlus & DexScreener) and the risk categories checked. It omits a materially important behavior: results appear gated/masked unless an API pass or x402 payment is supplied, which the description never mentions.

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 no filler, and the dual-mode scope is front-loaded in the first clause. The opening 'AI agents' framing is slightly promotional but costs little.

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

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

With no output schema, the description carries the burden of describing what an audit returns (risk score, per-check findings, masked vs unmasked data) and it does not. It is otherwise complete about inputs and scope, but the missing result-shape and paid-unmask behavior leaves a real gap for a tool whose value depends on interpreting output.

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

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

Schema description coverage is 100%, so all four parameters, including the enum-constrained chain and the optional x_api_key/payment_signature unlock semantics, are already documented in the schema. The description adds no parameter-level detail beyond that baseline, so a 3 is appropriate.

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

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

Names a specific verb ('audits') and two concrete resource types (0x contract/token addresses, https URLs), and enumerates the checks performed (honeypot, buy/sell tax, mintable, DEX liquidity, phishing, drainers, prompt injection). An agent grasps the scope immediately. It stops short of distinguishing itself from overlapping siblings like token_due_diligence or package_audit, so 4 rather than 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-flight' implies the moment of use (before transacting with a token or visiting a URL) and the dual target types imply target-based routing. However, no explicit when-not conditions or alternatives are named, so the agent must infer whether this beats token_due_diligence or compliance_check for a given request.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description usefully adds return-format context (structured JSON and LLM-ready Markdown) and the absence of rate-limit blocks, but it omits the significant behavioral detail visible in the schema: without a pass or payment signature the dataset is masked, which materially changes what the agent gets back.

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

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

Two sentences, front-loaded with the capability and followed by the output/benefit claim; nothing is redundant. The second sentence leans promotional ('without rate-limit blocks or API keys') and partially oversells relative to the schema's paid-unmasking parameters, which slightly undercuts its value.

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

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

For a 5-param, read-only search tool with no output schema, the description covers what the tool does and roughly what it returns. However, it never explains the free-vs-unmasked distinction that the x_api_key and payment_signature parameters introduce, so an agent cannot tell when it must acquire a pass to get complete 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?

Schema description coverage is 100%, so limit, query, platform, x_api_key and payment_signature are all documented in the schema. The description adds no parameter-level detail (e.g., no hint that the key/signature parameters gate the unmasked data), so the baseline 3 applies.

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

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

States a specific verb (search) plus resource (live social media discussions) and enumerates the sources (Reddit, HackerNews, tech forums), so it is distinguishable from academic_search and github_intel in spirit. It stops short of explicitly naming what makes it different from those siblings, so it lands just under the top band.

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 when-to-use or when-not-to-use guidance and no mention of the obvious alternative tools (academic_search, web_extract, github_intel). Usage is only implied by 'any topic, product, or trend', leaving the agent to infer routing on its own.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the analytical content but omits the key behavioral trait that results are masked unless an x_api_key or payment_signature unlocks the full dataset (that lives only in the schema).

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

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

Two tight sentences that front-load the purpose and then enumerate the metrics. The leading tagline is slightly marketing-flavored, but no sentence is wasted.

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

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

For a read-only, no-output-schema tool, the description conveys what is analyzed, which is the main thing an agent needs. The payment-gated masking behavior is a notable omission but is covered by the schema's x_api_key and payment_signature parameters.

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 all four parameters are already documented in the schema. The description's 'token ticker or contract address' maps to query but adds no syntax or format detail beyond it, so the baseline of 3 applies.

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

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

States a specific verb ('Analyzes') and resource (buy vs. sell pressure, liquidity depth, volume velocity, FDV, top DEX pools) scoped to a token ticker or contract address. An agent can tell it produces order-flow analytics, but nothing distinguishes it from sibling token_due_diligence or whale_alpha_radar.

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?

No when-to-use, when-not-to-use, or alternative routing is given. 'For any token ticker or contract address' defines scope, not selection guidance, so the agent must infer when this beats token_due_diligence.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds meaningful non-structural context: a $0.10 USDC cost and the composite A-F output, both of which shape invocation decisions. It does not itself explain the masked-vs-unmasked dataset behavior, but that is carried in the schema.

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

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

Two dense sentences with the value proposition (the composite deliverable and its sources) front-loaded. Little waste, though the parenthetical pricing/grade details slightly compress into the same block.

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

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

With no output schema, the description adequately conveys the return shape (a composite A-F investment grade synthesized from three named sources) plus cost. For a 4-param tool with full schema coverage, this is complete enough to call correctly.

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

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

Schema description coverage is 100%, so the schema already documents query, chain, x_api_key, and payment_signature. The description adds no parameter-level syntax or format detail (e.g., chain defaults, symbol vs address handling). Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific deliverable ('Institutional 3-in-1 Token Due Diligence Report') and enumerates its three components: GoPlus security audit, DexScreener order-flow/liquidity, and Reddit/HN sentiment producing an A-F grade. This is clear and specific. However, it does not differentiate from overlapping siblings like security_audit (on-chain audit) or token_alpha (DEX/alpha), so an agent must infer the distinction.

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 deliverable (reach for this when you want a composite due-diligence grade on a token), but no explicit when-to-use, when-not-to-use, or named alternatives are given. It also fails to route the agent between this and the overlapping security_audit/token_alpha siblings.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld. The description adds genuinely useful behavioral context beyond that: a per-call price ($0.008 USDC), and that the dataset is masked unless unlocked via x_api_key or payment_signature. What it omits is rate limits, latency, and whether unmasked results differ structurally.

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?

It's a single dense sentence with the price front-loaded in parentheses and the payload enumerated after—efficient and skimmable. The long enumeration of ten market signals is arguably padding, but each name is informative rather than marketing fluff, so it mostly 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?

For a read-only, no-output-schema tool with three optional params, the description covers what is returned (the enumerated signals), the cost, and the masking/unlock mechanism. It's sufficient to decide whether to call it. It lacks focus-mode return differentiation and any note on data freshness or update cadence.

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

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

Schema description coverage is 100%, so the schema already documents focus, x_api_key, and payment_signature. The description mentions the paid/unmasked gating concept but adds no format or syntax detail beyond the schema (e.g., no guidance on paying without a key). Baseline 3 applies when the schema carries the parameter burden.

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 enumerates concrete data sources (S&P 500, Nasdaq, VIX, DXY, 10Y yield, Gold, WTI, Fear & Greed, BTC dominance, DeFi TVL), which makes the verb+resource unambiguous. It's clear this is a macro/market-data feed. Sibling differentiation is weak, though—nothing explicitly distinguishes it from defi_yields or prediction_markets beyond the enumerated metrics.

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 when-to-use guidance, no alternates named, and no conditions under which this tool should be preferred over defi_yields, token_alpha, or whale_alpha_radar. The 'focus' enum hints at scoping, but the description never states when to pick tradfi vs crypto vs defi focus.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful output-scope detail (live balances, tier, contract detection), but says nothing about rate limits, masking behavior, or what happens without a key — the paid/unmasked aspect only appears in the schema, not the description.

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 tightly packed sentences with zero filler; the chain scope is front-loaded and the return fields follow. Every clause carries information.

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

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

With no output schema, the description correctly carries the burden of describing return values, and it does so thoroughly (balances, nonce, tier, contract detection). It falls short only on operational context such as masking defaults or rate limits, which would help an agent interpret 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?

Schema description coverage is 100%, so the address, x_api_key, and payment_signature parameters are already fully documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description names a specific verb (profiler) and resource (multi-chain wallet portfolio) and enumerates exactly what it returns: USDC/native balances, nonce/outgoing tx counts, wallet tier, and contract-vs-EOA detection. It is clearly a wallet-intelligence tool, though it does not explicitly differentiate itself from the sibling whale_alpha_radar.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as whale_alpha_radar or token_due_diligence. The agent is left to infer that this is the tool for a single-address profile rather than an aggregate whale feed.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower; the description still adds a genuine behavioural trait by disclosing that pages are scanned for hidden prompt-injection traps, which is non-obvious and changes how an agent should treat the returned text. It omits that output may be truncated/masked unless a paid key is supplied, though the schema touches on that.

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 sentence, front-loaded with the primary action and output format, with the secondary injection-scanning clause appended. No filler or restatement of the tool name.

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

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

For a read-only fetch tool with full schema coverage and no output schema, stating the return format (Markdown) plus the injection-scan behaviour is nearly sufficient. The remaining gap is that the masked/unmasked payment gating and any truncation caveats are only implied through the schema, not called out in prose.

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

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

Schema description coverage is 100%, so url, x_api_key, max_length and payment_signature are already documented in the schema and the description adds nothing about them (no default, range, or gating explanation). Baseline 3 applies when the schema carries the parameter burden.

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 (extract) plus resource (any web URL) plus the exact output form (clean, LLM-ready Markdown), with a secondary capability (prompt-injection scanning) named. No sibling tool performs generic URL extraction, so an agent can place this correctly without opening the schema.

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

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

The description never says when to use this tool versus the specialised retrievers in the sibling set (academic_search, social_search, domain_intel, github_intel), nor does it state prerequisites. Usage is only inferable from the name and verb — no explicit routing or exclusion guidance is given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: a $0.10 USDC cost and the fact that x_api_key or payment_signature unlock a full unmasked dataset, which matters for output fidelity. It stops short of describing what the masked default returns.

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 content is packed into a couple of dense sentences that are front-loaded with the core capability. The opening marketing-style phrase ('Complete Multi-Chain Whale Portfolio & DeFi Yield Optimizer Report') is somewhat verbose, but overall there is little wasted text.

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

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

With no output schema, the description carries the burden of conveying what the agent gets back, and it does summarize the pipeline (profiling, pool matching, yield projection) plus payment gating. It lacks detail on the report's structure and the difference between masked and unmasked payloads, but it is sufficient to call the tool correctly.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the optional key and payment signature. The description's only added semantic value is the $0.10 USDC cost tied to payment_signature, so the baseline 3 is appropriate.

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

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

The description states specific actions on a specific resource: profiling a 0x wallet across four named EVM chains, matching idle USDC/ETH against DeFiLlama yield pools, and computing projected annual yield. It is clear what the tool does, but it never distinguishes itself from overlapping siblings like wallet_profiler or defi_yields, so an agent cannot tell them apart from this text alone.

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 framing (profile whale wallets and find yield opportunities), and the mention of masked vs unmasked datasets hints at a paid tier. However, there is no explicit when-to-use, when-not-to-use, or comparison against alternatives such as wallet_profiler, so the agent must infer selection.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavior: it is a paid endpoint costing $0.001 USDC on Base Mainnet and tied to x402 v1/v2 settlement, which is material context absent from the structured fields.

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

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

A single front-loaded sentence pairing cost and network up front. It is slightly over-stuffed with promotional adjectives ('Ultra-low-cost', 'round-trip echo endpoint'), but nothing is wasted or buried.

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

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

With no output schema the description should carry the return contract, yet it never says what a successful call returns (echo of message? masked vs unmasked data?). The schema hints at a masked/unmasked distinction that the description leaves unexplained for a 3-param paid endpoint.

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

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

Schema description coverage is 100%, so all three params (message, x_api_key, payment_signature) are already explained in the schema. The description adds nothing about how payment_signature or x_api_key alter behavior, so baseline 3 is appropriate.

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

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

States a specific action (wallet verification ping / payment settlement test / round-trip echo) on a named resource (x402 v2 & v1 on Base Mainnet). The agent can distinguish it from siblings like buy_prepaid_pass or wallet_profiler, though the description piles four overlapping capabilities (ping, settlement test, latency check, echo) into one clause rather than naming a single crisp function.

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 '$0.001 USDC' pricing and 'payment settlement test' phrasing imply this is a cheap connectivity/settlement smoke-test endpoint, so usage is inferable. However it names no alternatives and gives no explicit condition for choosing it over buy_prepaid_pass or a real swap/quote tool.

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