FiatDock

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

Annotations only declare readOnly/openWorld/idempotent, but the description discloses far more: a $0.0045 x402 payment requirement, the 402 challenge on an unpaid first call, the npm package that auto-pays, a 400 for bad addresses and 502 for RPC/GoPlus outages, and the guarantee that neither failure is charged. That is exactly the behavioral context an agent needs before invoking a paid 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?

The description is front-loaded with the cost and the core capability, then the payment mechanics and error codes. It is dense and mostly earns its space, though 'PAID ($0.0045 USDC via x402)' mildly duplicates the title's price and the single dash-heavy sentence packs a lot together.

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

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

An output schema exists so return values need not be spelled out, annotations carry the safety profile, and the description still covers the paid-call flow, the auto-pay path, and both failure codes. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents both the address format and the payment payload envelope, establishing a baseline of 3. The description adds real value on the payment parameter's lifecycle — omit it first, read howToPay.payloadTemplate from the 402, resend on the second call — clarifying the two-step flow beyond the schema 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 (enrich) and resource (any Base address) and enumerates exactly what comes back: EOA vs contract detection, ERC-20 metadata, nonce, ETH/USDC balances, and a GoPlus security verdict. That specificity distinguishes it from sibling lookups like token_safety, eth_balance, or domain_intel without opening 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?

It gives clear context — 'before you trust it,' triaging a counterparty, payout target, or approval spender — which tells the agent when this tool is the right call. It stops short of naming an alternative sibling to use instead when the agent only needs a single balance or token-safety verdict, so exclusions are absent.

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 annotations already provide readOnlyHint and idempotentHint, and the description adds substantial behavioral detail: payment requirement, the 402 challenge flow, automatic payment via the npm package, and no charge on RPC failure. This is valuable context beyond the structured annotations.

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

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

Three tightly written sentences: cost and purpose up front, then the payment flow and failure behavior. Every sentence contributes new 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?

For a one-parameter tool with an output schema, the description covers what is returned, when to use it, how payment works, and what happens on failure. Nothing essential is missing.

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

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

Schema coverage is 100% and the schema's payment parameter description is thorough, explaining the two-call flow. The description reinforces that payment is involved but adds no new meaning beyond what the schema already provides.

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

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

The description states a specific verb and resource: returns the latest Base block number plus timestamp. It also names the intended use as a freshness/liveness probe, which clearly distinguishes it from sibling tools like gas_price or eth_balance.

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 says when to use this tool: 'agents that need to know the chain head'. However, it does not mention alternatives or explicit exclusion cases, so it falls short of a perfect score.

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 richly discloses behavior beyond the annotations: the non-custodial payment flow, the two-call 402 challenge protocol, on-chain settlement to the seller's wallet, the direct forwarding of free listings, and the wallet/signing requirement. There is no contradiction with the annotations, which only indicate non-read-only, open-world 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?

The description is dense and uses imperative framing with step-by-step guidance, which makes it efficient for an agent. It is longer than strictly necessary—phrases like 'the gateway commission is currently waived' are peripheral—but the structure is front-loaded with the core action and each sentence carries operational weight.

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 tool's complexity (two-phase payment, signing, gateway vs. direct forwarding), the description is complete: it covers auth, payment, argument passing, listing ID provenance, and the no-wallet automation path. The output schema covers return values, 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?

The input schema already provides 100% description coverage and detailed parameter docs, so the baseline is 3. The description adds value by weaving the parameters into the operational flow—explaining when `payment` must be omitted/present, how it maps to the X-PAYMENT header, and how `args` is the service-defined request body. This is a helpful amplification rather than mere repetition.

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: 'Invoke a listed FiatDock service.' It then clearly distinguishes paid vs. free/first-party execution paths, so an agent understands both the core action and the two modes of behavior.

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

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

The description gives explicit step-by-step instructions: call once without `payment` to receive the 402 challenge, then call again with `payment` to complete the purchase. It also clarifies that free/first-party listings are forwarded directly without payment, which is a clear usage condition. However, it never names sibling alternatives like `call_x402` or `search_services`, leaving some tool-selection nuance 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 (readOnlyHint=false, destructiveHint=false) already cover the safety profile, and the description goes well beyond them: it discloses the two-call protocol, that money moves directly from the caller's wallet to payTo, that FiatDock charges no fee and never touches funds, and that responses come back as `result` with a settlement receipt. For a tool that triggers real payment, this level of disclosure is essential and fully delivered.

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?

Although long, every sentence earns its place: purpose/scope, buy protocol, no-wallet alternative, response semantics, and reach limitation. The 'TO BUY:' and 'No wallet?' signposts make a complex flow scannable, and the purpose is front-loaded before any procedure. No filler or repetition of annotation 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?

For a high-complexity, financially consequential tool, the description covers everything needed to call correctly: source of inputs (search_x402), the exact two-step payment flow, fee transparency, response shape (`result` plus settlement receipt), and the host scope limit. An output schema exists, so return-value details are available structurally, and the description still gives the key semantic. Nothing essential is missing.

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

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

Schema coverage is 100% and each parameter already has a rich description, so baseline is 3. The description adds genuine protocol-level meaning beyond the schema: it assembles the parameters into a sequence (omit payment → receive 402 → sign one accepts entry → resubmit with payment), clarifies url must come from search_x402, and explains that payment is sent to the endpoint, not read by FiatDock. It earns a 4 but not a 5 because the schema already carries most per-parameter semantics.

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 opener states a specific verb and resource — 'Call a pay-per-call x402 endpoint from the public index' — and immediately separates it from siblings: search_x402 (finding) and call_service (FiatDock listings). The 'any host, not only FiatDock listings' clause makes its scope unmistakable. Nothing about the purpose is left to inference.

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

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

