DropEngine x402 Agent Services

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

With no annotations provided, the description fully carries the behavioral disclosure burden and does so exceptionally well. It discloses the $0.02 cost, the heuristic nature of large-trader labels, the lack of chain-wide coverage, the dependency on Helius/Etherscan in wallet mode, and the explicit statement that it does not claim complete balances or whale labels. This is far more than the schema provides.

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, each earning its place: a cost warning, an asset-mode summary, and a wallet-mode disclosure with limitations. It front-loads the most operationally critical fact (payment) and packs substantial caveats into a compact, readable form 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 complex two-mode tool with no annotations and an output schema that covers return values, the description is remarkably complete. It covers cost, data source, heuristic labels, chain-wide limitations, wallet-mode configuration, and the scope of returned data. An agent has all the behavioral context needed to decide whether and how to invoke it; only the explicit choice between asset and wallet is left to the mode names, which are self-evident.

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 has 100% description coverage, so the baseline is 3, but the description adds meaningful context beyond it. It explains the difference between the asset and wallet modes, ties the concept of 'large' trades to the min_transaction_usd threshold, and clarifies that wallet mode's address parameter selects a wallet rather than a token. This adds value without repeating schema details.

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 ('summarizes') and resource ('large public GeckoTerminal-indexed DEX trades') and clearly distinguishes the asset and wallet modes. It tells an agent exactly what the tool does without ambiguity, and the cost warning at the start adds a unique operational identifier.

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 context for both modes: asset mode analyzes token trades, while wallet mode uses Helius/Etherscan when configured and returns only recent indexed transactions. It does not explicitly name alternative tools or give negative guidance, but the mode-specific details effectively inform an agent about when each variant is 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?

With no annotations, the description carries the full burden of behavioral disclosure. It covers the cost, data scope, execution timing (candle close to next open), fee/slippage application, declarative-only inputs (no code execution), and a warning that results are not predictions. This is comprehensive for a paid backtesting tool.

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

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

The description is concise, front-loads the cost and purpose, and uses a structured sequence: purpose, data, execution, fees/safety, and disclaimer. Each sentence earns its place with no fluff. The semicolon usage is efficient. Very 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?

For a complex tool with 8 parameters, a nested strategy object, and an output schema, the description covers many behavioral aspects (cost, timing, safety) but fails to explain what each parameter does. Since schema descriptions are absent and coverage is 0%, the description should at least summarize key parameters. The output schema exists, which partially mitigates, but parameter semantics remain unclear.

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 0%, so the description must compensate by explaining parameter meanings. It does not mention any parameter by name (market, timeframe, start, end, initial_capital, strategy, fee_bps, slippage_bps). Even the strategy enum is not elaborated. The description only broadly mentions 'declarative parameters' without adding value to the schema. This is a significant gap for an 8-parameter tool.

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 a specific verb ('tests') and a specific resource ('built-in long-only spot strategies against bounded public Binance OHLCV history'). It also includes the cost ($0.10 USDC), making it unique and distinct from the unrelated sibling tools. The purpose is 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 clearly implies when to use this tool (for backtesting strategies) and provides context about the data source and execution model. However, it does not explicitly mention alternatives or when not to use it. Since no sibling is related to backtesting, differentiation from alternatives is less critical, but explicit exclusions would have improved this 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the paid cost ($0.001 USDC), normalization of text, the requirement for a public HTTPS page, and the conditional return of a compact diff when a prior snapshot exists. It does not detail failure modes or what happens when no snapshot is available, but it provides substantial useful behavior 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 a single sentence with no filler. It front-loads the paid nature and the core purpose, then immediately provides the mechanism and output condition. Every phrase earns its place.

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

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

