Tollkit

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

Annotations only cover read-only and open-world safety, but the description adds substantial operational context: pricing ($0.003 USDC per call over x402), that failed calls cost nothing, a quote-then-pay flow, and a 3-free-calls-per-day allowance. This is precisely the auth/cost/failure behavior an agent needs 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?

Front-loads the purpose and data returned, then a second short paragraph for the payment model. Both earn their place for an x402 tool; only mild redundancy with the payment schema field keeps it from a 5.

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 no output schema, the description usefully describes the return payload (delay types with minutes/trend/reason, closures) and covers the payment prerequisite. It is essentially complete for a read-only, open-world lookup, missing only explicit return-shape/pagination notes.

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

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

Schema description coverage is 100%, so both the airport code and the payment quote flow are already documented. The description restates these ('give an airport code, or none' and the quote workflow) with essentially no new syntax or format detail, so baseline 3 applies.

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

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

States a specific verb (Check) and resource (US airport delays) sourced from the FAA's live National Airspace System, and enumerates exactly what is returned: ground stops, ground delay programs, arrival/departure delays with minutes/trend/reason, and closures. No sibling tool overlaps, so the agent can identify it immediately.

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

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

Gives clear invocation context: supply an airport code, or omit it to list every airport with delays right now. It does not name an alternative or an explicit when-not-to-use condition (none meaningfully exists in the sibling set), so it falls just short of the top band.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses cost ($0.01 USDC per call over x402), that failed calls are free, the quote-then-sign flow, the ranking methodology and its anti-gaming rationale, and an honest conflict-of-interest disclosure about Tollkit ranking its own tools (marked sold_by_tollkit). This is exactly the extra context annotations cannot carry.

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 tight paragraphs, purpose front-loaded in the first sentence, with pricing and the quote mechanism at the end. The Tollkit disclosure is a slight digression but is materially relevant to trusting the ranking, so it 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 discovery tool with no output schema, the description covers what is returned (ranked sellers, one endpoint each, price, caution flags), the cost model, and the two-step payment flow. It is nearly complete; only the unmentioned `limit` and the exact response shape are left unaddressed.

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 67%: `task` and `payment` are documented in the schema, while `limit` has none. The description usefully reinforces the payment flow (omit it to receive a quote; sign and call again) but says nothing about the undocumented `limit` parameter, so it only partially compensates for the coverage gap.

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

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

States a specific verb and resource ('Find the best paid x402 API for a task') and details what the result contains (ranking by paying wallets/repeat buyers, one endpoint per seller, price, caution). However, it never names the sibling it should be distinguished from (e.g. x402_seller_lookup or find_service), leaving the agent to infer the boundary.

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 quote-first workflow ('Call without `payment` to get a quote') and 'Failed calls cost nothing' are actionable invocation guidance, but the description gives no when-to-use/when-not guidance relative to the many service-discovery siblings. Usage is implied by the task parameter rather than routed explicitly.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavioral context: the call is free, returns a balance plus a refill link, and the tool operator never holds funds or keys. It does not contradict the annotations.

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

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

Three short sentences, with the core purpose front-loaded. The 'Free' opening and the trust statement add useful context rather than pure filler. A minor typo ('Tollkit') slightly detracts, but the overall structure is tight and scannable.

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 simple read-only nature, the fully documented schema, and the annotations, the description provides enough to call the tool correctly: wallet scope, network, output (balance + refill link), and safety expectations. It does not describe error cases or threshold behavior, but those are minor for this operation.

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

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

Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description adds some context by specifying 'USDC' and pointing to the user's own wallet, but it does not meaningfully enrich the parameter-level guidance, so the baseline 3 applies.

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

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

The description clearly states the verb and resource: 'Check how much USDC is left in your own wallet on Base.' It identifies the exact scope (own wallet, Base network) and is readily distinguished from the provided sibling tools, which are about products, attestations, and service info.

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 practical context for when to use the tool: 'so you can tell your human before you run out.' It does not explicitly name alternatives or exclusions, but no sibling tool appears to cover balance checking, so the missing contrast is less critical.

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=true and openWorldHint=true, so the safety profile is covered. The description adds substantial behavioral context: it explicitly says the tool does not score or recommend, returns facts and named signals, and compares against a public listing. This goes well beyond the annotations and gives the agent precise expectations.

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 'Free.' and then concentrates on the core purpose and behavioral traits. Every sentence adds value, and the exclusion 'does not score or recommend' is a meaningful, concise addition. No fluff.

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

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

For a two-parameter read-only tool with no output schema, the description fully explains what the tool returns (charges, wallet, network, comparison data, named signals) and what it does not do. There is nothing an agent needs to know to call this correctly that is missing.

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

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