Explicit routing is given in the prose: endpoints come from search_x402, FiatDock listings go to call_service, and the wallet-less path is npx fiatdock-mcp. The 'TO BUY' section lays out the exact call sequence (once without payment, then again with payment). This tells an agent both when to use it and which sibling to pick instead.

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

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

Beyond the annotations, the description discloses payment requirements ($0.01 USDC via x402), the 402-challenge first-call behavior, link expiry (~2 hours), automatic emailing behavior, provider restrictions, and the lack of push status updates. This is rich, non-obvious behavioral context that annotations alone could not convey.

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

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

The description is front-loaded with the core action and return values, followed by payment, compliance, and jurisdictional details. It is dense and long, but nearly every clause carries an operational constraint an agent needs. Some structuring with separators would improve scanability, 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?

For a complex, paid, compliance-sensitive tool with 12 parameters, this description covers the essential workflow, authentication/payment mechanism, return values, exclusions, provider behavior, and fallback polling guidance. Combined with the rich schema and output schema, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful workflow context beyond the schema, especially the payment flow ('OMIT it on the first call... Send it on the second call') and the automatic email behavior for the owner's email. It does not enumerate every parameter, but the schema already provides detailed descriptions for each.

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: 'Convert the agent's USDC to fiat in the owner's OWN bank account.' It clearly defines the output (checkoutUrl, partnerOrderId) and the direction of the operation (USDC → fiat), which distinguishes it from the sibling create_onramp_session without requiring the agent to infer anything.

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 clearly states when to use this tool: when converting USDC to fiat for the owner's own bank account, with explicit compliance exclusions (no third-party funds, no P2P, not available for UK/US/sanctioned countries). It does not explicitly name create_onramp_session as the alternative for the reverse direction, but the title and 'off-ramp' naming make the boundary clear enough.

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 discloses far beyond what annotations provide: it explains the x402 payment mechanism (returns 402 challenge without payment, use npm package), the two-step completion, the fact that nothing is charged for the 402 itself, no callbacks are sent, order status is not push-updated, and the wallet-locking mechanism (walletCode + walletHash). Annotations only indicate non-read-only and non-idempotent; the description adds all the practical behavior an agent needs. No contradiction with annotations.

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

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

The description is long but every sentence carries unique, high-value information—payment flow, compliance, geography, settlement, locking, and error conditions. It is front-loaded with the core function and returns, then expands into operational details. It is not tautological or redundant; the density is appropriate for the tool's complexity. The length slightly exceeds minimal conciseness but is justified.

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 12 parameters, a two-step payment flow, compliance restrictions, and provider-specific behavior, the description covers every critical aspect: the exact call sequence, the parameters' roles, the settlement method, the geography limits, the output expectations (checkoutUrl + partnerOrderId, echoed emailedTo), and the absence of callbacks. The output schema exists to document return values, so the description need not duplicate it. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds significant meaning beyond the schema: it explains the payment parameter's exact role in the two-step flow ('OMIT it on the first call... Send it on the second call'), the provider parameter's constraint ('Any other value returns 400'), the callbackUrl's non-functionality for the current provider, and the walletCode/walletHash relationship. This goes beyond the schema's field-level descriptions, justifying a 4.

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: 'Buy USDC with the owner's OWN fiat and deliver it to the agent's wallet (address locked)' and returns the exact outputs (checkoutUrl + partnerOrderId). It clearly distinguishes from the sibling create_offramp_session by naming the direction (fiat → USDC) and the ownership constraint, so an agent can tell them apart immediately.

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

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

The description provides extensive usage context including the two-step payment flow (omit payment first, use payment on second call), compliance rules (own-account, 18+, geographies), and settlement details (SEPA, provider choice). It does not explicitly name the alternative tool for the reverse operation, but the purpose and conditions are concrete enough that an agent can infer when to use this vs create_offramp_session. The lack of an explicit 'use create_offramp_session instead' costs one point.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: discloses the x402 paid flow, the 402 challenge on the first call, that the 402 and any >=400 error are not charged, that failed post-payment calls settle nothing, that down feeds surface in 'sources', that 404 means no matching headline, and that feed text is data not instructions. That is unusually rich behavioral 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?

Price and paid-tool warning are front-loaded and each paragraph carries information. It loses a point for redundancy: the 'not charged' guarantee is stated three separate times across the description, which could be consolidated.

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

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

An output schema exists, so return-format explanation is not owed, yet the description still sketches the result shape (link, publisher, time, summary) and covers the failure modes an agent will actually hit (402, 404, partial sources). Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: 'every word must appear' for query, the 1-168 hour window framing for sinceHours, and the full first-call/second-call dance for payment (402 carries howToPay.payloadTemplate; sent as PAYMENT-SIGNATURE header, never body data). Only the limit default is left entirely to the schema.

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

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

States a specific verb+resource (latest crypto headlines) plus the exact scope: nine named newsrooms merged, de-duplicated, newest first, with link/publisher/time/summary. No sibling tool in the list covers news, so the agent can select it without cross-checking 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?

Explains the operating context clearly: filter by keywords and a 1-168 hour window, omit query for everything. It also routes the agent to the practical path ('the fiatdock-mcp npm package pays automatically') versus the 402 challenge. It does not name an alternative sibling for news, but none exists to disambiguate against.

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 only declare read-only/idempotent/open-world, but the description discloses behavior annotations cannot: the $0.001 x402 charge, the two-call 402 challenge flow, that failures are not charged, and that statistical outliers are dropped unless includeOutliers is true. That is rich, non-redundant 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?

The paid/402 caveat is front-loaded and every clause carries information, but the second sentence crams filters, output fields, and outlier behavior into a single dense run-on. It is appropriately sized for an 8-param paid tool yet could be parsed more easily.

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

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