For a simple two-parameter tool, the description covers the essential context: cost, input constraints, processing behavior, and expected output. It leaves minor gaps such as exact behavior when no prior snapshot exists, but nothing critical prevents an agent from invoking the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does: 'url' is clarified as a public HTTPS page with normalized text, and 'previous_hash' is clarified as a SHA-256 hash. This adds meaning well beyond the bare schema properties.

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 a specific action: checks normalized text on a public HTTPS page against a previous SHA-256 hash. It also distinguishes itself from sibling tools like check_url and check_package by focusing on change detection rather than generic URL or package validation.

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 makes the intended use case clear: use this tool when you have a URL and a prior SHA-256 hash and want to detect changes. It does not explicitly name alternatives or exclusions, but the conditions are specific enough to guide selection.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses the fee and network, states static analysis only, explicitly says package code is never executed, lists limitations, and describes the caution outcome for unknown 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?

The description is compact, front-loads cost and usage, and every sentence adds distinct value: when to call, what is checked, execution safety, and limitations. No filler or redundant schema repetition.

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

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

For a paid safety gate with three simple parameters and no output schema, the description covers pricing, invocation timing, checks performed, safety guarantees, exclusions, and the caution result. An agent has enough to decide and call correctly.

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

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

Schema description coverage is 0%, but the description compensates by referencing 'npm dependency' (ecosystem), 'package/version' (package and version), and the resolved version check. It doesn't spell out optionality or types, but the three simple parameters are reasonably inferable from context.

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

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

The description names a specific verb and resource: it 'checks' an npm dependency for vulnerabilities, typosquatting, and lifecycle scripts. It clearly positions itself as a 'Paid Package Safety Gate' distinct from sibling URL, wallet, content, and transaction 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?

It gives explicit usage context: 'Call before a coding agent installs, imports, or adds an unfamiliar npm dependency.' It does not name alternatives or list exclusions, but the when-to-use guidance is unmistakable.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool performs deterministic checks, does not load page content, blocks localhost/private addresses, optionally queries Google Web Risk, and incurs a cost. It also notes that no LLM is used and that a clean result is not a guarantee. This is comprehensive behavioral transparency for a tool of this complexity, though it could mention error handling or response format.

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, with every sentence adding value: cost, use case, safety features, optional integrations, and limitation. It is front-loaded with the most critical information (cost and when to use). No fluff or repetition.

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

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

The tool has a single parameter and no output schema, so the description covers the essential usage context (when, what, how). It explains the tool's internal checks, cost, and limitations. Minor gaps include the exact return structure (though not necessary given no output schema) and potential error conditions, but for this simple tool, the description is complete enough.

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 has 0% coverage and only one parameter, 'url'. The description explains what the tool does with the URL, implying that the 'url' parameter should be the URL to check. It also gives context on the URL length (max 4096) implicitly through schema. The description adds meaning beyond the type definition by clarifying the tool's behavior on the URL, which is sufficient for a single 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's purpose: to perform a preflight URL check before opening or trusting a URL. It mentions specific actions (checks redirects, blocks localhost, optionally queries Google Web Risk) and distinguishes it from general URL utilities. It also notes the cost and no-LLM nature, which is unique among 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 states when to use this tool: 'Call before an agent opens, follows, downloads from, or trusts an unknown URL.' It also provides a clear exclusion—'A clean result is not a guarantee of safety'—which sets expectations. While it doesn't mention alternatives, the sibling tools are all invoice-related, so the usage context is clear that this is the only URL check tool, making the guidance sufficient.

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

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

With no annotations, the description carries full responsibility and is exceptionally transparent: it flags the $0.02 charge, notes that risk intelligence is unavailable unless a trusted provider is configured, says results are cautious and low-confidence rather than a safety certification, and warns not to send private keys or seed phrases.

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 defining cost and purpose, and each subsequent sentence adds a meaningful caveat or safety note. It is slightly longer than strictly necessary, but not wasteful.

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

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

For a paid, security-relevant tool with an output schema, the description covers when to call it, what it verifies, cost, limitations, and safety constraints. Nothing needed to invoke it appropriately 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 0%, and the description does not add parameter-level meaning beyond mentioning Base and address at a high level. It does not explain that chain selects base vs base-sepolia or elaborate on address format, leaving the schema constraints to carry the meaning.

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

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