Schema coverage is 100% for both parameters (url and method). The description does not add meaning beyond the schema, but the schema already documents each parameter adequately, 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 states a specific verb ('probes') and resource ('x402 endpoint') and clearly differentiates from siblings by emphasizing 'before paying' and 'without paying'. It also distinguishes from Tollkit-related services, making it clear this is a standalone check tool.

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

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

The description gives strong contextual guidance: use it before paying, it's free, and it works for non-Tollkit services. However, it does not explicitly name alternative tools (e.g., get_service_info) or state when not to use it, so it falls short of perfect 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds real behavioral context beyond them: the x402 pricing model ($0.03 USDC per call), that failed calls are free, and the two-step quote-then-pay handshake. It omits latency or rate-limit behavior, but the payment mechanics are the significant disclosure here.

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

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

Front-loaded with the capability list, followed by a compact payment/cost line. Every sentence carries information; the only mild redundancy is the 'in one call' phrasing that recurs implicitly in the enumeration.

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 no output schema, the description does the necessary work of enumerating return content (profile, ratios, filings with links, plain-English 8-K summaries), so an agent knows what comes back. Pricing and the payment handshake are covered; only the cik parameter's meaning is left to 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?

Schema coverage is 67%: ticker and payment are documented in the schema, cik is not. The description reinforces the payment parameter's intent by explaining the quote-first workflow, but adds nothing about cik's format (10-digit SEC identifier) or the ticker/cik mutual exclusivity beyond what the schema already says.

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

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

States a specific verb and resource ('Run due diligence on a US public company') and enumerates exactly what the call returns: profile, growth, margins, leverage/cash ratios, filings, and 8-K summaries. The 'in one call' framing implicitly separates it from the narrower siblings sec_company and sec_financials, though it never names them explicitly.

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

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

Gives clear operational guidance for the payment flow ('call without `payment` to get a quote'), but says nothing about when to pick this composite tool over sec_company, sec_financials, or company_snapshot, which appear to be the obvious alternatives. Usage is implied by scope rather than stated.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely useful behavior beyond them: a concrete price ($0.006 USDC over x402), that failed calls are free, and a two-step quote-then-pay handshake. It stops short of stating rate limits, latency, or result shape, but the cost/payment disclosure is substantial for a paid tool.

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

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

Two short paragraphs, front-loaded with what is returned and followed by the commercial mechanics. Every sentence carries information the agent needs — scope, contents, price, failure cost, and the quote flow — 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?

With 5 parameters, zero required, no output schema, and a read-only open-world profile, the description does the work an output schema would have done by listing the returned sections and the financial time ranges. The one real gap is that it never clarifies its relationship to the sec_company/sec_financials siblings.

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 80%, so the schema already documents cik, ticker, form, filings, and payment. The description adds no parameter-level syntax or defaults beyond the schema, and the one detail it does touch (omitting payment yields a quote) is already in the payment field's schema description. 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 names a specific verb and resource ("Get a one-call snapshot of a US public company from SEC EDGAR") and enumerates the payload: profile, recent filings with links, and named financial metrics. It never distinguishes itself from the closely related siblings sec_company and sec_financials, so an agent cannot tell from the text alone why it should pick this aggregator over those granular 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?

Usage is implied by "one-call snapshot" (use when you want everything at once) and the payment protocol is spelled out procedurally. However, there is no explicit when-to-use/when-not statement and no routing to the sibling tools that appear to cover the same SEC data, which is the most likely agent confusion here.

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, so the description carries the full burden and does so: flat $0.04 cost, partial-success batches billed in full, all-fail batches not charged, duplicates deduplicated and unbilled, and per-URL ok/error so one failure doesn't lose the rest. This is exactly the pricing and failure-mode detail an agent needs.

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

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

The critical routing rule is front-loaded in caps, and the billing paragraph is deliberately explicit. Slightly long with emphasized fragments, but every sentence carries a distinct fact (cost, billing, dedupe, return shape) rather than padding.

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

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

Given an output schema exists, the return explanation is a bonus rather than a necessity, and the description still covers cost, billing edge cases, and the sibling relationship. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds ordering semantics ('one entry per URL in the order given'), duplicate handling, and the allow_redirect scope ('Applies to every URL'). Marginal but real value 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?

States a specific verb and resource ('Price the same product at several stores') with an explicit scope of up to 5 URLs in one call. It clearly distinguishes itself from get_product_details by contrasting the batching model against one-call-per-URL.

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

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

Gives an unconditional directive ('USE THIS WHENEVER YOU HAVE MORE THAN ONE URL'), lists scenarios (comparing across stores, checking a short list, refreshing tracked prices), names the alternative get_product_details, and even states when that alternative is better ('If you have one URL and are unsure it is live').

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

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

