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?

Beyond the annotations, the description discloses key behavioral traits: paid listings route through the gateway, payment split is normally 99/1 with a 0% launch-window exception, the 402 challenge flow requires two calls, and FiatDock never holds funds. It also covers the free-listing direct-forwarding behavior. This is rich, honest 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 longer than average but highly structured: it starts with the core purpose, then explains the paid flow, the free flow, and the no-wallet alternative. Each sentence adds necessary operational detail. It is not padded, but could be tightened slightly by separating the wallet-setup command into a prerequisite note.

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 multi-step payment tool, the description covers the full invocation lifecycle: challenge, signing, payment submission, gateway settlement, free-list fallback, and wallet automation. With an output schema present, return-value documentation is not required. The description is complete and self-sufficient.

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

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

Even though schema coverage is 100%, the description adds significant workflow meaning. It explains that `payment` is omitted on the first call and set on the second, that `args` is the service-specific request body, and that `id` comes from search_services. This elevates parameter understanding beyond raw schema definitions.

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 clearly distinguishes this call/invoke tool from sibling tools like search_services and get_service by describing the actual invocation mechanics (gateway vs direct forwarding). The scope and action are unmistakable.

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 explicit workflow instructions: call once without `payment` to get the 402 challenge, sign, then call again with payment. It also states when payment is NOT needed (free/first-party listings). However, it does not explicitly compare against alternative tools (e.g., 'use get_service for metadata'), so it lacks a direct alternatives statement.

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

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

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 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?

Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful non-obvious behavior: the 99/1 split enforced for paid listings, the distinction between paid gateway calls and free direct MCP endpoints, and the fact that the tool is free. This goes beyond what structured annotations 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 two compact sentences with no filler. It front-loads the most decision-relevant facts (full detail, how to call, read-only, free) and earns every word.

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

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

Given an output schema, 100% parameter coverage, and read-only/idempotent annotations, the description covers the unusual marketplace routing behavior and the prerequisite for paid calls. Nothing essential is missing for an agent to call 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the includeSchemas timing and paid-call context, but it does not add substantial parameter meaning beyond what the schema already documents for id and includeSchemas.

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 ('Get'), a specific resource ('a FiatDock marketplace listing'), and the nature of the result ('Full detail'). It also references call_service as the gateway for paid listings, which helps distinguish this introspection tool from the actual invocation sibling.

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 routing guidance: paid listings go through call_service, free/first-party listings are called directly, and includeSchemas should be set before a paid call. It names the relevant sibling (call_service) and provides actionable context, though it does not explicitly say 'do not use this tool for X'.

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. The description adds the 'free' cost property and clarifies that it returns a summary list rather than full service detail, while matching the read-only annotation. No contradictions or hidden destructive behavior are present.

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

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

The description is four concise sentences with no filler: purpose, return shape, sibling routing, and safety/cost are each covered efficiently. The primary action and result are front-loaded, and 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?

Given the rich input schema, output schema, and annotations, the description covers discovery purpose, result contents, routing to detail/invoke tools, and the read-only/free nature of the operation. Nothing needed to call this zero-required-parameter search tool 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%, and the parameter descriptions are already detailed, including q's scoring semantics, sort defaults, and verifiedOnly behavior. The description does not need to repeat this, so the baseline score 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?

The description states a specific verb and resource: 'Find paid + free MCP services... on the FiatDock marketplace.' It also lists the returned fields and explicitly distinguishes the tool from get_service and call_service, so an agent can tell it apart from its closest 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?

The description explicitly says 'Use get_service for full detail and call_service to invoke one,' giving clear routing guidance when search results are not enough. This is direct, actionable usage guidance in a tool set where several siblings relate to the same marketplace.

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 far beyond what readOnlyHint=true, openWorldHint=true, and idempotentHint=true provide. It discloses that this is a paid endpoint, the exact cost ($0.002 USDC via x402), the fact that without payment a 402 challenge is returned, and that the fiatdock-mcp npm package pays automatically. There is rich detail about parameter semantics and failure behavior — even though the `payment` param documentation covers the mechanics, the description states that nothing is charged for the 402 and that failed calls settle nothing. Consistent with and additive to 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?

Every sentence earns its place. The cost stamp comes first, then the data returned, then the use case, then the payment behavior. It covers pricing, protocol, data shape, target audience, and failure mode in roughly five sentences without fluff. The structure is perfectly front-loaded and wastes zero tokens.

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, the description doesn't need to document return values. Given that 0 params are required, 100% schema coverage exists, and annotations are comprehensive, nothing essential is missing. The only slight gap is that the use case is narrowly scoped to a treasury/payments agent as opposed to other potential consumers, but that's not a completeness issue — it's the description's strongest differentiating feature.

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%, placing the baseline at 3 per the rubric. The description meaningfully adds value by explaining the two-phase payment exchange at the tool level ('Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically'), which contextualizes both the `asset` and `payment` parameters without duplicating the schema's own documentation. It reinforces when to send the `payment` parameter without restating its exact payload format, so there's a clear division of labor.

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 data points returned: total circulating supply, peg deviation from $1.00, peg mechanism, per-chain breakdown on Base with share, top chains by supply. The 'PAID ($0.002 USDC via x402)' prefix unambiguously signals the billing model, distinguishing it immediately from the 17 sibling tools, especially token_price, token_metadata, and token_report. It leaves no ambiguity about what an agent gets by calling this tool.

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 names the target use case — 'A treasury/payments agent uses it to check its settlement asset is healthy' — which helps an agent decide when this is the right tool. However, it does not name alternative sibling tools or state when NOT to use it. There is clear context but no exclusion, which fits the level 4 definition.

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 (readOnly, idempotent, openWorld) cover the safety profile, and the description adds what annotations cannot: the $0.01 paid cost, the 402 challenge on non-payment, the automatic payment via the npm package, and the exact returns. The 'a call that fails after payment settles nothing' (in the payment param schema) and 'returns verdict with exact risks' complement the no-mutation hints. 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?

Front-loaded with the most critical gate ('PAID ($0.01 USDC via x402)') before the purpose, which is the right priority for a paid tool. The feature list is dense but each item is information-bearing, and the payment-flow sentence earns its place. Slightly verb-heavy near the end ('Not financial advice'), but every sentence contributes signal.

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

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

Complete for a complex, paid, two-step tool. Output schema covers return values, schema covers all params at 100%, and the description covers cost, payment flow, verdict format, and auto-pay. The riskiest part — the 402→payment handshake — is fully described in both description and schema, so an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, and the schema already documents all three params thoroughly — the payment param in particular is extensively described (EIP-3009 payload, howToPay payloadTemplate, PAYMENT-SIGNATURE header). The description adds little param-specific meaning beyond what the schema provides, which matches the baseline-3 expectation when the schema does the heavy lifting.

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

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

Clear verb+resource: 'On-chain safety verdict for any EVM token' with specific deliverables (verdict safe|caution|danger). The feature list (honeypot, taxes, owner privileges, LP lock, liquidity) crisply distinguishes it from siblings like token_metadata and token_price, and the 'BEFORE you trade it' framing sets the exact scope. The verdict output is a distinct deliverable that differentiates it from 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?

Strong context: 'BEFORE you trade it' tells the agent when this is the right tool, and the cost is front-gated. The payment guidance is explicit about the two-step 402-then-payment flow. However, it never names sibling alternatives (token_report, token_metadata) or states a when-not condition, so some routing is left to the agent rather than being 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 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.