The description names a specific operation—a paid wallet risk check—and states exactly what it does: checks whether an address is a wallet or contract and reads basic on-chain metadata. This clearly differentiates it from sibling tools like check_url and check_package by resource and use case.

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

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

It gives concrete triggers: call before sending funds, accepting value, granting approvals, or interacting with an unfamiliar address. It does not explicitly name alternatives or state when not to use it, but the trigger list is 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?

With no annotations, the description carries the full burden and does well: it discloses the paid nature ($0.01 USDC), the indicative (non-binding) nature, the provider configuration requirement, and explicitly states 'Read-only: never signs, submits, or executes.' This is strong behavioral coverage, though it omits details like quote expiration or failure behavior, which are secondary for a quote tool.

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

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

Three sentences, front-loaded with the cost and purpose, then conditions, then read-only guarantee. Every sentence adds new information with no redundancy, making it easy to scan.

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 8 parameters and an output schema that exists, the description covers the core behavior, prerequisites, and return type ('estimated output and quote source'). It does not explicitly explain all parameters or failure cases, but the output schema and standard trading knowledge fill some gaps. It is adequate for an agent to call correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the meaning of asset addresses and decimals ('Requires token addresses and decimals for custom assets') and the venues (Jupiter/0x) in relation to chain and venues parameters. However, it does not elaborate on amount, max_slippage_bps, or the specific format of to_asset/from_asset beyond custom assets, leaving those parameters under-explained.

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 a specific verb ('Gets'), a resource ('indicative swap quote'), and the context ('before a trade'). It also names the supported venues (Jupiter, 0x) and chains, making its purpose unambiguous and distinguishable from generic quote 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 provides usage context ('before a trade') and a prerequisite ('Requires token addresses and decimals for custom assets'), but it does not name alternatives or explicitly state when not to use it. The sibling get_live_quote may serve a similar purpose, but no differentiation is offered, leaving some ambiguity.

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

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

With no annotations present, the description carries the full disclosure burden and does so thoroughly: it discloses the paid nature, that it fetches a fresh copy, that it only uses static data, that it never executes JavaScript, and that it won't fabricate missing fields. This is well beyond what the schema alone communicates.

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

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

Three sentences with no filler: pricing, core function, and key limitations are packed efficiently. The most important action and output are front-loaded before the caveats.

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?

Despite no output schema, the description gives a reasonable picture of the return value ('typed JSON shape' with validation and per-field provenance) and the tool's constraints. It is slightly incomplete about behavior when the schema parameter is omitted and about the exact provenance format, but an agent has enough 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 description coverage is 0%, so compensation is required. The description hints at the schema parameter through 'agent-defined typed JSON shape' and at url through 'webpage', but it never names either parameter, does not explain the optionality of the schema object, and does not describe how field types map to the schema's enum values.

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

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

The description opens with a specific verb and resource: it extracts a fresh webpage into a typed JSON shape, with validation and per-field provenance. This clearly distinguishes it from sibling tools like scan_content or check_url, which do not promise structured extraction against an agent-defined schema.

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

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

Usage context is implied rather than explicit. The static-page-only constraint and 'never fabricates missing fields' tell an agent when the tool is unsuitable, and the $0.01 USDC charge signals cost, but no alternative tools are named and no direct when-to-use/when-not-to-use guidance is given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the $0.01 USDC cost, the read-only nature of the operation, and the null semantics for shipping, tax, and unknown values. It does not cover failure modes or rate limits, but the core behavioral traits are transparent.

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 short sentences with no filler. The cost, target resource, timing, null-value behavior, and non-purchase guarantee are all packed in efficiently and front-loaded.

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 core purpose and cost, but without an output schema or annotations it leaves gaps around return shape, failure behavior, and how the nested parameters interplay. It is adequate for basic use but not fully 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 description coverage is 0% and the description adds little parameter-level meaning. It indirectly references the URL as a public HTTPS product page but says nothing about how variant, quantity, or destination affect the quote.

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

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

