FiatDock

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

Annotations indicate readOnly, openWorld, and idempotent hints. The description adds significant behavioral details: it's a paid tool ($0.005), returns a 402 challenge without payment, the npm package handles payment automatically, and bad addresses return 400, unavailable services return 502 (not charged). 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 information-dense but slightly long. It front-loads the paid status and core purpose. Each sentence adds value, though some details (like the npm package) could be integrated more concisely.

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 (paid tool, multiple data sources, error handling), the description is complete. It covers inputs, behavior, payment mechanics, error responses, and output types. The presence of an output schema further reduces the need to describe return values.

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

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

The input schema has 100% coverage for the single 'address' parameter, with a description. The tool description adds minimal extra meaning—just states 'A 40-hex EVM address (0x…) on Base'. Since schema already covers this, 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 states it enriches a Base address with a comprehensive set of attributes (EOA vs contract, ERC-20 details, nonce, balances, security verdict). It uses specific verbs like 'enrich' and 'triaging', and the listed outputs distinguish it from sibling tools 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 provides usage context: 'before you trust it' and 'triaging a counterparty, payout target or approval spender'. It explains payment requirements and error handling (400, 502). However, it does not explicitly state when not to use the tool or suggest alternatives.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds cost details, payment mechanism, and error/failure behavior that are not captured by annotations. This provides valuable transparency beyond the structured hints.

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, each serving a distinct purpose: cost and output, payment mechanism, error handling. Front-loaded with the most critical info (paid, what it returns). No 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?

Given no parameters, complete annotations, and the presence of an output schema, the description covers all essential aspects: purpose, cost, payment workflow, and error conditions. It is sufficient for an agent to correctly invoke and handle the 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?

There are zero parameters and schema coverage is 100%. Per guidelines, this yields a baseline of 4. The description adds no parameter information, but none is needed.

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 explicitly states it returns 'the latest Base block number plus its timestamp' and positions it as a 'freshness/liveness probe'. This clearly identifies the verb (probe) and resource (Base block chain head), distinguishing it from sibling tools like token_price or gas_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 explains the payment requirement ($0.001 USDC via x402), the 402 challenge without payment, and automatic payment via the npm package. Error handling is also covered ('4xx/5xx and NOT charged'). While it doesn't explicitly compare to alternatives, the context is sufficient for deciding when to use this tool.

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

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

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?

Even though annotations indicate a mutating, non-idempotent operation, the description goes far beyond them: it discloses the $0.01 USDC x402 payment requirement and 402 challenge, automatic emailing behavior, 2-hour checkout URL validity, provider limitations (mtpelerin only, no push updates), callback behavior (no webhooks), and compliance/geographic restrictions. This fully prepares the agent for real-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 a substantial paragraph, but almost every sentence adds necessary operational detail (payment, compliance, geography, provider behavior, email, volatility). It is front-loaded with the core purpose and ends with an advisory disclaimer. It is slightly long, but the density of relevant information justifies the length, earning a 4 rather than a 3.

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 11 parameters, an output schema, and a complex compliance/payment model, this description covers all essential context: what the endpoint returns, what happens without payment (402), when it is not allowed, geographic restrictions, provider specifics, and how to track orders. It is fully self-sufficient for an agent to decide whether and how to invoke the 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 schema already has 100% parameter description coverage, but the tool description adds significant extra meaning beyond the schema: it explains the email parameter's automatic email side effect, clarifies provider default and that only 'mtpelerin' works, details the walletCode/walletHash/walletAddress dependency chain, and warns that callbackUrl receives no push updates. This is far above the baseline 3 for high-coverage schemas.

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

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

The description uses a specific verb ('Convert') and resource ('agent's USDC to fiat in the owner's OWN bank account'), clearly distinguishing this off-ramp tool from the sibling create_onramp_session. It also specifies the output artifacts (checkoutUrl, partnerOrderId), leaving no ambiguity about the tool's function.

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

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

The description provides explicit when-not-to-use constraints: only for the owner's own account, no third-party funds, no aggregation, no P2P transfers, and geographic exclusions (not US persons, sanctioned countries, or the UK). It also clarifies that get_order_status should be used for status instead of relying on callbacks. However, it does not explicitly name create_onramp_session as the alternative for the reverse conversion, so it stops short of a full 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?

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses critical behavioral traits: payment required with 402 challenge if not paid, address locking behavior, emailing of checkout link, and that the current provider sends no push updates. It also details legal/compliance constraints and geographic availability. No contradiction with annotations; the description adds significant context.

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

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