Goes well beyond the annotations: discloses that rates come from the ECB and are informational only, not for transactions; specifies pricing ($0.002 USDC per call over x402), that failed calls cost nothing, and that the first 3 calls/day are free without a wallet. This is exactly the rate-limit and cost context an agent needs.

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

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

Front-loaded with the core purpose, followed by source/caveat and then payment mechanics. Three short paragraphs, each earning its place; slight verbosity in the pricing detail but nothing 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 read-only conversion tool with no output schema, the description covers source, coverage, date range, and payment flow. It does not describe the response shape (e.g., rate vs converted amount), a minor gap given the output schema is absent.

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

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

Schema coverage is already 80%, so the schema documents from/to/date/amount. The description adds meaningful semantics for `payment` (omit it to receive a quote, sign and call again) and corroborates the 90-day date window, going beyond 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?

States a specific verb (convert) and resource (currencies) with clear scope: ECB reference rates covering 30 currencies for the latest business day or any day in the last 90. An agent can immediately distinguish this from siblings like token_price or wallet_balance.

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

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

Gives clear usage context (currency conversion using official ECB rates) and an operational hint: call without `payment` to get a quote first. It does not explicitly name an alternative sibling or state when-not-to-use, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds concrete behavioral detail: it 'checks each result live without paying', explains ranking by live price quote and distinct paying wallets, and warns that 'nobody pays for placement'. It also discloses that descriptions are the sellers' own words, adding context beyond structured annotations.

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

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

The description is compact and front-loaded: it opens with the core action ('Searches ...'), then adds behavioral and ranking details. Every sentence contributes distinct information with 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?

For a 2-parameter, read-only search tool, the description covers discovery purpose, live-check behavior, ranking, and the caveat about seller-written descriptions. It does not detail the result output structure, but no output schema exists and the description gives enough to infer what results contain. Minor gaps like potential latency are acceptable.

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

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

Schema coverage is 100% and both parameters have descriptions. The description adds value by giving example query values ('product price lookup', 'send sms', 'web page screenshot'), which clarifies the expected format of the query parameter beyond the schema's generic 'What you need done, in plain words.'

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

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

The description states a specific verb-resource pair: 'Searches Coinbase's public x402 discovery index for services that do a task' and gives concrete examples. The title also clarifies its role. It distinguishes itself from siblings like check_service by searching an index rather than checking a specific service.

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: use this to find a service for a task without paying, and notes that it live-checks results. However, it does not explicitly name alternatives or exclusion conditions, nor does it say when to prefer this over siblings like check_service or get_service_info.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds material behavior beyond that: per-call pricing ($0.002 USDC over x402), that failed calls are free, and the two-step quote-then-pay flow. It does not discuss rate limits beyond the free tier or error semantics for malformed addresses, keeping it short of a 5.

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

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

Front-loaded with the core transformation and returned fields, then a tight second paragraph on constraints and pricing; every sentence earns its place. Slightly dense with billing detail, but none of it is filler for an agent that must decide whether to call.

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?

There is no output schema, so the description compensates by enumerating the return fields directly, and it covers the cost/payment behavior an agent needs before invoking a paid tool. For a two-parameter read-only lookup, nothing essential is missing.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, and the description's 'US street addresses only (with a house number)' largely restates the schema example's format. The quote/payment flow adds some conceptual framing but no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

Specific verb+resource: turns a US street address into latitude/longitude, and it goes further by enumerating the derived outputs (standardized address, ZIP, county, FIPS, state, census tract) and naming the data source (US Census Bureau geocoder). No sibling tool competes for this function, so the purpose is 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?

States a clear eligibility constraint ('US street addresses only (with a house number)'), which tells the agent when the tool is not applicable. It also guides the payment workflow (call without `payment` for a quote, first 3 calls free). No alternative tool exists to route against, so the absence of an explicit alternative is not a real gap.

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, so the description carries the full burden and does so richly: headless-browser rendering, x402 payment flow (call once without payment, then pay), $0.01 USDC cost and sponsored gas, provenance.declared vs provenance.inferred semantics with an explicit 'act on declared, verify inferred' rule, free refusal on cross-page redirects, no-charge failed extractions, and 300-second cache re-serving. This is far beyond annotation-level 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?

Front-loaded and well-sectioned with USE THIS WHEN / DO NOT / RETURNS / HOW / COST / provenance headings that scan cleanly. It runs long, but nearly every sentence carries decision-relevant payload (cost, payment protocol, provenance trust rule); a slight trim would reach 5.

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 an output schema existing, the description still adds value by explaining provenance trust tiers, null-for-missing-fields policy, image cap, and payment mechanics. For a paid, multi-step tool with a bespoke auth flow, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds the x402 call-twice protocol, explains why allow_redirect is refused (wrong-product risk), and clarifies url must be a single product page. It complements the schema with usage semantics the schema descriptions don't carry.

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

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