States a specific action and resource: 'Retrieves explicitly published product price and stock from a public HTTPS product page.' It also clarifies its role as a pre-purchase quote with 'Never purchases,' which helps distinguish it from purchase or transaction 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?

Provides clear usage context: use it 'before an agent buys.' It also explicitly excludes purchasing behavior. However, it does not name sibling alternatives or state when not to use this tool beyond not purchasing.

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

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

With no annotations provided, the description carries the full burden. It discloses the paid nature ($0.065 USDC on Base), the input constraints (up to 3 pages), the comparison behavior (expected purchase fields and line items), and the non-mutating outcome (no payment or bookkeeping action). It does not mention rate limits, failure modes, or what happens with invalid documents, but the core behavioral traits are well covered.

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 sentences with no wasted words. It front-loads the most important operational facts (paid, format, page limit) and then states the comparison behavior and the non-action guarantee. 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?

The tool has 5 parameters, a nested expected object, an output schema, and no annotations. The description covers the input formats, the comparison logic, the output categories, and the non-mutating nature. It does not explain the output schema in detail, but the output schema exists and the description's summary of return categories is sufficient 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?

Schema description coverage is 0%, so the description must compensate. It explains the purpose of the 'expected' object (expected purchase fields and line items) and the document input options (UBL XML or PDF/image). It does not detail each parameter's format or constraints, but the schema itself provides patterns and enums, and the description gives enough context to understand what the parameters represent.

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 ('check'), a clear resource ('paid invoice'), and the exact scope: UBL XML or PDF/image invoices up to 3 pages. It also names the output categories (evidence, amount checks, match/discrepancy/needs_review) and explicitly says no payment or bookkeeping action is taken. This distinguishes it from the sibling tools that handle more pages or provide quotes.

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 what input formats are accepted (UBL XML or complete PDF/image invoices up to 3 pages) and what the tool does not do (no payment or bookkeeping action). It does not explicitly name the sibling alternatives or state when to choose invoice_preflight_10_pages or invoice_preflight_50_pages, but the page limit and the sibling names make the usage context reasonably 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?

With no annotations provided, the description carries the full burden, and it discloses the most decision-critical behavior: the $0.13 USDC payment and the fact that oversized documents are rejected before OCR (i.e., before incurring cost). This is exactly the high-value context an agent needs for a paid tool; what is missing is any note on side effects or failure modes beyond the size rejection.

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, about 25 words, with the most critical facts front-loaded (cost first, then resource, format, page limit, and rejection behavior). Every clause earns its place and nothing is redundant.

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

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

For a paid tool with a nested schema and no annotations, the description adequately covers cost, format, and page scope. However, it leaves meaningful gaps: the semantics of the 'expected' field are unexplained, and the relative use of document_url versus document_base64 (neither required) is unaddressed, though the output schema partially offsets the need to document 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?

Schema description coverage is 0%, so the description must compensate, but it only adds a marginal hint that 'PDF/image' maps to the mime_type enum. The 'expected' nested object — the apparent core of the preflight concept, containing tax, total, line_items, etc. — is completely unexplained, and there is no guidance on choosing between document_url and document_base64.

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 clear function — OCR on PDF/image invoices — plus a specific scope ('up to 10 pages'), which distinguishes it from the sibling invoice_preflight_50_pages by page limit and from invoice_preflight_quote by document type. The verb 'process' is somewhat generic, but the OCR framing and page constraint make the purpose unambiguous.

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

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

The page ceiling ('up to 10 pages') plus 'Oversized PDFs are rejected before OCR' gives an explicit, actionable boundary for when this tool applies versus the 50-page sibling. It does not name alternatives explicitly, but the page-count criterion is the operative routing signal and it is stated clearly.

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

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

