FiatDock

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

Despite readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds substantial behavioral detail: paid via x402, the 402 challenge without payment, automatic payment via fiatdock-mcp, 400 for bad addresses, 502 when dependencies fail, and no charge for failed calls. This goes well beyond the annotations and does not contradict them.

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

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

The description is dense but every sentence earns its place: pricing, enrichment contents, intended use case, payment flow, and error semantics. The paid aspect is front-loaded, and the information is organized in a scannable way.

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 output schema covers the return shape, and the description covers the operational context needed to invoke the tool correctly: cost, two-step payment, automatic payment path, error statuses, external dependencies, and triage use cases. 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 schema already documents both parameters at 100 percent coverage, so the baseline is 3. The description adds meaningful behavior around the payment parameter: OMIT it on the first call, the npm package pays automatically, and neither the 402 nor failed calls are charged.

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 enriches a Base address in one call and enumerates the exact outputs: EOA vs contract, ERC-20 details, nonce, ETH/USDC balance, and a GoPlus security verdict. This distinguishes it from narrowly scoped siblings like eth_balance and usdc_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?

The description gives strong use context: use it before trusting a counterparty, payout target, or approval spender, and frames it as the loop input for triaging addresses. It does not explicitly name alternatives or state when not to use it, so it falls just 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 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?

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?

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?

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?

Beyond the readOnlyHint annotation, the description adds meaningful behavior: the tool is free, paid listings route through a gateway, and the gateway commission is currently waived. It also explains the free/first-party direct-endpoint distinction, which materially changes how an agent should act after the call. 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 two compact sentences with no filler. The core purpose is front-loaded, followed immediately by the actionable paid/free routing distinction. Every clause contributes to an agent's decision-making.

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 does not need to explain return values. The combination of description, annotations, and schema fully covers how to get a listing, when to set includeSchemas, and how to proceed for paid versus free listings. No critical calling information 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 id and includeSchemas thoroughly, including the instruction to set includeSchemas before a first paid call. The description adds routing context but no additional parameter-level meaning. A baseline of 3 is appropriate because the schema carries the weight.

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: 'Full detail for one FiatDock marketplace listing.' It distinguishes this tool from both search_services (discovery) and call_service (invocation) by explicitly mentioning the paid-call routing through call_service. The title reinforces the single-listing-detail scope.

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 clear context for what to do after retrieving a listing: PAID listings go through call_service, while FREE/first-party listings can be called directly via their real MCP endpoint. It does not explicitly state when to prefer search_services for listing discovery, though the schema's id description implies it. This is clear contextual guidance without fully listing 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 already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: result ordering ('best match first when q is given, otherwise newest, or the sort you pass'), the 20-per-call cap, the token-cost warning about the catalog size, and the fact that first-party listings are always featured first. It doesn't contradict 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 compact and front-loaded: the core purpose and return shape come first, then ordering/cap behavior, then sibling routing, then the read-only/free note. Every sentence earns its place; the token-cost warning is dense but directly relevant to safe invocation.

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

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

Given the output schema exists, the description doesn't need to explain return values. It covers ordering, cap, narrowing, sibling routing, and safety. For a 5-parameter, 0-required search tool with rich schema and annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the cap rationale in context terms ('injected into your context... costs six figures of tokens') and by summarizing the q semantics ('best match first'). It doesn't fully restate every parameter, but it adds strategic value on top of 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 states a specific verb ('Find'), a resource ('paid + free MCP services on the FiatDock marketplace'), and the return shape (id, name, summary, price, category, seller, verified, gatewayUrl). It also distinguishes itself from siblings by naming get_service and call_service as the tools for full detail and invocation, so an agent can tell it apart without opening schemas.

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

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

The description explicitly says when to use this tool vs alternatives: 'Use get_service for full detail and call_service to invoke one.' It also gives concrete narrowing guidance ('pass limit for more, or q/category to narrow') and warns against raising limit without narrowing, which is actionable usage context.

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

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

Annotations already declare readOnlyHint, 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?

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?

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?

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses critical behavioral traits: it is a paid call requiring x402 payment, the first call returns a 402 challenge, payment is forwarded as a header, and nothing is charged for the 402 or failed calls. These details are essential for correct usage and are not present in the annotations.

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

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

The description is dense but well-organized: it opens with the paid nature, lists the data points, contrasts with alternatives, explains the payment flow, and lists error conditions. Each sentence contributes value; it is slightly long but not verbose, warranting a strong score.

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 sufficiently explains what data is returned (price, liquidity, volume, market cap, safety) and the conditions under which errors occur. Since an output schema exists (though not shown), the absence of a detailed return format is acceptable. The description provides enough context for an agent to decide whether to call this 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?