States a specific verb+resource+scope: extract product fields and price from ONE product URL. It explicitly distinguishes from search/category pages and names the sibling try_it_free for free previews. An agent can tell it apart from read_page, page_brief, and compare_products without opening schemas.

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

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

Explicit 'USE THIS WHEN' enumerates concrete jobs (cross-store comparison, price tracking, stock checks, catalogue ingestion) and 'DO NOT USE THIS FOR' lists exclusions (search/category pages, paywalled/login pages, non-product pages, private addresses). This is textbook when/when-not 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?

readOnlyHint covers the safety profile, and the description adds that the tool is free and returns a description rather than sample output. However, it does not explain what 'Free' means or characterize the returned fields beyond a short list, so behavioral detail remains thin.

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 short sentences with no redundant schema repetition, and the alternative call is placed at the end. The leading sentence fragment 'Free.' is terse but not wasteful; minor structural polish would make it a 5.

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 zero-parameter, read-only info tool, the description covers what the agent gets (price, network, return description) and where to go for a sample, which is sufficient to invoke correctly. It stops short of enumerating the output format, but try_it_free covers that need.

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 zero parameters, so there is no parameter meaning to document; the baseline of 4 applies. The description does not need to compensate for any parameter documentation gap.

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 the tool surfaces service-level information ('Price, network, and what this service returns') and distinguishes itself from try_it_free by offering a description rather than a sample. It is clear enough, though it leans on the tool name for the verb and leaves the leading 'Free.' slightly ambiguous.

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 routes to try_it_free when the agent needs an actual output sample rather than a description, which is a clear use-vs-alternative condition. It does not discuss compare_products or get_product_details, but their names make the boundary less critical.

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

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

Annotations only declare readOnlyHint and openWorldHint, but the description adds substantial beyond-schema behavior: the $0.002 USDC price, that failed calls cost nothing, the quote-then-sign payment handshake, and the first-3-calls-per-day free tier. This is exactly the pricing/auth/risk context an agent needs before invoking.

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

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

Front-loads the core capability, then tacks on accuracy caveat, data attribution and pricing in short sentences with little waste. The DB-IP license line is compliance-relevant though slightly peripheral for tool selection, keeping it just below a 5.

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?

There is no output schema, yet the description specifies the return fields and accuracy level, and covers cost and the payment handshake. That is nearly everything needed to call it correctly, with only minor gaps (e.g., error behavior on invalid IPs).

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

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

Schema description coverage is 100%, so the schema already documents both the 'ip' and 'payment' parameters including the quote/sign flow. The description's mention of calling without payment largely restates the schema's own payment note, adding no new syntax or format detail. 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?

States a specific verb+resource ('Find where an IP address is') and enumerates the returned fields (country, region, city, continent, approximate coordinates) plus the accuracy boundary. However, it does not distinguish itself from the sibling geocode_address, which is the closest ambiguous alternative, so it falls short of a 5.

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

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

Gives clear operational context: city-level accuracy rather than a street address, the x402 payment flow ('Call without payment to get a quote'), and the free daily tier. It stops short of stating explicit when-not-to-use cases or naming an alternative tool, so no 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 establish that this is a read-only, open-world operation. The description adds useful behavioral context beyond that: pricing, free failed calls, the x402 quote flow, and that it reports when the page was longer than the summarized portion.

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

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

The description is front-loaded with the core purpose, followed by truncation behavior and payment details. Every sentence carries useful information and there is no filler.

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

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

With no output schema, the description does describe key return elements: summary, title, final URL, and truncation notice. It also covers payment behavior, though it could say more about summary format or error handling beyond failed calls being free.

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

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

Schema description coverage is 100%, so the schema already documents `url`, `payment`, and `max_words` thoroughly. The description reinforces the payment workflow but adds little parameter-level meaning beyond what is already in the schema.

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

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

The description states a specific verb and resource: read a web page and return a summary plus title and final URL. It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like read_page or screenshot_page.

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 payment workflow is clearly specified: call without `payment` to get a quote, then sign and call again. However, there is no guidance on when to use this tool instead of alternatives such as read_page, so the agent must infer the use case.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond by disclosing size/page limits, the text-layer requirement, per-call pricing, that failed calls are free, the daily free tier, and the quote-then-sign payment handshake. This is exactly the behavioral context an agent needs.

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

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