With no annotations, the description carries the full burden. It discloses the cost ($0.475 USDC), the page limit, and the rejection behavior for oversized PDFs. It does not disclose auth requirements, whether failed calls are charged, or side effects, but the disclosed cost and rejection behavior add meaningful 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 two tight sentences with no fluff. Cost and page limit are front-loaded, and the rejection behavior earns its place. It is concise without being under-specified for what it chooses to cover.

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 has four parameters, a nested expected object, no annotations, and is a paid operation, the description is incomplete. It does not explain how to provide the document, what the expected fields are for, whether the fee applies to rejected inputs, or how to choose among the sibling tools.

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 0%, so the description should compensate, but it does not explain any of the four parameters. It hints at mime_type via 'PDF/image' and at document size via '50 pages', but it never clarifies document_url vs document_base64, the expected object, or how the parameters relate to the OCR process.

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 (OCR), resource (invoices), accepted formats (PDF/image), and a key constraint (up to 50 pages). It distinguishes itself from invoice_preflight_10_pages through the page limit, though it does not explicitly name sibling alternatives.

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: this is a paid OCR tool for invoices up to 50 pages, and oversized PDFs are rejected. However, it does not explicitly say when to choose this over invoice_preflight, invoice_preflight_10_pages, or invoice_preflight_quote, nor does it state exclusions beyond the page limit.

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

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

With no annotations, the description carries the burden and does well: it discloses cost ('FREE'), side-effect freedom ('no wallet or document upload'), and non-inspection ('does not inspect or validate'). It doesn't explicitly state that it returns a quote or price, but the name and purpose strongly imply it.

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 tight sentences, each earning its place: one for pricing/inputs, one for when to call, one for what it doesn't do. The 'FREE' qualifier is front-loaded, and there is zero redundant content.

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

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

The output schema exists, so return values need no explanation. The description covers prerequisites (none), cost, side effects, and invocation timing. Minor gap: it doesn't explain whether page_count applies only to PDF or also to other document types, though the phrase 'PDF page count' implies it.

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

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

Schema description coverage is 0%, so the description must compensate. It adds useful context by mapping 'PDF page count' to page_count (limiting it to PDFs) and calling file_size_bytes 'optional.' It doesn't clarify enum meanings for document_type or range behaviors, but the schema already provides those constraints.

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 a specific job: quote the lowest-priced Invoice Preflight tool based on document type, page count, and byte size. It explicitly distinguishes itself from actual preflight work with 'It does not inspect or validate the document,' preventing confusion with the sibling preflight 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?

It gives an explicit trigger condition: 'Call this before a paid invoice tool when the tier is uncertain.' It also states this is free and requires no wallet/upload, which clarifies it is a safe preliminary step. It doesn't name sibling alternatives directly, but the intent to route before paid tools is clear.

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

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

No annotations are present, so the description carries the burden. It discloses the read-only nature, the $0.01 cost, and that inspected tools are never called. It does not cover failure modes or payment prerequisites, but the core safety and cost behavior is clear.

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?

One dense sentence front-loads cost and safety, then enumerates the tool's actions. There is no filler or 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?

An output schema exists, so return values are covered. The description addresses purpose, cost, safety, and the roles of both parameters. Minor gaps such as payment flow details and failure behavior do not prevent correct selection or invocation.

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 0%, so the description must compensate. It maps endpoint to 'public HTTPS MCP endpoint' and expected_tools to 'compare expected tool names', adding meaningful semantics beyond the raw schema. It does not detail constraints like maxLength or optionality, but the schema already provides those.

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

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

States a specific action set: verify a public HTTPS MCP endpoint, list tool names, summarize input schemas, compare expected tool names, and flag risky metadata. This clearly distinguishes the tool from the unrelated invoice_preflight 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?

Establishes clear usage context: a paid, read-only check for public HTTPS MCP endpoints, with inspected tools never called. It does not explicitly name alternatives or give when-not conditions, so it stops short of a 5.

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

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

With no annotations, the description carries the full transparency burden, and it succeeds: it discloses the cost, the no-LLM guarantee, the recommendation-only behavior, the absence of invocation or second payment, and the degraded local-only fallback when the environment variable is missing.

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

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