The description is dense but efficient, packing essential operational, compliance, and geographic details into a single paragraph. It is front-loaded with the core purpose and follows with critical caveats. While long, every sentence adds value and no extraneous filler is present. Slightly under a 5 due to the rapid-fire legal language, but well-structured for the complexity.

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 (payment, compliance, provider limitations) and the presence of an output schema (checkoutUrl + partnerOrderId), the description covers all necessary context: payment handling, provider restrictions, compliance rules, geographic exclusions, and how to poll status. It is complete for the agent to invoke correctly and handle side effects. The output schema handles return values, so the description needn't explain them.

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 meaningful context beyond the schema: it explains the address lock mechanism (walletCode/walletHash) and that walletAddress is the receiving wallet, and it clarifies that only mtpelerin is a valid provider (others return 400). This enhances understanding of parameter interplay and constraints, warranting 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 clearly states the specific action: 'Buy USDC with the owner's OWN fiat and deliver it to the agent's wallet (address locked).' It identifies the resource (on-ramp session) and the direction (fiat → USDC), distinguishing it from sibling tools like create_offramp_session. The verb 'Buy' and target 'USDC' are explicit.

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 when-to-use and how-to-use guidance: it mentions the paid endpoint, the npm package for automatic payment, and compliance constraints (own-account rule, no third-party funds). It also mentions exclusions (US persons, sanctioned countries, UK) and tells the agent to 'Poll get_order_status instead' for current provider, indicating when not to rely on callbacks. This qualifies as clear usage vs 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?

Description adds significant behavioral context beyond annotations: payment requirement, automatic payment handling, error handling and billing rules. Annotations (readOnlyHint, openWorldHint, idempotentHint) are consistent, and description 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?

Description is three sentences covering purpose, payment, and error cases. It is concise and front-loaded with the payment note, though the first sentence is fragmented. Overall, efficient with minimal redundancy.

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 simplicity and presence of output schema, the description covers all essential aspects: what the tool does, payment model, error handling, and billing rules. No critical 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 provides description for the single required parameter 'address' (A 40-hex EVM address). Description does not add extra meaning for the parameter beyond what schema already documents. With 100% schema coverage, baseline of 3 is appropriate.

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

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

Description clearly states it returns the native ETH balance on Base in wei and ETH, with specific verb 'returns' and resource 'ETH balance of any address'. It is distinct from siblings like usdc_balance and token_balance, which are not listed but implied by context.

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?

Description explains payment model ($0.001 fee, 402 challenge without payment, automatic payment by npm package) and error conditions (400 for invalid address, 5xx for RPC failure, no charge in those cases). It does not explicitly list when not to use or alternative tools, but the context and sibling names provide guidance.

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

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

Beyond annotations (readOnly, idempotent, openWorld), the description adds details on payment via x402, the 402 challenge response if unpaid, automatic payment via npm package, and error behavior on RPC failure. No contradictions 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?

Four sentences covering purpose, payment, usage context, and errors. The payment info is front-loaded, which is relevant but could be placed after stating the main purpose. No unnecessary words.

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 and zero parameters, the description adequately covers purpose, payment behavior, error handling, and usage context for a gas-aware agent. Missing details like the exact structure of the output are covered by the schema.

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

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

The tool has no parameters; schema coverage is 100%. The description does not need to add parameter info, but it provides useful context about the payment mechanism and response conditions.

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 retrieves the current Base gas price in wei and gwei, and mentions its use by gas-aware agents. However, it does not explicitly differentiate from siblings, though the function is unique among the listed tools.

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

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

The description implies when to use (for gas price sampling before transactions) and mentions payment/error handling, but does not provide explicit when-not-to-use or alternative tool references.

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?

The description discloses that the tool is 'Read-only, free,' which matches the annotations. It also reveals a behavioral nuance: the 99/1 split for paid listings is enforced when routing through call_service. This adds context beyond the annotations by explaining what the returned details contain and how the calling mechanism works.

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

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