Front-loads purpose, then capability limits, then pricing/billing mechanics. Every sentence carries information, though the pricing paragraph is dense and slightly marketing-flavored rather than purely operational.

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 stateless read tool with no output schema, the description covers return contents, input constraints, failure behavior, and the two-step payment flow. An agent has everything needed to decide to call it, quote, and retry with payment.

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

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

Schema description coverage is 100%, so the input schema already documents url, payment and max_pages fully. The description reinforces the payment flow ('call without payment to get a quote') but adds no syntax or format detail beyond what the schema already provides. 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?

States a specific verb (read), a precise resource (PDF from an http(s) URL), and the exact return shape (text page by page plus title, author and page count). This clearly separates it from sibling reading tools like read_page, page_brief and screenshot_page.

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

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

Gives solid context on when it works and when it does not: text-layer PDFs up to 25 MB/300 pages succeed, scanned PDFs without a text layer are refused, and the payment quote flow is spelled out. It does not explicitly name an alternative sibling (e.g., read_page) or state when to prefer one, so it falls short of a 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses cost ($0.01 USDC per call over x402), that failed calls are free, and the two-step quote-then-sign flow when `payment` is omitted. It also sets a scope expectation with "Facts, not advice" — behavioral context the annotations cannot convey.

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

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

The purpose and return contents are front-loaded in one dense sentence, followed by a compact second paragraph on pricing and the payment flow. Efficient overall, though the first sentence packs six comma-separated outputs into a single breath.

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 no output schema, the description correctly takes on the burden of describing what comes back (price, liquidity, warnings, impact, holdings, web results) plus cost and payment flow. The remaining gap is that it never positions itself against the many similarly named token/wallet balance siblings.

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 every parameter is already documented in the schema, giving a baseline of 3. The description restates parameter roles (trade size vs pool depth, wallet holdings, chain) at roughly the same level of detail as the schema, adding little beyond it.

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 pre-trade check and enumerates exactly what it returns: USD price, liquidity, on-chain warnings, rough price impact, wallet holdings, and web results. It is clear and concrete, but it never differentiates itself from near-named siblings like token_check, token_info, or token_price, leaving the agent to guess which one to call.

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?

"Before trading a token" gives a clear, actionable usage context, and the payment mechanics tell the agent the actual call sequence (quote first, then pay). However, it names no alternatives and gives no exclusions, despite several sibling tools that appear to overlap heavily in scope.

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

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

Annotations only cover readOnlyHint/openWorldHint, but the description adds substantial behavior the agent could not otherwise know: browser rendering for JS pages, redirect resolution, the 50k truncation limit, the x402 price model, that failed/empty loads are free, the 3-free-calls-per-day tier, and the quote-then-pay round trip. That is exactly the value-add expected on top of 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 short sentences/paragraphs, each carrying distinct information: what comes back, when to use it, and the payment mechanics. Capability, usage, and cost are front-loaded in that order 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?

With no output schema, the description carries the return-value burden itself and does so (visible text, title, redirected URL, size ceiling). Combined with the fully-covered input schema and annotations, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so both `url` and `payment` are already documented in the schema, including the omit-to-get-a-quote flow. The description restates the payment quoting behavior but adds no new syntax, format, or constraint beyond what the schema provides, making the baseline 3 the correct call.

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

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

States a specific verb and resource ('Read any public web page and get its visible text back') and details the output shape: visible words, nav/boilerplate stripped, title, final URL after redirects, JS rendered, 50k cap. It never names a sibling (page_brief, screenshot_page, pdf_to_text), so the agent must infer the boundary itself rather than being told.

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

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

Gives clear positive context ('read an article, a doc, a policy or any page you were given a link to') and even a chaining hint (pair with a summarizer for long pages). It stops short of any exclusion or alternative comparison, so when NOT to use it versus page_brief or search_and_read is left to inference.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the payload size (50-150 KB base64), the exact cost ($0.003 USDC per capture over x402), that failed loads are free, the quote-then-pay workflow, and a free tier of 3 calls/day without a wallet. These are the behavioral facts an agent needs to budget and sequence calls.

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 paragraphs, front-loaded with purpose and output, then usage/alternative, then pricing mechanics. Every sentence carries distinct information (format, use cases, alternative, price, failure cost, quote flow, free tier) 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?

With no output schema, the description fully carries the return burden (base64 JPEG, SHA-256, title, final URL, size), and it also covers the payment lifecycle and failure semantics. Nothing material for correct invocation is missing.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds marginal value by tying the `payment` parameter to the quote-and-retry workflow ('Call without payment to get a quote') and confirming the URL must be a public page, though much of this overlaps the schema text.

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

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

States a specific verb (capture) and resource (public web page) and immediately specifies the concrete output format (1280x800 JPEG, base64, SHA-256, title, final URL). It also implicitly distinguishes itself from siblings like attest_page and read_page by describing a rendered screenshot rather than text or signed evidence.

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

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