Given an output schema exists, return values need not be enumerated, yet the description covers the fields, defaults, outlier handling, payment/error semantics (>=400 not charged), and the auto-paying client. An agent has everything needed to call and pay 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 already 100%, so the schema carries the parameter burden. The description still adds value beyond it by restating defaults (Base, $1M TVL) and by explaining the payment/retry lifecycle and the outlier-exclusion default, which are semantics the enum and type fields alone would not convey.

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 (DeFi yield pools) and the exact question it answers ("Where a token earns the most"), names DefiLlama as the source, and its scope is clearly distinct from siblings like token_price or stablecoin_intel. An agent can select it without reading 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 gives concrete selection context — filter by chain, symbol, stablecoin-only, min TVL, sort by APY/TVL — and notes the default chain and TVL floor, which tells the agent what it gets without arguments. It stops short of naming a sibling alternative or an explicit when-not-to-use condition, so it falls short of a 5.

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

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

Annotations (readOnly/openWorld/idempotent) only cover the safety profile; the description goes far beyond by disclosing the x402 payment flow, the 402 challenge, that a 502 outage is not charged, that any answer it cannot produce is >=400 and uncharged, and the null-registration case for RDAP-less TLDs. This is unusually rich behavioral 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?

Front-loaded with what the tool returns before the payment mechanics, and every sentence carries information. It is a dense single block with no formatting breaks, which slightly hurts scanability but wastes 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?

For a paid, multi-facet tool with an output schema already present, the description covers scope, error/payment semantics, and edge cases. An agent has everything needed to invoke it correctly on both the challenge and payment calls.

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 both parameters are already fully documented in the schema (including the payment envelope details), so the description mostly restates rather than adds. The "accepts a bare domain or a URL" note is already in the schema, making this a baseline 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?

States a specific verb+resource and enumerates the exact facets returned: registrar/dates/status/nameservers from RDAP, live DNS records, SPF/DMARC, and TLS certificate details. This distinguishes it from siblings like email_check, site_contacts, and address_intel at a glance.

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?

"Everything about a domain in one call" clearly frames it as the comprehensive domain tool, and it specifies accepted input forms (bare domain or URL) plus the paid-answer semantics. It gives no explicit when-not or named alternative, so it stops short of a 5.

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

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

The description goes far beyond the readOnlyHint/openWorldHint/idempotentHint annotations by disclosing the paid nature, the 402-challenge flow, charging edge cases (invalid address = paid verdict, DNS failure = 502 not charged), and the absence of an SMTP probe. This is exactly the behavioral context an agent needs for a metered tool. No contradiction with annotations; readOnlyHint is consistent with 'no SMTP probe'.

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 and front-loaded with the critical facts (PAID, purpose) before details. Every sentence earns its place: charging, checks, no-SMTP limitation, error behavior, and payment automation. It is a long single paragraph of compound sentences, which slightly hurts scannability, but there is zero redundancy or 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 paid tool with a two-call x402 protocol, the description is exceptionally complete: it covers what happens without payment (402 challenge), on DNS failure (502, not charged), on invalid input (paid verdict), and what the tool refuses to guarantee (mailbox existence). With an output schema present, the return-value summary (risk verdict with reasons) is also mentioned.

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 both the email and payment parameters are fully documented in the schema itself, including the detailed two-call payment flow. The tool description adds the high-level framing ($0.001, second-call completion), but this largely restates the schema's payment parameter description, so it adds marginal value beyond the structured data.

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 ('check an email address') and enumerates the exact capabilities: syntax, DNS MX/A/AAAA, disposable/role lists, typo suggestion, normalization, and a risk verdict. It clearly distinguishes itself from the blockchain/x402 siblings (eth_balance, token_*, call_x402) by framing the purpose as 'Is this address worth sending to?'.

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 frames the use case clearly ('Is this address worth sending to?') and includes an implicit when-not: 'No SMTP probe: it vouches for the DOMAIN, never the mailbox' instructs the agent that this tool is for deliverability-risk assessment, not mailbox confirmation. No explicit alternative is named, but none of the 21 siblings are email-related, so cross-routing guidance is unnecessary.

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

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

Annotations cover read-only/idempotent/open-world, and the description adds substantial context beyond them: paid x402 flow ($0.0027), 402 challenge not charged, failures >=400 not charged, SSRF-guarded gateway fetches, mainnet public RPCs, off-chain Basename lookup, and that the avatar record is returned raw (not fetched).

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 with purpose and price, and nearly every sentence carries decision-relevant information. It is a single long block that could be better segmented, but there is little filler.

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

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

An output schema exists so return values needn't be described; the description nonetheless covers payment mechanics, error/charging semantics, resolution constraints, and data sources. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it clarifies the dual role of name vs address (either/or resolution), the ASCII constraint, and the full payment parameter lifecycle (omit on first call, send on second, forwarded as header not body).

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 specific verbs and resources: resolving ENS names and Basenames bidirectionally (name→address and address→primary name) plus profile records. No sibling tool does ENS resolution, so the agent can distinguish it immediately.

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

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

Explains the two directions of use, the ASCII-only constraint, and the 404/uncharged behavior for non-resolving inputs. It does not name an alternative sibling, but the use context is clear and the payment flow is 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?

The description clearly discloses the payment requirement (PAID $0.001 via x402), the 402 challenge behavior, the automatic payment by the fiatdock-mcp npm package, and the charging/non-charging behavior on error. It goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) and adds crucial context about payment and error handling. No contradiction with annotations.

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

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

The description is well-structured and front-loads the most critical info (PAID, what it does, what it returns). The payment details are dense but necessary. It's a bit heavy on the payment mechanics, but every sentence serves a purpose. Slightly verbose could be trimmed, but it's efficient for a complex flow.

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 complexity of the x402 payment flow, the description is remarkably complete. It covers the what, how to use, payment nuances, error handling, and charging behavior. The output schema exists, so return format is covered. There's nothing an agent needs to know to call this correctly that's missing.

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

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