The description is dense and front-loaded with fee and purpose. Every sentence contributes meaningful operational detail (ranking factors, no LLM, no invocation, fallback behavior). It is longer than minimal, but the additional clauses justify themselves.

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 return structure, but parameter usage remains ambiguous due to 0% schema description coverage and no param-level elaboration in the description. The behavioral and failure-mode context is strong, so the tool is not under-specified overall, but an agent may struggle to populate 'query' vs 'capability' 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 0%, so the description must explain parameters, but it does not name or define 'query', 'capability', 'constraints', or 'preferences'. It references 'hard constraints' and ranking factors like price/latency/reliability, which loosely map to the schema, but the crucial distinction between 'query' and 'capability' is left unstated.

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 a specific action ('Finds and ranks') on a distinct resource ('machine-payable MCP services and x402 HTTP endpoints'). It also clarifies the non-execution boundary ('Returns a recommendation only'), which differentiates it from provider-invoking 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 gives clear context for when to use the tool: 'before your agent chooses or pays a provider'. It also explains that it never invokes the provider or makes a second payment, which implies it is a pre-payment routing step. It does not explicitly name alternative tools or exclusions.

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

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

With no annotations, the description carries full disclosure burden. It reveals the $0.03 USDC cost, states it 'Rejects stale books,' and clarifies it does not place orders. It does not mention rate limits or auth, but the read-only nature and fee are clearly disclosed.

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 sentences with no filler. It front-loads the cost and core operation, then lists exclusions efficiently. Every clause adds useful information.

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

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

For a paid, 6-parameter tool with an output schema and no annotations, the description covers purpose, cost, stale-book handling, and safety. It omits some parameter semantics and alternative routing, but the schema supplies defaults/enums and the output schema covers return values, making it nearly 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 description coverage is 0%, so the description must compensate. It explains trade_size_usd ('requested trade size'), fee_bps_by_venue ('caller- or server-configured taker fee assumptions'), and venues ('Binance and Coinbase'). However, quote_asset and min_net_spread_bps are left undocumented, though their names/defaults make them partially inferable.

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: it 'Compares Binance and Coinbase public spot order books at a requested trade size and applies... taker fee assumptions.' It also differentiates from siblings by explicitly saying it 'does not place orders' and excludes guaranteed execution, so an agent can distinguish it from execution or quote 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 usage for arbitrage scanning and gives negative boundaries ('Excludes transfers, inventory rebalancing, and guaranteed execution; does not place orders'), but it never names sibling alternatives like get_live_quote or estimate_trade_execution, nor states explicit when-to-use versus 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?

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the payment cost, bounded deterministic local scanning, the absence of external LLM/provider calls, the 100000-character limit, and what the tool returns. Nothing in the description contradicts schema or annotations.

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

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

The description is compact and front-loaded: it leads with cost and core purpose, then gives usage timing, outputs, technical behavior, and limits. Every sentence adds distinct value without repetition 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 that an output schema exists, the description covers the remaining essential context: cost, when to use, input types, size constraints, determinism, privacy behavior, and output expectations. An agent has enough information to select and invoke this tool correctly.

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

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

The schema has 0% description coverage, so the description must compensate. It elaborates on content by listing accepted formats and the character limit, and it effectively explains the content_type options in plain language. The optional `source` parameter is not described, but its role is inferable as an identifier for the scanned content.

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 and object: 'Scan untrusted text, HTML, Markdown, email, document text, API responses, and tool outputs.' It clearly explains what is scanned and what output is returned (risk score, categories, recommendation, sanitized text), and its content-scanning focus differentiates it from sibling tools like check_url and invoice_preflight.

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

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

The description gives explicit timing guidance: scan content 'before your agent adds them to context, follows their instructions, or acts.' It does not name alternative tools or explicitly say when not to use it, but the supported content types make the intended use 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the $0.02 USDC payment, that it never signs/holds keys/broadcasts, that private keys/seed phrases must never be sent, and that return values include execution status, gas estimate, and risk. It also honestly flags the limitation that calldata decoding is not a complete state diff.

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 tight sentences with no filler. It front-loads the cost and purpose, then states return values, limitations, and security rules in order of importance. 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?