Two sentences with no redundant words. The key purpose is front-loaded, and the paid/free routing distinction is packed efficiently without unnecessary elaboration.

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 simple read-only lookup with one parameter and an output schema, the description covers the purpose, the key nuance of paid vs free calling, and a note on cost. No significant gaps remain for an agent to select and invoke 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 provides complete documentation for the 'id' parameter ('Listing id (svc_…) from search_services'). The description does not add further meaning to the parameter, and since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states it returns 'Full detail for one FiatDock marketplace listing,' which is a specific resource and scope. It distinguishes itself from sibling tools by implying that search_services finds listings, while get_service retrieves a single listing's details, and call_service is for actually invoking paid services.

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 clear guidance on how to use the returned information: paid listings must be called via call_service, while free listings expose a direct MCP endpoint. It also implies this tool is the prerequisite step before calling a service. However, it does not explicitly contrast with search_services for finding listings, so the usage context is clear but not fully exclusionary.

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 value by specifying the exact return fields (id, name, summary, price, category, seller, verified, gatewayUrl) and noting the tool is free. This goes beyond the annotations, though it doesn't cover pagination or rate limits, but the baseline is lowered by strong 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 three sentences, front-loaded with the primary purpose, followed by return fields and usage pointers. Each sentence contributes distinct information with no waste, making it highly concise and well-structured.

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 tool is a simple search operation with an output schema and rich annotations. The description covers the purpose, return shape, and sibling tools for full detail and invocation, which is complete for this context. The schema and annotations handle the rest.

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

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

Schema description coverage is 100%, with each parameter (q, sort, category, verifiedOnly) having a detailed description. The tool description does not add significant parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states it finds paid and free MCP services on the FiatDock marketplace, using the specific verb 'Find' with a clear resource and scope. It also distinguishes from siblings by explicitly naming get_service and call_service as alternatives for detail and invocation.

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 usage guidance is provided: 'Use get_service for full detail and call_service to invoke one.' This directly addresses when to use this tool versus its siblings. It also mentions the tool is read-only and free, which helps set expectations for safe 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 annotations (readOnly, idempotent, openWorld), the description reveals critical behavioral traits: the tool is paid ($0.002 USDC via x402), and without payment it returns a 402 challenge. It also notes that the fiatdock-mcp npm package handles payment automatically. This transparency about cost and authentication exceeds what annotations provide, adding significant value.

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

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

The description is extremely concise: three sentences covering paid status, output details, use case, and payment mechanism. Every sentence adds essential information. The most critical features (paid, supply/peg breakdown) are front-loaded. No wasted words.

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 low complexity (1 optional parameter, no required params, output schema present), the description is fully adequate. It explains what data is returned, the use case, and the payment model. There are no gaps in coverage given the available schema and annotations.

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 covers 100% of the single optional parameter 'asset' with a description listing example symbols. The description complements this by implying default behavior (USDC) and confirming it returns data for other stablecoins. This adds context beyond the schema's bare definition, earning above the baseline of 3.

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

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

The description explicitly states the tool's purpose: providing supply, peg health, and per-chain breakdown for stablecoins. It lists specific metrics (total circulating supply, deviation from peg, peg mechanism, Base circulation, top chains) and notes the use case for treasury/payments agents. This clearly distinguishes it from sibling tools like token_price 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 provides a clear use case: 'A treasury/payments agent uses it to check its settlement asset is healthy.' While it doesn't explicitly state when not to use it or compare to alternatives, the context of siblings (token_price, token_safety) makes differentiation clear. The use-case guidance is actionable and contextually appropriate.

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 annotations: it mentions the $0.002 fee, the 402 challenge without payment, automatic payment via the npm package, and that errors (4xx or 5xx) are not charged. Annotations only indicate read-only, open-world, and idempotent, so this extra detail is valuable and does not contradict.

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

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

The description is a single concise paragraph that front-loads the key point (paid tool) and efficiently covers functionality, payment mechanism, and error handling without unnecessary words.

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 and the tool's straightforward purpose, the description provides complete context: what it returns, when to use it, and how payment and errors work. An agent can determine if and how to invoke it.

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

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

There is only one parameter ('token') with 100% schema coverage. The description repeats the schema's description of the address format but adds no new semantic meaning. Baseline 3 is appropriate as the schema already clearly defines the parameter.

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 returns name, symbol, decimals, and total supply for any ERC-20 contract on Base. It distinguishes itself from related tools like token_price and token_safety by specifying its purpose as providing identity fields needed before pricing or safety checks.

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 when to use this tool (before pricing or safety-checking a token) and details payment requirements and error handling. Although it doesn't explicitly exclude scenarios or name alternatives, the context is sufficiently clear for an agent.

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

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

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

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

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