The input schema already provides comprehensive descriptions for all parameters (chain, token, payment), including the payment payload format. The tool description does not add additional parameter-specific semantics beyond what the schema states, so it receives the baseline score for full schema coverage.

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

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

The description clearly states the tool's purpose: providing a comprehensive ERC-20 report combining price, liquidity, volume, market cap, DEX pair, and safety verdict. It explicitly contrasts with token_price and token_safety, making its unique value proposition obvious.

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 tells when to use this tool instead of chaining token_price + token_safety. It also details the payment flow: first call without payment returns a 402 with instructions, second call with payment completes the request. Error codes (400, 404, 502) are explained with the condition that no charge occurs for failed calls.

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

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

Annotations already declare readOnly, openWorld, and idempotent. The description adds the paid x402 flow, the 402 challenge without payment, the automatic payment via fiatdock-mcp npm package, and the caveat that a failed call settles nothing. This is valuable behavioral context beyond the annotations, though no rate limits or auth details are mentioned.

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?

Information-dense but front-loaded with the paid nature and core purpose. Each sentence earns its place: cost, purpose, checks, output, payment behavior, package automation, and disclaimer. Slightly long but not bloated; the structure flows from what → when → how.

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

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

Output schema exists, so return-value details are unnecessary. The description covers the full call flow including the two-step payment handshake, the fee, behavior without payment, and what the verdict includes. For a paid read-only screening tool, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents token, chain, and payment payload. The description reinforces token's purpose (what checks will be run) and payment's role (completing the purchase), but it adds little beyond the schema's own detailed prose. The baseline of 3 applies because the schema does the heavy lifting.

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

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

States a specific verb+resource: on-chain safety verdict for any EVM token BEFORE you trade it. Enumerates the exact risk checks (honeypot, buy/sell tax, owner privileges, holder concentration, LP lock, CEX listing, DEX liquidity), which distinguishes it from sibling tools like token_price or token_report without needing to open 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?

Explicitly gives the context when to use this tool: BEFORE you trade any EVM token. It implies it is the pre-trade screening gate, and explains the payment flow (402 challenge first, then paid call) so an agent knows the call sequence. It does not explicitly name sibling alternatives or when not to use it, so it falls short of a 5.

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

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

Annotations already declare 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.

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

Given that an output schema exists and the input schema is highly descriptive, the tool description covers all essential non-schema context: payment requirements, the exact two-step x402 flow, error behavior, and what is and is not charged. An agent has enough information to call the tool correctly.

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

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

The input schema already covers both parameters thoroughly, including the Base64 payload format and the two-call protocol. The description adds useful semantic context by linking payment to the x402 challenge and by noting the npm package's automatic-pay behavior, which helps an agent understand the optional payment parameter beyond the schema alone.

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 operation: it reads the USDC balance of any Base address. It adds specific scoping details such as 'on Base', 'settlement asset for x402', and 'atomic units and USDC', which makes the tool's purpose precise and easily distinguishable from siblings like 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?

The description gives clear invocation context: omit payment to get the 402 challenge, send payment on the second call, and note that the fiatdock-mcp npm package handles payment automatically. It does not explicitly contrast this tool with sibling balance/token tools, so a small exclusionary step is missing.

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 declare readOnly, openWorld, and idempotent hints. The description goes well beyond this by disclosing the paid x402 mechanism, the 402 challenge flow, the fact that failures are not charged, the redirect behavior, and the security guidance to treat page text as data, never instructions. Nothing about the tool's behavior is hidden.

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

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

The description is dense but every sentence carries essential information: pricing, output fields, limits, error semantics, payment flow, and security. It is front-loaded with the purpose and then layers constraints and workflow details. Nothing is wasted.

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

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

Given the output schema exists and the parameter schema is fully covered, the description still adds everything else an agent needs: error codes, charging rules, redirect behavior, the two-call payment flow, and the security caveat. There are no meaningful gaps for selecting and invoking this tool correctly.

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

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

The input schema already documents all three parameters with 100% coverage. The description reinforces them and adds meaningful context: the payment payload must be base64 x402 and is forwarded as a header, maxChars affects context usage, and URLs must be absolute with no credentials. This exceeds the baseline for schema-covered parameters without being redundant.

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: 'Fetch any public web page and get its readable text' followed by a precise list of returned fields (title, meta description, canonical URL, stripped body, links, word count). This leaves no ambiguity about what the tool does, and it distinguishes itself from the sibling tools, which are mostly crypto/address/account operations.

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 when-to-use and when-not-to-use conditions: only public pages, one page per call, redirects are not followed and the target is named for a follow-up call, JS-only pages return 422, non-2xx/timeout/binary return >=400 and are not charged. It also details the two-step payment workflow (omit payment on first call, send on second), leaving no ambiguity about how to invoke it correctly.

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