Gives explicit use cases ('see a page's layout, check that something renders, or hand the image to a vision model') and names the alternative with its selecting condition: 'For signed, timestamped evidence of a page use attest_page instead.' That is when-to-use plus when-to-use-something-else.

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

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

Annotations only declare readOnlyHint and openWorldHint, so cost and payment behavior must come from the description — and it delivers: $0.002 USDC per call over x402, failed calls cost nothing, omit `payment` to receive a quote and re-call, and a free tier of 3 calls/day without a wallet. This is genuinely additive context. It loses a point for not mentioning the result cap (limit max 40) or any rate/coverage limits on EDGAR data.

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

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

Front-loaded with the core capability and return contents, then a compact pricing/payment paragraph. Every sentence carries information. Minor redundancy with the schema ("Filter by form type" restates the `form` field description).

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 no output schema, the description does the work of describing returns (profile fields plus filings with direct links), and it fully covers the non-obvious x402 payment handshake. Remaining gaps are the undocumented `limit` cap and `cik` format, which an agent must infer.

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 60%: `form`, `ticker`, and `payment` are documented in the schema, while `cik` and `limit` carry no description anywhere. The description adds practical meaning for ticker/CIK lookup, form filtering, and the payment handshake, but leaves `limit` (1-40) and CIK format unexplained. Adequate but with a clear gap.

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?

Specific verb+resource: "Look up a US public company in SEC EDGAR by ticker or CIK," followed by an explicit enumeration of returned fields (legal name, exchange, industry, state, fiscal year end) and filings (10-K, 10-Q, 8-K, Form 4) with direct links. It is unambiguous what the tool does. It stops short of 5 because it never distinguishes itself from near-neighbors like sec_financials, company_snapshot, or company_due_diligence.

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

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

Gives concrete operational guidance for payment ("Call without `payment` to get a quote", first 3 calls/day free) and one filtering hint ("Filter by form type, e.g. only 10-Ks"). However it offers no when-to-use/when-not-to-use guidance relative to the many sibling lookup tools (sec_financials, company_snapshot, company_due_diligence). Usage is implied rather than scoped.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the real behavioral load and does so richly: exact cost ($0.004 USDC per call over x402), failed-call billing behavior, the quote-then-sign two-step handshake, and a per-day free allowance that needs no wallet. These are consequential traits the agent cannot infer from the annotation block.

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

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

Front-loads purpose and returned fields, then pricing and payment mechanics. Two tight paragraphs with no filler, though the parenthetical warning list is dense and could be trimmed without losing meaning.

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 no output schema, the description must describe returns and it does — enumerating what the warnings and price/liquidity sections contain per chain. Combined with the payment/cost details, nothing an agent needs to invoke this correctly (including the quote-first flow) is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds value beyond the schema: it names the three supported chains and their default, clarifies token as an ERC-20 contract or SPL mint, and explains the otherwise-cryptic `payment` parameter's role in the quote workflow.

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

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

States a specific verb (check) and resource (token) and enumerates the actual output: identity, USD price, liquidity, and chain-read warnings (owner, upgradeability, mint/pause/blacklist/fee powers, Solana mint/freeze authority). This scope implicitly separates it from price-only siblings like token_price and token_info, but it never names an alternative to anchor the distinction explicitly.

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

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

Gives a clear when-to-use trigger ('before buying, sending or accepting it') and, unusually, operational guidance for the payment flow: call without `payment` to get a quote, then sign and call again; failed calls are free; first 3 calls/day are free. It stops short of explicitly excluding or comparing against adjacent siblings such as pretrade_check or token_info.

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

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

Annotations only cover readOnly/openWorld, but the description discloses a full behavioral profile: $0.002 USDC per call via x402, failed calls are free, the quote-then-pay handshake, and a free tier of three calls per day without a wallet. This is exactly the kind of cost/auth/rate context annotations cannot express.

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 tight paragraphs, front-loaded with the capability and return fields before the payment mechanics. Every sentence carries information; the only minor cost is that the pricing block is dense, but it is genuinely necessary detail.

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 no output schema, the description steps in by enumerating the returned fields and the chain-specific extras (Solana mint/freeze authority). The payment lifecycle and free-tier carve-out are fully spelled out, leaving nothing an agent needs 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 100%, so the schema already documents `chain` (with enum and default), `token` (ERC-20 contract vs SPL mint), and `payment`. The description restates the chains and mentions the quote flow but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (look up) and resource (token) across three named chains, and enumerates the exact returned fields (name, symbol, decimals, total supply, mint/freeze authority on Solana), which cleanly separates it from the pricing-oriented token_price sibling. It never names token_check or token_price explicitly, so the differentiation is inferred from content rather than stated.

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

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

Gives a clear use case ('confirm what an address actually is before acting on it') and a concrete invocation protocol: call without `payment` for a quote, then sign and re-call. It does not state when to prefer this over token_check or token_price, so no explicit exclusions are offered.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them with pricing ($0.002 USDC per call), failure-cost behavior ('failed calls cost nothing'), the free daily quota, and the no-wallet requirement for free calls. This is exactly the kind of cost/auth/retry context an agent needs before invoking a paid tool.

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

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

Front-loads what the tool does and what it returns, then relegates billing mechanics to a compact second paragraph. Every sentence carries distinct information; 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?

With no output schema, the description compensates by enumerating the returned fields, including the Solana-specific balance-change semantics. Payment prerequisites, pricing, and the quote handshake are all covered, so an agent has everything needed 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 coverage is 100%, so the hash format, chain enum, and payment payload are already fully documented in the schema. The description's explanation of the payment/quote loop restates the schema's own payment description rather than adding format or edge-case detail. Baseline 3 applies.

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

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

Specific verb+resource ('look up a transaction') with scope narrowed to three named chains and an enumeration of exactly what comes back (success status, timestamp, sender, fee, token movements with symbols/amounts). An agent can immediately tell this is a transaction-verification tool, distinct from siblings like token_info or wallet_portfolio.

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

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

Gives a concrete use case ('confirm a payment actually landed') and a clear payment workflow (omit `payment` for a quote, sign, call again). It stops short of naming or excluding alternatives among the many sibling lookup tools, so the routing guidance is contextual rather than explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful context: 'It takes no arguments and costs nothing' and 'produced by the identical code — not a hand-written example — so what you see is what you get.' This goes beyond annotations without 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 somewhat verbose but well-structured: it opens with the core purpose, then provides usage guidance and rationale. Every sentence adds value, though it could be tightened slightly.

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 zero-parameter tool with an output schema, the description fully covers what the agent needs: what it does, why it's free, what to expect, and which sibling to use instead. Nothing essential is missing.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The description reinforces 'takes no arguments,' which is consistent. Baseline of 4 is appropriate since there is nothing more to explain.

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: 'Run a real extraction against one fixed sample product page and return the result.' It clearly differentiates itself from siblings like get_product_details by focusing on the free sample nature, making it 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 explicitly says 'USE THIS to decide whether the paid tools are worth paying for' and tells the agent to 'Use get_product_details for the URL you actually care about.' It also explains why you cannot choose the page, giving a clear when-to-use vs. alternative.

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 mark readOnlyHint and openWorldHint, and the description adds meaningful context by stating the service holds no database and works regardless of operator, and that non-issued attestations answer 'no'. These are non-obvious behavioral traits not present in the 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 at four sentences, but the opening 'Free, forever, no account' is marketing copy rather than functional guidance. The rest earns its place, explaining scope, external-attestation behavior, and statelessness.

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

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

For a one-parameter, read-only verification tool, the description covers what input is accepted, how foreign attestations are handled, and operational guarantees. Return format is not described, but absent an output schema this is a minor gap.

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 single parameter is fully documented in the schema (100% coverage), and the description adds no additional parameter semantics beyond reiterating that the input is an attestation. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the tool's function: given an attestation, it checks whether the signature holds and whether the service issued it. This is distinct from sibling tools like attest_page (which creates attestations) and product/comparison tools, so an agent can identify it easily.

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 tool accepts attestations from any source ('yours or one someone else gave you') and explicitly covers attestations this service did not produce, so the use case is clear. However, it does not name an alternative or state a when-not-to-use condition, leaving some routing to inference.

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 and openWorldHint, so the safety profile is already covered. The description adds genuinely useful behavioral context beyond that: $0.002 USDC per call over x402, failed calls cost nothing, a quote-first payment flow, and a 3-free-calls-per-day limit. This is rich disclosure of cost and rate-limit behavior, but it omits return shape and error semantics.

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?

Purpose is front-loaded in the first sentence, and the second paragraph is dense but every clause carries load-bearing information for an x402 tool (price, failure cost, quote flow, free tier). It is efficient without padding.

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 no output schema, the description does explain the return contents ('symbols and decimals applied') and covers chains, token limits, payment, and pricing. It is largely complete for a read-only balance tool, though it could say more about what a quote response looks like.

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 chain, tokens, address, and payment are already documented in the schema, which sets the baseline at 3. The description reinforces scope (up to 20 tokens, symbols/decimals applied) but adds no syntax or format detail 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?

States a specific verb (Check) and resource (a wallet's balances) with explicit scope: Base/Ethereum/Solana, native ETH/SOL, USDC/USDT, and listed token contracts. It is clear what the tool returns, but it never distinguishes itself from close siblings such as wallet_portfolio or check_my_balance, leaving overlap for the agent to resolve.

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 operational guidance for the payment flow ('Call without `payment` to get a quote') and notes the free tier, which implies usage but does not frame it as a when-to-use rule. There is no explicit when/when-not or naming of alternative tools for balance lookups.

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

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

Annotations only declare readOnly and openWorld, so the description's addition of the pricing model ($0.002 USDC per call over x402), the zero-cost-on-failure behavior, the quote handshake, and the free daily tier is genuinely valuable behavioral context—especially the fact that a call must be made without `payment` first to obtain a signable quote. It stops short of stating rate limits or timeout/retry behavior, keeping it from a 5.

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

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

Front-loads the core purpose and return shape, then isolates the payment mechanics in their own short paragraph. Every sentence is actionable, though the pricing tier wording is slightly dense and could be trimmed.

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 no output schema, the description carries the return-value burden and fully discharges it by describing the period structure and the alert payload. Combined with the payment/auth flow and geographic scope, an agent has everything needed to call it correctly.

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

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

Schema coverage is 80%, so the schema already documents lat, lon, address, and payment. The description reinforces the address-or-lat/lon duality but never mentions the `periods` parameter by name; it only implies a default of 7 days against a schema max of 14. Baseline 3 is appropriate given the schema does most of the work.

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

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

States a specific verb and resource ('Get the US National Weather Service forecast') narrowed to a US address or lat/lon, and enumerates exactly what comes back: 7 days of day/night periods with temperature, rain chance, wind, summary, plus active watches/warnings/advisories. No sibling tool covers weather, and this is unmistakably distinct from the geocode/airport token tooling.

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

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

Gives clear operational context: United States and territories only, and the payment flow (call without `payment` to get a quote first, 3 free calls/day). It does not name alternatives, but no sibling performs forecasting, so there is no real routing decision to spell out. The one gap is that exclusions beyond geography aren't stated.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds substantial context on top: pricing ($0.10 USDC per call), that failed calls are free, the quote-then-pay flow, weekly rebuild cadence, and the Coinbase Bazaar data source. That is exactly the extra behavioral context annotations cannot carry.

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 compact paragraphs with zero filler; the dataset contents lead, followed by the pricing/payment mechanics. Every sentence carries information an agent needs.

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

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

No output schema exists, so the description compensates by enumerating the returned fields and category totals. Combined with pricing, freshness, and source, an agent has everything needed to call it and interpret the result.

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

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

Only one parameter at 100% schema description coverage, so the schema already explains that omitting `payment` yields a quote and that the signed quote is resubmitted. The description restates this rather than adding syntax or format detail, so the baseline 3 applies.

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

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

Specific verb ('Get') plus a precisely scoped resource ('the whole x402 market as one dataset') and an enumeration of returned fields (rank, 30-day calls, revenue, paying wallets, categories, labels, category totals). The 'whole market' framing implicitly separates it from the single-entity sibling x402_seller_lookup.

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

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

Gives operational guidance on the payment flow ('call without payment to get a quote', failed calls cost nothing) but never states when to choose this over siblings like best_x402_tools or x402_seller_lookup. Usage is only implied by the 'whole market' scope.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds substantial context beyond them: the $0.02 USDC cost per call, that failures are free, the exact challenge/quote payment flow, the weekly refresh cadence, and the Coinbase Bazaar data source. This is the kind of cost and auth-flow disclosure an agent needs before invoking a paid endpoint.

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

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

The return payload is front-loaded in one dense sentence, followed by a short payment/source paragraph. No filler; every sentence carries information an agent needs to invoke or interpret the result.

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 no output schema, the description compensates by enumerating the returned fields in detail, and it spells out the paid-invocation mechanics and refresh cadence. An agent has everything needed to call it correctly and anticipate the response shape.

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

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

Schema description coverage is 100%, so the schema already documents both `host` (with example) and `payment` (omit to receive a quote). The description's payment instructions add a little workflow clarity but no syntax or format detail beyond what the schema states. Baseline 3 applies.

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

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

States a specific verb (look up) and resource (x402 seller by hostname), then enumerates exactly what comes back: rank, 30-day calls, revenue, paying wallets, per-endpoint numbers and price, categories, competitors, and anomaly labels. This is far more than a restatement of the name and lets an agent distinguish it from dataset-level siblings like x402_market_dataset.

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?

Clearly explains the two-step invocation flow: call without `payment` to get a quote, sign it, and call again. It also notes failed calls cost nothing. It does not explicitly route against alternatives such as x402_market_dataset for market-wide vs single-seller data, 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.