The description is only two sentences, front-loaded with the primary use case and then the alternative. Every sentence is essential, with no wasted words. It is highly efficient.

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

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

Given the output schema exists, the description adequately covers inputs, outputs (listed explicitly), free cost, real-time nature, and read-only behavior. No critical information is missing for a pricing snapshot tool.

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

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

Schema description coverage is 100%, so the JSON schema already documents all parameters. The description adds value by explaining the use of the symbol parameter for Coinbase spot prices and stating that chain defaults to base, providing context beyond the schema.

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds payment requirement, error handling details, and that the npm package pays automatically, providing useful behavioral context beyond 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 thorough but slightly long at 5 sentences. Each sentence provides value, but could be more concise. Structure is logical, front-loading the core benefit.

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 (paid API, combined data), the description covers inputs, payment mechanism, error handling, and the nature of the returned data (price + safety). An output schema exists but is not shown; the description compensates effectively.

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 context about the chain parameter defaulting to 'base'. However, it does not significantly enhance the schema's own parameter 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 that this tool provides both price/liquidity data and safety verdict in one call, explicitly distinguishing it from the sibling tools token_price and 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?

Explicitly explains that this tool replaces chaining token_price + token_safety, mentions payment requirement ($0.05 via x402), and describes error codes (400, 404, 502) with their charging implications.

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 readOnlyHint, idempotentHint, openWorldHint, but the description adds critical context: the tool is paid ($0.01), returns a 402 challenge without payment, and the agent pays automatically. It also includes a disclaimer ('not financial advice'), which is beyond what annotations provide.

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 key purpose and constraints. It is efficient with about 4 sentences, though the payment explanation could be slightly tighter. No wasted words.

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 (paid endpoint, multiple checks, output schema exists), the description fully explains what the tool does, how payment works, and what it returns (verdict with risks). It leaves no significant gaps for an AI agent.

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 description adds marginal value. It clarifies that 'chain' defaults to 'base' and 'token' is an ERC-20 contract address, but these are already in the schema. The description does not add new parameter semantics beyond reinforcing defaults.

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

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

The description uses a specific verb ('returns safety verdict') and resource ('any EVM token'), clearly defining the tool's function. It lists detailed checks (honeypot, taxes, etc.) that distinguish it from sibling tools like token_price or stablecoin_intel.

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 states 'BEFORE you trade it', indicating when to use. It also explains the payment mechanism and automatic payment via the npm package. While it does not explicitly state when not to use, the context and sibling tools make the scope clear.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds critical behaviors: payment requirement (402 challenge), no charge for unconfirmed/unknown (404), no charge on RPC failure (5xx). This is excellent transparency.

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 relatively concise and structured, but the opening 'PAID ($0.001 USDC via x402)' could be clearer. Overall, it communicates effectively with minimal redundancy.

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 simplicity (one parameter, output schema exists, few sibling overlaps), the description covers all necessary aspects: purpose, payment, error handling, and polling safety. It is complete.

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

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

Schema coverage is 100%, and the schema already describes txHash as 'A 64-hex transaction hash (0x…) on Base'. The description does not add further parameter semantics, so it meets the baseline.

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

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

The description clearly states the tool's purpose: 'Confirmation status of a Base transaction — success/failed, block, confirmations, gas used, from/to.' This is a specific verb+resource combination. No sibling tool overlaps, so it distinguishes well.

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 guidance on when to use (polling safety via 404 on unconfirmed) and mentions payment handling. However, it does not explicitly mention when not to use or alternative tools, so it's not a perfect 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral details: payment via x402, atomic units vs USDC, and error handling specificity (no charge on 400/5xx). No 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?

The description is concise (three sentences) and front-loads the key purpose and payment model. Every sentence adds value.

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

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

Given the presence of annotations and an output schema, the description is complete. It explains the payment mechanism, error handling, and the output format (atomic units and USDC). No gaps.

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

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

Schema coverage is 100% with a clear parameter description. The description does not add further meaning beyond the schema for the parameter itself, but provides useful context about payment and errors. 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 states the tool returns the USDC balance of any address on Base, in atomic units and USDC. It distinguishes from siblings like eth_balance by specifying the asset and network.

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 when to use (get USDC balance on Base), payment handling, and error conditions (invalid address returns 400 not charged, RPC failure returns 5xx not charged). It does not explicitly contrast with siblings but the context is sufficient.

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