An output schema exists, so the description does not need to explain return value structure. It still summarizes the key return categories, cost, safety guarantees, and an important limitation. For a preflight simulation tool, this is sufficient for an agent 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 description coverage is 0%, so the description must compensate. It adds meaningful context by mentioning Base as the chain and ERC-20 transfer/approval calldata, which maps to the data parameter. It does not explain value denomination, the exact meaning of each required field, or hex encoding conventions, so compensation is partial rather than complete.

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 and resource: 'Simulates an unsigned Base transaction before an autonomous agent signs or broadcasts it.' This clearly defines the tool's scope and distinguishes it from signing/broadcasting tools. The sibling set contains no other transaction simulator, so there is no ambiguity.

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 states when to use the tool: before an autonomous agent signs or broadcasts a transaction. It also gives a when-not-to-use warning: 'do not treat calldata decoding as a complete state diff.' However, it does not name a specific alternative tool, so it stops short of full alternative routing.

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

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

With no annotations, the description carries the full burden and does it well. It discloses the cost ($0.01 USDC), the failure mode before payment when GOPLUS_ACCESS_TOKEN is missing, the separation of provider findings from internal scoring, and the explicit non-guarantee of safety. This is exemplary behavioral disclosure for a mutated/paid workflow.

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, each earning its place: cost, core behavior, prerequisite, and caveat. The paid nature is front-loaded, and no words are wasted. It is concise while still covering essential operational details.

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?

Despite having only 2 parameters and an output schema, the description covers cost, authentication requirement, error behavior, output segregation, and limitations. Nothing critical for an agent to invoke this tool correctly is missing, and the output schema handles return-value documentation.

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 0%, so the description must compensate, but it does not explicitly explain 'chain' or 'token_address'. It only mentions 'supported EVM tokens' generically. The schema's enum and regex provide format hints, but the description adds little semantic meaning about which parameter is which or how they relate to the audit.

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 ('Normalizes GoPlus token-security flags and public EVM RPC metadata') and a clear resource ('supported EVM tokens'). The paid audit scope is front-loaded, and the tool name aligns with the described behavior, distinguishing it from sibling tools like check_wallet or analyze_whale_activity.

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 context: when you need a security audit of an EVM token, with a prerequisite (GOPLUS_ACCESS_TOKEN) and a limitation ('Does not trade or guarantee token safety'). It does not explicitly name alternatives or provide when-not-to-use guidance, so it stops at implied usage rather than explicit routing.

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

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

With no annotations, the description carries the full behavioral burden and excels: it discloses the $0.02 USDC payment, the required API key, the failure mode before payment, and that claim text is sent to an external search provider. This covers cost, authentication, error behavior, and data flow.

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: purpose, result categories, prerequisite, and error behavior. The core function is front-loaded, and the total description is compact 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 tool with no output schema and no annotations, the description covers the key behavioral aspects well: payment, key requirement, failure path, and what the tool returns. However, two parameter semantics are missing, so an agent cannot be fully confident in constructing a valid call, especially for optional fields.

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

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

Schema description coverage is 0%, so the description must explain the parameters, but it only implicitly covers `claim` ('factual claim') and says nothing about `freshness_days` or `preferred_domains`. An agent would have to guess their exact role and format, leaving two of three parameters underspecified.

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 ('Checks a factual claim'), a clear resource (fresh web search evidence), and exact result categories (supported/contradicted/mixed/insufficient/stale with sources). It also opens with the paid nature, making the tool's purpose instantly identifiable and distinct from the unrelated crypto-analysis 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 provides strong operational context: it is paid, requires TAVILY_API_KEY, and details what happens if the key is missing. It doesn't explicitly name alternatives or when-not-to-use scenarios, but the unique claim-verification purpose makes the intended use obvious.

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