Schema coverage is 100% and the description adds significant value. It clearly explains the payment parameter's role: it's a Base64 of an x402 v2 PaymentPayload, when to omit it (first call), what to do with the 402 response (howToPay.payloadTemplate), and that it's forwarded as a header, not body data. The address parameter is also clarified as requiring a 40-hex EVM address. This goes beyond the schema descriptions.

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 the tool reads the native ETH balance of any address on Base, in wei and ETH, and is distinct from USDC balance and other token tools. It names the exact resource (native ETH balance), the network (Base), and the return units, distinguishing it from siblings like usdc_balance and token_price.

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 explicitly explains the two-call payment flow: first call gets a 402 challenge, second sends the payment payload and completes the purchase. It also clearly states when the tool is NOT appropriate or what happens on failure (invalid address returns 400 not charged, RPC failure returns 5xx not charged). It does not explicitly name alternatives, but given the sibling list includes usdc_balance, it implies this is for native ETH only. The payment mechanism guidance is thorough and prevents misuse.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the paid model ($0.001 USDC), the two-call 402 handshake, that failures are not charged, that an unknown currency returns 404 uncharged, and that the fiatdock-mcp package auto-pays. These are exactly the behavioral facts an agent cannot get from structured fields.

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

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

Front-loads the critical facts (PAID, what it returns) and every clause carries information. The nested em-dash constructions make the single dense paragraph slightly harder to parse than it needs to be, but there is little waste.

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

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

With an output schema present, return-value explanation is not required, yet the description still covers output shape, payment protocol, error/charge semantics, and currency coverage. An agent has everything needed to invoke it correctly, including the required two-step payment.

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 `to`, `from`, `amount`, and the payment envelope with defaults and limits. The description reinforces defaults and currency breadth but adds no syntax or format meaning beyond the schema, 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+resource up front: 'Live exchange rates and a conversion,' and defines exactly what is returned (units of each target per unit of `from`, the converted amount, plus the ECB reference rate and deviation). It is immediately distinguishable from siblings like token_price or get_quote.

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

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

Gives clear context for use (fiat+crypto conversion with an independent ECB cross-check) and a scope caveat ('Rates for information, not an executable quote'), which steers the agent away from treating it as a tradeable quote. It does not explicitly name a sibling alternative, so it falls short of the top band.

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 says 'PAID ($0.001 USDC via x402)' and the schema describes an EIP-3009 transferWithAuthorization payment, which is a payment side effect, while annotations declare readOnlyHint=true. This is a direct contradiction: a paid call is not read-only in the usual MCP sense, and the description even notes that a failed call is NOT charged, implying a successful call can charge. Flagged as annotation contradiction.

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

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

Four short sentences front-load the cost first, then the resource and use case, then the payment and failure behavior. Every sentence carries operational 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?

The description covers the resource, units, use case, payment flow, and failure semantics, and an output schema exists so return values do not need to be described in prose. It is only held back because the contradictory readOnlyHint means an agent relying on metadata rather than the description may be misled about side effects.

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 for the single payment parameter is 100%, and the schema already explains omitting it on the first call, sending it on the second, and forwarding it as the PAYMENT-SIGNATURE header. The description adds the automatic fiatdock-mcp payment behavior, but that is operational context rather than new parameter semantics, 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 clearly identifies the resource: the current Base gas price in wei and gwei, and gives the intended use case of sampling before submitting a transaction. It does not explicitly state a verb like 'get' or distinguish itself from sibling price tools such as token_price, so it stops short of full sibling differentiation.

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 provides a clear when-to-use signal: a gas-aware agent samples this before submitting a tx. It also explains the payment flow, including that the first call omits payment and returns a 402 challenge, but it does not mention alternatives or when-not-to-use conditions.

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 (readOnlyHint, idempotentHint, openWorldHint) already convey key behaviors. The description adds no extra details beyond the annotation coverage.

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 sentence, no extraneous words. Front-loaded with the core purpose.

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 strong annotations and output schema, the description is adequate. Could add context about scope (e.g., only for partner orders) but not necessary.

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

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

Schema coverage is 100% with clear parameter description. The description only mentions 'by partnerOrderId', adding marginal meaning to what the schema already provides.

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

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

The description clearly states the action (check status) and resource (on/off-ramp order by partnerOrderId). It is specific, but does not differentiate from sibling tools like create_offramp_session or get_quote.

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 guidance on when to use this tool versus others. It simply describes the function without context of prerequisites or 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?

The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint, openWorldHint). It discloses that the quote is an 'executable estimate, not a locked rate' and explicitly states it provides the net amount after fees. This helps an agent understand the dynamic nature of the quote and that it is not a binding offer.

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 extremely concise: two sentences and a quick note about 'side'. It front-loads the core value proposition ('free quote before paying: exchange rate and net amount') and immediately addresses the estimate nature. Every sentence adds unique value, 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 presence of an output schema (handling return values) and strong annotations, the description covers the key behavioral aspects: net-of-fees display, estimate disclaimer, and side direction. It does not explain conditional parameter requirements (e.g., cryptoAmount required for SELL), but the schema descriptions compensate. Slightly incomplete for a fully contextual description, but certainly adequate.

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

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

The input schema already covers all 5 parameters with descriptions, achieving 100% schema description coverage. The description redundantly explains the 'side' parameter (SELL/BUY) but does not add new information beyond the schema. Baseline score of 3 is appropriate given that the schema carries the 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 clearly states the tool's purpose: providing a free quote with exchange rate and net amount after fees, distinguishing between SELL and BUY directions. It uses specific verbs ('get a free quote', 'executable estimate') and resource ('quote'), which differentiates it from sibling tools like 'create_offramp_session' or 'get_order_status'.

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 before paying ('free quote before paying') and clarifies it is an estimate ('not a locked rate'). However, it does not explicitly state when not to use this tool or suggest alternative sibling tools for other scenarios, such as creating a session. Still, the context is clear enough for an agent to infer primary usage.

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/open-world/idempotent, and the description adds substantial value on top: exact price, the 402-challenge payment handshake, the note that 404s and >=400 failures are not charged, the 1,200-char abstract cap, and the auto-pay npm package. These are precisely the behavioral traits an agent needs before invoking a paid call.

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?

Long but dense with distinct facts (price, sources, return fields, filters, payment flow, billing rules), and the PAID/cost header is front-loaded. A couple of clauses about the payment flow and fiatdock-mcp could be trimmed, but nearly every sentence earns its place.

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

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

Covers purpose, source coverage, return content, filter/sort semantics, and the full payment lifecycle. An output schema exists so return-value explanation is not strictly required, and the parameter schema is fully documented. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema — that citation and date sorts match title and abstract so results stay on topic, and that an empty query searches the published example. It goes slightly beyond restating the schema fields.

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?

Opens with a specific verb+resource ('Search the scholarly literature') and names both upstream sources (OpenAlex ~250M works, Crossref fallback). It enumerates return fields and available filters, so an agent knows exactly what the tool produces without opening the schema. No sibling competes for this purpose.

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 explains sorting defaults and the Crossref fallback, but those are internal behaviors rather than guidance on when to choose this tool over an alternative. With no sibling offering academic search, there is nothing to route against, yet there is no explicit 'use this when…' framing either. Usage context 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 only cover read-only/idempotent/open-world, and the description adds substantial behavioral context beyond them: paid at $0.001 USDC via x402, a 402 challenge without payment, 404 with nearest names for unknown coins, and that any >=400 answer is not charged. It also discloses the two-call payment handshake and that nothing settles on post-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?

Dense but front-loaded, leading with the paid/x402 fact and the returned fields before drilling into edge cases. Slightly redundant with the title's '$0.001' and a long final sentence, but nearly every clause carries operational value.

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

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

For a paid, no-required-param tool with full schema coverage, an output schema, and safety annotations, the description covers everything an agent needs: data returned, default behavior, payment flow, and failure semantics. Nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the Hyperliquid coin naming convention (kPEPE-style), the 24h-volume default when coin is omitted, and the correct payment sequencing (omit payment on the first call, send it on the second). These go beyond what the schema alone states.

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 (Hyperliquid perpetual futures) and enumerates the exact fields returned (mark, oracle, mid price, 24h change, funding rate + APR, open interest, volume, max leverage). It is clearly distinguishable from the spot-oriented token_price sibling, and the cross-venue funding comparison is named 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?

Gives clear usage context: omit coin for the most-traded markets by 24h volume, and pass a named coin to also get next funding on Binance/Bybit for cross-venue comparison. It does not name a sibling alternative to use instead for spot prices, but the when-to-use conditions are 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?

Annotations only declare the safety profile (readOnly/idempotent/openWorld); the description goes well beyond by disclosing the x402 paid flow, the 402 challenge on the first call, auto-payment via the fiatdock-mcp package, and the crucial billing guarantee that failures are NOT charged. That is exactly the behavioral context an agent needs before invoking a paid 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-loads the price and purpose, then packs in return shape, search behavior, and payment mechanics efficiently. There is mild redundancy between 'a query that matches no open market answers 404 and is not charged' and 'any answer the tool cannot produce is >= 400 and is NOT charged,' but both reinforce a billing-critical rule.

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

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

An output schema exists, so return values need no prose. Everything an agent must know to call this correctly — cost, payment handshake, error semantics, billing exclusions, and query behavior — 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema — it clarifies that price is 'the price of one share, 0-1 USDC, read as the market's implied probability' and that the npm package handles payment automatically, which the schema does not state. It does not restate limit/query semantics beyond what the schema already carries.

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 — 'Live prediction markets from Polymarket' — and then enumerates exactly what each record contains (outcome, price as implied probability, 24h/total volume, liquidity, closing date, link). That level of return-field specificity makes it trivially distinguishable from siblings like perp_market or token_price.

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

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

Gives clear operational context: 'Search by topic, or omit the query for the markets with the most 24h volume,' plus an explicit negative case (no match → 404, not charged). It does not name a competing sibling tool to route against, so it stops short of a 5.

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

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

Annotations only cover read/idempotent/openWorld; the description carries the real behavioral load: price ($0.0045 USDC), the 402-challenge-then-pay two-step, the 8,000-character cap, that nothing is stored, that failures >=400 are not charged, and the key caveat that pattern matching means no_known_pattern is not a guarantee.

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 and front-loaded — purpose, then what it detects, then return shape, then caveat, then pricing/payment logistics. Every sentence earns its place, though the payment logistics run long for a description whose schema already covers them.

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

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

An output schema exists, yet the description still names the verdict values and what accompanies them. Combined with the limits, privacy statement, caveat, and payment/error semantics, an agent has everything needed to call it correctly and interpret the result.

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: both `text` and `payment` are already documented with equal or greater detail in the schema. The description's added value here is only reinforcement of the 402/PAYMENT-SIGNATURE flow, not new parameter meaning.

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

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

States a specific verb (scan) and resource (text about to be read) plus the exact threat class it detects: instruction-override phrasing, redefined persona, credential-move requests, hidden tags, invisible Unicode. It is unmistakable against siblings like web_read or email_check, which fetch/parse rather than scan for injection.

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 when-to-use context ('text you are about to read — a fetched web page, an email, a tool description, another agent's message') and explains the paid-call flow. It stops short of naming an alternative or an explicit when-not-to-use, so it is clear context without 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?

Annotations cover only readOnly/idempotent/openWorld, so the description carries the rest and does so richly: pricing ($0.009 USDC via x402), the 402 challenge flow, that a 404/no-scene response is not charged, that failures after settlement settle nothing, and that attribution is always included. This is behavioral context well beyond the structured fields.

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

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

The price and payment status are front-loaded and every sentence is informative, but the single dense paragraph packs payment, licensing, filtering, and error semantics together, which slightly taxes scanning. Efficient overall with minor structural compression.

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, open-world, zero-required-param tool with an output schema, the description covers everything an agent needs: cost, the two-step payment protocol, charging semantics, filter defaults, and error behavior. Nothing essential is omitted.

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

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

Schema description coverage is 100% and the schema already documents ranges, defaults, and even the payment envelope mechanics in detail. The description restates the cloud-limit and look-back defaults but adds no syntax or format meaning beyond what the schema provides, so the baseline of 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 verb+resource combination ('newest satellite images of any coordinate') with concrete provenance (Copernicus Sentinel-2 Level-2A via Earth Search). The scope, resolution, and revisit cadence make it instantly distinguishable from every sibling tool in the list.

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

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

Gives clear context for when the tool applies (fetching imagery at a coordinate, with cloud/look-back filters) and explains the payment branch (first call returns 402, second completes). It does not, however, route the agent to any alternative such as call_x402 or search_x402 for related tasks, so it stops short of explicit when-not guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds context: it is read-only and free, the ranking algorithm is described, and it notes that FiatDock takes no fee and never touches the money. This goes beyond the structured hints and gives the agent a complete behavioral picture.

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 well-structured and front-loaded: the first sentence states the core purpose, then it flows into ranking, row contents, workflow, and the alternative. Every sentence earns its place; no filler or repetition.

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 5 optional parameters and a rich output, the description explains the ranking criteria, the data each row contains, the read-only nature, the follow-up tool, and the difference from the sibling. It provides everything an agent needs to call it correctly and 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 coverage is 100% with detailed parameter descriptions (e.g., q explains scoring, sort lists options, limit explains default and rationale, network gives an example, maxPriceUsd specifies units). The description text adds the overall ranking logic and advice to narrow with q, maxPriceUsd, or network, which enhances the schema but does not repeat it entirely.

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 the tool finds any pay-per-call x402 endpoint on the internet via the public index, with details on ranking and row contents. It explicitly distinguishes from sibling search_services by contrasting the public index with FiatDock's marketplace, so an agent can select correctly without guessing.

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 provides explicit when-to-use guidance: use this for public x402 endpoints, and names the alternative search_services for marketplace listings that include health, schemas, and a call hint. It also explains the workflow with call_x402, so the agent understands the follow-up action.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses the exact price, that an unknown ticker returns 404 and is not charged, that a missing payment yields a 402 challenge, that failed calls after settlement charge nothing, and that the payment header is forwarded out-of-band. This is unusually rich behavioral disclosure for a paid endpoint.

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 and front-loaded with the paid notice and purpose before enumerating return fields and payment mechanics. Every sentence carries information, though the single long paragraph could be broken up for faster scanning.

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

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

With an output schema present, return values need not be re-explained; the description still covers pricing, error/charging behavior, the 402 flow, filtering, and input format. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds meaning beyond the schema: concrete form-type examples (10-K, 10-Q, 8-K, 4, DEF 14A), the 'newest first' ordering implied for limit, and the full semantics of the payment envelope. That extra context lifts it above the schema-only 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?

States a specific verb and resource ('latest SEC filings from EDGAR') with the input key (ticker or CIK), and enumerates the returned fields (form type, dates, accession number, 8-K item codes, sec.gov link, company metadata). No sibling tool covers SEC filings, so this is unambiguously distinct from the crypto/on-chain 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?

Explains how to invoke: provide ticker/CIK, optionally filter by form types, and how the two-call payment flow works (omit payment first, pay from the 402 challenge, or let fiatdock-mcp auto-pay). It does not need to route to an alternative since no sibling overlaps, but it also doesn't state when *not* to use it.

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?

Far exceeds the annotations: it discloses the paid/402 mechanism, that unreadable pages are not charged, that failures after settlement are not charged, that everything unproducible returns >=400 uncharged, that requests pass through an SSRF guard, and that the JS is not executed. These are exactly the behavioral facts an agent needs beyond readOnlyHint/openWorldHint/idempotentHint.

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 pricing/payment constraint is front-loaded and the audit scope is delivered as a dense but scannable enumeration. It is long, but nearly every clause carries distinct information (checks, severity output, payment flow, SSRF).

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, single-input audit tool this covers everything: what is fetched, what is measured, the return shape (issues with severity, raw measurements, 0-100 score), and the full payment lifecycle. An output schema exists, so the description needn't detail return values, yet its brief mention adds clarity rather than redundancy.

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 baseline is 3, but the description adds genuine payment semantics: payment is forwarded as the PAYMENT-SIGNATURE header and never as body data, the first call should omit it, and nothing is charged for the 402 itself. That contextualizes the 'payment' parameter beyond the schema 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?

States a specific verb and resource ('Audit one public web page') and precisely scopes what is examined: served HTML without JS, plus /robots.txt and sitemap. The enumerated check list and the sibling set (web_read, site_contacts, domain_intel) make it easy to distinguish this from other page-oriented 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?

Clear context for when to use it (technical SEO/crawler-view audit of a single public page) and an explicit operational flow: omit payment on the first call, pay via the returned 402 template, or let the fiatdock-mcp package handle it. It does not explicitly name an alternative sibling to use instead for adjacent needs (e.g. web_read for raw content), so it stops short of full when-not 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 only cover safety (readOnly/openWorld/idempotent); the description adds substantial context the agent cannot get elsewhere: personal-looking addresses are never returned (only counted), up to 3 safety-checked redirects, no JavaScript execution, 422 for JS-only pages, and the exact billing semantics (402 unchallenged, failures post-payment uncharged).

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 paid price and core purpose, then layers extraction scope, behavioral limits, and payment mechanics in a tight sequence. Long but every clause carries distinct, decision-relevant 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 an output schema present, return values need no explanation, and the description covers the remaining gaps: pricing, the 402 handshake, redirect limits, JS handling, and the no-charge guarantee on errors. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so the url and payment parameters are already fully documented in the schema. The description restates the payment envelope behavior 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 concrete verb+resource: 'How to reach the organisation behind a website, read from its own HTML,' then enumerates exactly what it extracts (socials, role emails, tel: phones, contact URLs). This scope is unmistakably distinct from web_read, email_check, or domain_intel, though no sibling is named 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?

Gives strong procedural guidance for the two-call x402 flow: omit payment on the first call, read howToPay.payloadTemplate from the 402, send the payload on the second call. It lacks any explicit when-to-use-vs-alternative routing (e.g., vs web_read or email_check), which keeps it short of a 5.

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

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

The description discloses the paid nature, exact price, the 402-challenge response when payment is omitted, and that the fiatdock-mcp package pays automatically. This adds payment/auth behavior far beyond the readOnly/openWorld/idempotent annotations and matches them. It also names DefiLlama as the data source.

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 with no filler: the paid warning is front-loaded, the data scope is compactly listed, and the 402/payment behavior is stated in one final sentence. Every sentence earns its place.

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

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

For a two-parameter tool with an output schema and rich parameter descriptions, the description covers the essential missing context: cost, payment flow, and intended use. Nothing an agent needs to decide whether to call it is missing.

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

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

The input schema already covers 100% of the parameters, so the baseline is 3. The description adds useful context beyond the schema by stating the price, the paid x402 flow, and what data the tool returns (supply, peg, chains), which gives the optional asset and payment parameters operational meaning.

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

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

The description states a specific purpose: assessing stablecoin supply, peg health, and per-chain breakdown for USDC and other stablecoins. It lists exact data points (total supply, peg deviation, Base circulation, top chains), which clearly separates it from price/safety/wallet-balance siblings. The treasury/payments use case adds a concrete operational purpose.

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 explicitly frames when to use the tool: a treasury/payments agent checking whether its settlement asset is healthy. It does not list exclusions or alternatives (e.g., use token_price for market price), so it misses the explicit when-not guidance needed for a 5.

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

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

Annotations already declare readOnlyHint/openWorldHint/idempotentHint, but the description adds substantial context they cannot carry: the $0.0027 x402 price, that the 402 challenge is free, that failures return >=400 and are not charged, and that a failed-after-payment call settles nothing. This is exactly the billing/settlement behavior an agent needs before spending money.

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 and the returned fields are front-loaded in the opening clause, and every section (chains, defaults, payment, errors) carries real information. It is dense and the payment detail sits mid-paragraph, but the length is justified by the tool's paid, multi-step nature.

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 tool with an output schema and full annotation coverage, the description supplies everything the agent needs: what is returned, which chains, the default, the 402/payment handshake, and the error/charging policy. Nothing required to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents chain, token, and payment thoroughly, including the two-call payment flow. The description largely restates that (Base default, no body = USDC on Base), adding little beyond what the structured fields provide, 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+resource ('Who holds an ERC-20') and enumerates exactly what it returns: top 10 holders with share of supply and contract/locked/burn status, LP holders and locked LP, creator/owner share, holder count, and raw vs controlled concentration. This content is clearly distinct from siblings like token_price, token_metadata, and token_safety, so an agent can route 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?

Gives clear operating context: Base is the default chain with six alternatives, omitting the body returns USDC on Base, and the payment flow is spelled out (first call yields a 402 challenge, second call pays). It stops short of explicitly contrasting when to choose this tool over token_report or token_safety, so no true when-not 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?

The description discloses critical behavioral traits beyond the annotations: the $0.002 payment requirement, the 402 challenge flow, automatic payment via the npm package, and the no-charge behavior on 4xx/5xx failures. It also clarifies that a failed call after payment settles nothing, which is important financial 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?

Three dense sentences front-load the paid nature and returned fields, then cover the payment flow and error semantics. Every sentence earns its place, and there is no redundant restating of the 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?

The description covers what the tool returns, how payment works, what happens without payment, and error/charging behavior. An output schema exists, so return-value details are already structured. The tool is fully specified for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning to the payment parameter: omit it on the first call, use the returned payloadTemplate on the second, and send it as the PAYMENT-SIGNATURE header rather than body data. This goes well beyond the schema's base64 description.

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

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

The description states a specific verb-resource pair: returns name, symbol, decimals, and total supply for any ERC-20 contract on Base. It also distinguishes itself from sibling pricing/safety tools by calling these 'identity fields an agent needs before pricing or safety-checking a token.'

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 clearly indicates when to use this tool: before pricing or safety-checking a token, when identity fields are needed. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to select it correctly.

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 goes beyond annotations by detailing the exact outputs (USD price, 5m/1h/6h/24h change, liquidity, 24h volume, market cap/FDV, most-liquid DEX pair) and adds that it's free and real-time. There is no contradiction with annotations (readOnlyHint, openWorldHint, idempotentHint).

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 only two sentences, front-loaded with the primary use case and then the alternative. Every sentence is essential, with no wasted words. It is highly efficient.

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 output schema exists, the description adequately covers inputs, outputs (listed explicitly), free cost, real-time nature, and read-only behavior. No critical information is missing for a pricing snapshot 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 100%, so the JSON schema already documents all parameters. The description adds value by explaining the use of the symbol parameter for Coinbase spot prices and stating that chain defaults to base, providing context beyond the schema.

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

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

The description clearly states the tool provides a 'FREE real-time price snapshot for any EVM token by contract address' and also handles major symbols like ETH/BTC for Coinbase spot price. This specific verb+resource combination distinguishes it from siblings like token_metadata or token_safety.

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 explains how to use the tool (by contract address or major symbol) and mentions it's free and read-only. However, it does not explicitly state when to use this tool over alternatives like token_metadata or provide conditions where it should not be used.

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 only cover read/idempotent/openWorld; the description adds substantial behavior beyond them — the x402 paid flow, the 402 challenge on unpaid calls, automatic payment via the npm package, and precise error semantics (400 bad address, 404 no data, 502 upstream/partial, none charged, failed-after-payment settles nothing).

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 price and the one-call value proposition, and dense with actionable detail. It is somewhat long with parenthetical vendor tags and a closing 'Not financial advice' disclaimer that is marginal, but nearly every sentence carries information an agent needs.

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

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

An output schema exists, so return values need not be explained. Given a paid, multi-source tool, the description still covers payment flow, error codes, and charge behavior — everything needed to invoke it correctly without surprises.

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 each parameter (chain, token, payment) is already fully documented in the schema, including the payment envelope mechanics. The description reinforces the payment flow but adds no new syntax or format detail beyond what the schema states. 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 ('The full picture on an ERC-20 in ONE call') and enumerates the exact data returned: live price, liquidity, 24h volume, market cap/FDV, best DEX pair, plus safety verdict fields. It explicitly distinguishes itself from the sibling tools token_price and token_safety by naming both.

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 when to prefer this over alternatives: 'One payment instead of chaining token_price + token_safety.' It also gives the payment procedure (omit payment on first call, resend on second) and the failure conditions that are not charged.

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

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

Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing the entire paid-call protocol: the first call returns a 402 challenge with a payloadTemplate, nothing is charged for the 402, payment is forwarded as the PAYMENT-SIGNATURE header, a post-payment failure settles nothing, and the npm package can auto-pay. This is exactly the kind of non-obvious behavior an agent needs.

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 price, purpose, and scope, then handles payment mechanics in a compact sentence. It is dense but every clause carries information; the closing 'Not financial advice' is the only near-disposable element.

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

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

An output schema exists, so return shapes need not be detailed, yet the description still summarizes the verdict values (safe|caution|danger) and the payment lifecycle. For a paid, multi-call tool this leaves no ambiguity about how to invoke it successfully.

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 process semantics the schema alone does not convey: why `payment` is omitted on the first call and sent on the second, and that it travels as a header rather than body data. The chain/token meaning is left to the well-written schema fields.

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?

Starts with a specific verb+resource ('On-chain safety verdict for any EVM token') and enumerates the exact checks performed (honeypot, buy/sell tax, owner privileges, LP-locked, liquidity). This clearly distinguishes it from siblings like token_metadata, token_holders, token_price and token_report.

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 frames timing ('BEFORE you trade it'), which is actionable guidance. However, it never names a sibling alternative or states when a different tool (e.g. token_report or token_holders) would be preferred, so the routing is implicit 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?

Adds substantial context beyond the readOnly/idempotent/openWorld annotations: the x402 paid model ($0.009), the 402-challenge-on-first-call flow, that failed calls are not charged, and crucially that 'boost' is paid promotion not a quality signal and new tokens are high-risk.

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 well-organized, front-loading price and what the tool returns before filters, sorting, payment mechanics, and disclaimers. Long, yet each sentence (payment flow, risk warning) is functional for a paid data tool.

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

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

With an output schema present, return values need not be restated. The description nonetheless covers the full picture for a 6-param paid tool: filters, defaults, comparison options, payment protocol, and safety caveats.

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 schema already documents enum members and defaults (baseline 3). The description elevates this by explaining the semantic meaning of the 'boosted' list (paid promotion) and restating the liquidity-floor default, giving interpretable meaning to the 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 precise verb and resource: the union of DexScreener's new/boosted lists with the exact metrics returned (price, liquidity, volume, buys/sells, age). It is clearly distinguishable from siblings like token_price or token_safety, which it names 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?

Gives concrete filters, defaults, and routing guidance ('run token_safety before trading'), which tells the agent where this fits in a workflow. It stops short of explicitly stating when NOT to use it versus token_price/token_report, but the context is clear.

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

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

Annotations already declare readOnly/openWorld/idempotent hints, but the description goes well beyond them: it exposes the per-call cost, the non-chargable 404 and 5xx paths, the 402 payment challenge, and the automatic payment behavior. This is excellent behavioral disclosure.

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

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

The description is rich but efficient: each sentence adds new material (status result, 404 polling guidance, 402 challenge, automatic payment, 5xx behavior) without clutter. It is front-loaded with the most important facts and covers a lot in a few lines.

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 status tool with an output schema, the description covers all necessary context: the exact inputs, the return value coverage, error semantics, payment gate, and charging/not-charging rules. The agent can invoke and interpret this tool correctly without needing additional external instructions.

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 100% schema description coverage, the baseline is 3, and the schema already documents txHash and payment well. The description adds genuine value by clarifying that the payment is handled automatically by the 'fiatdock-mcp' package and that the txHash refers to a Base transaction, which helps an agent understand how to fulfill the required parameter in practice.

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 the tool's purpose: 'Confirmation status of a Base transaction', with the specific data returned (success/failed, block, confirmations, gas used, from/to). It is clear and resource-specific, but it does not explicitly contrast with sibling tools like get_order_status, so it stops short of full differentiation.

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

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

The description gives useful context: an unconfirmed/unknown transaction returns a 404 and is not charged, so an agent can safely poll. It also clarifies the 402 challenge and automatic payment via the fiatdock-mcp package. However, it doesn't explicitly state when to choose this tool over a sibling like get_order_status.

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 annotations already declare readOnly, openWorld, and idempotent hints, but the description goes further by exposing the paid x402 flow: no payment returns the 402, invalid addresses return 400 without charge, and RPC errors return 5xx without charge. This is exactly the kind of behavioral detail that annotations cannot replace.

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

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

The description is compact and information-dense: it covers payment, resource, network, units, challenge handling, explicit failure modes, and charge guarantees in under three sentences. No sentence is wasted.

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