ScorpTech x402 Tools

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

Annotations already cover readOnly/idempotent/openWorld, and the description adds context those cannot: public-domain sourcing and, importantly, a per-call price ($0.01 USDC via x402 on Solana) plus an alternate HTTPS endpoint. The cost/access model is useful pre-invocation information; describing what is not covered by the feed (e.g., non-FAA airports' delay data) would push this higher.

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 data sources and coverage, then the parameter contract, then cost/transport. Dense and purposeful, though the pricing and URL sentence is slightly tangential to tool selection 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 does the right thing by enumerating the returned fields (delay categories plus name, city, ICAO/IATA, lat/lon). It stops short of describing result structure or volume for the nationwide overview, which is the main remaining 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?

Schema coverage is 0%, so the description must carry the load and it does: it documents the single parameter's accepted formats with examples (SFO for IATA, KSFO for ICAO) and the semantics of omitting it. Nothing further is needed for a one-param 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?

Names a specific resource (US airport delay status) and an explicit source (FAA NAS Status feed), enumerates the content types (ground delay programs, ground stops, closures, arrival/departure delays), and notes supplemental OurAirports metadata. This is clearly distinguishable from the sibling weather 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?

Explains both usage modes concretely — pass an IATA or ICAO code for one airport, or omit for a nationwide overview — so the agent knows exactly how to get each behavior. It stops short of naming alternatives (e.g., weather_global/weather_nws) for overlapping needs.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful operational context beyond that: a $0.01 USDC x402 payment per successful call and a mirror HTTPS endpoint, both critical for an agent deciding whether to invoke and how. It omits rate limits and failure/payment-refund behavior.

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

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

Three sentences, each earning its place: returns first, query modes second, commercial/logistics third. Front-loaded and zero 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?

No output schema exists, and the description compensates by listing the returned fields and links explicitly. With price, endpoint, query syntax and response fields all covered, an agent has enough to call it correctly and predict 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?

Schema coverage is 100%, so the schema already documents query, sort, limit, start and category with examples. The description restates the field syntax and category/sort options but adds no new syntax or formatting 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?

States a specific verb (Search) and resource (arXiv papers) and enumerates the exact return fields (title, authors, abstract, categories, dates, DOI/journal ref, abs + PDF links). This makes it immediately distinguishable from scholarly siblings like pubmed_search and openalex_search by source.

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?

Explains the two query modes (plain keywords vs field syntax ti:, au:, abs:, cat:, AND/OR) plus optional category filter and sort, which tells an agent how to use it. It stops short of naming alternatives such as openalex_search or pubmed_search for non-arXiv corpora, so no explicit when-not guidance.

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

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

Goes well beyond the annotations by disclosing the response shape (observations newest first, preliminary flags, footnotes, latest value, MoM/YoY), per-call limits, the BLS retrieval date/disclaimer, and the payment requirement ($0.01 USDC via x402 on Solana) plus the equivalent HTTPS endpoint. For a paid, read-only API call, the pricing and response-format disclosure is exactly the 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?

One dense, front-loaded sentence plus two short trailing facts (price, HTTPS endpoint). Every clause carries information, though the pricing/endpoint sentence could be trimmed for token efficiency.

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 heavy lifting on return contents (observations, flags, footnotes, changes) and on the payment gate. Missing only minor operational detail such as error/partial-failure behavior when some series ids are invalid.

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 schema already documents series, startYear, endYear, and latestOnly in detail. The description adds only the 25-series cap and the year-range notion, which largely restate the schema; it says nothing extra about latestOnly behavior. 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 ('Any BLS time series by id') and enumerates covered series families (CPI, payrolls, LAUS, PPI, JOLTS, ECI), which lets an agent distinguish it from generic macro tools. It stops short of naming a sibling like macro_indicators or treasury_rates for disambiguation.

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 the series-id framing and the year-range scoping, so an agent knows this is the input path for BLS data. There is no explicit when-to-use/when-not or routing to alternatives among the many economy/finance siblings (us_macro, macro_indicators, treasury_rates).

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 safety (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely non-schema context: public-domain sourcing, a per-call price of $0.01 USDC via x402 on Solana, and an equivalent HTTPS GET endpoint. What it does not disclose is failure behavior — unmatched addresses, partial matches, or ambiguity resolution — which matters for an open-world geocoder.

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 operation and input, then the return payload, then practical notes on licensing, price, and the HTTPS mirror. The long geography enumeration is dense but each item is load-bearing information the agent needs to judge fitness for a district or data-join task.

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 correctly carries the return-value burden by listing the geography fields. Combined with price, endpoint, and licensing, an agent has enough to decide and call it. The remaining gap is response shape for failures or ambiguous addresses.

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 three parameters are already documented at the field level, including the address-vs-lat/lon alternative. The description restates the two input modes and that the address needs a house number, but adds no format guidance (e.g. ZIP, state abbreviation, suite handling) or tie-breaking rule when both modes are supplied. 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+resource ('US Census Bureau geocoder') and enumerates exactly what comes back: matched address, coordinates, FIPS state/county, tract, block group/block GEOID, place, congressional and legislative districts, ZCTA, CBSA, urban area. That is far beyond a restated title. It does not, however, distinguish itself from the sibling 'geocode' tool, which is the most likely confusion point for an agent choosing between them.

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 names use cases ('district lookups, data joins and address normalisation'), which implies when to reach for it, but gives no explicit when-not guidance and never mentions the sibling 'geocode' alternative. It also omits the key calling constraint that neither address nor lat/lon is required, so the agent must supply one of the two input modes on its own.

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 a safe, idempotent, read-only, open-world operation, and the description adds material context on top: per-call pricing ($0.01 USDC via x402 on Solana), an equivalent HTTPS endpoint, and the fact that up to 100 CVEs are accepted. Cost and transport details are exactly the kind of thing 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 core capability is front-loaded in one sentence, then search modes, then pricing. It is dense but every clause carries operational value; the aerial phrasing ('Or search the catalog by...') is slightly run-on, keeping it off 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 compensates by listing what each entry returns (date added, due date, past-due flag, ransomware use, required action, CWEs). Pricing, transport, and result caps are all stated, so an agent has everything needed to call it and interpret results.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns an extra point by clarifying the mode split (cve is the lookup branch, vendor/product/days/ransomware/limit are search branches) and by surfacing the 100-item cap, which maps directly to the cve 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 names a specific verb and resource ('check ... is a CVE in CISA's KEV catalog') and enumerates the returned fields (date added, remediation due date, ransomware flag, CWEs). It also explicitly positions itself against the sibling cve_lookup (NVD), so an agent can distinguish the two without opening either 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?

Two usage modes are spelled out: point lookups by CVE (up to 100) and catalog searches by vendor, product, ?days= recency, or ransomware use, plus the complement relationship with cve_lookup. What's missing is explicit guidance on which mode wins when both are supplied, and any when-not-to-use note.

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 read-only, idempotent, open-world behavior, but the description adds useful operational context: return fields, pagination via page token, site ranking by caller location, an informational-only disclaimer, and per-call pricing. It does not describe error handling or rate limits, but it is substantially richer than the annotations alone.

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 search scope and output shape, then appends pricing and endpoint information. It is dense but every sentence serves a purpose; the main sentence is somewhat long but remains readable.

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 full burden of explaining return values and does so thoroughly, including fields, total count, page token, and ranked sites. It also discloses pricing and an alternate HTTPS endpoint, leaving little important context missing for a read-only search tool.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description adds little parameter-level detail beyond restating the filter categories already present, 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?

States a specific verb and resource: searching ClinicalTrials.gov by condition, keyword, location, sponsor, status, and phase. It is clearly distinguishable from siblings like pubmed_search or fda_adverse_events because the registry and filter scope are named.

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 context for when this tool applies by enumerating supported search dimensions and the open/closed status shortcut. It does not explicitly contrast with alternatives such as PubMed or FDA tools, so the agent must infer when not to use it.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, but the description adds genuinely useful behavioral context beyond them: the fetch is SSRF-safe, only public pages are touched, and there is a $0.03 USDC x402/Solana charge per successful call. It does not cover rate limits, failure modes, or timing, 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?

The field list is front-loaded and dense, with safety and pricing details following in short sentences. The long enumeration is justified because it doubles as the return-value description, though it is slightly list-heavy.

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 tool with no output schema, the description adequately covers what comes back (field list), safety (SSRF-safe), cost (x402) and an alternate transport. Minor gaps remain around output structure and partial-failure behavior.

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

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

With one parameter at 100% schema description coverage, the schema already explains that a URL or bare domain is accepted. The description adds nothing about accepted formats, redirect handling, or error cases, 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 names a specific resource ('Company profile from its own website') and enumerates exactly what is extracted (name, logo, socials, emails/phones, JSON-LD, OG/Twitter, RDAP basics), which implicitly distinguishes it from narrower siblings like opengraph or contact_extract. However, it never names a sibling or states an explicit boundary, 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?

Usage is only implied: the reader infers this is the right tool when they want a broad company identity snapshot from a URL. There is no statement of when not to use it, no named alternatives for sub-tasks like email-only extraction, and no prerequisites beyond the schema's 'public http(s) only'.

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

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

Beyond the annotations, the description discloses extraction sources, obfuscation handling, Cloudflare-protected pages, JSON-LD parsing, share-link ignoring, same-domain tagging, crawl depth, SSRF-safe fetching, legal considerations, pricing, and an alternate HTTPS endpoint. This is unusually rich behavioral context for an agent.

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 and every detail is relevant, but the first sentence is a long, dense list with parentheticals. It is efficient for a complex tool yet could be easier 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?

For a complex extraction tool with no output schema, the description covers sources, crawl behavior, safety, legal use, and pricing. It still does not describe the return-value shape or result structure, which would be helpful since no output schema exists.

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, crawl, and max_pages. The description adds context about following up to 3 same-site pages by default, but does not provide parameter-level meaning beyond what the schema already conveys.

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: extract public business contact details from a website. It enumerates the exact artifact types (emails, phones, social profiles, JSON-LD org data, contact-form URLs), which clearly distinguishes it from generic siblings like web_to_text or url_links_extract.

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 usage context is clear: extract public business contacts, respect GDPR/CAN-SPAM, and optionally crawl same-site contact/impressum/about pages. It does not explicitly name alternatives such as pii_detect for personal data or url_links_extract for generic link collection, so it stops short of full when-to-use/when-not-to-use 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: DST correctness, the day-of-month OR day-of-week rule and its reporting, precise rejection of invalid expressions, and a pricing/auth note ($0.01 USDC via x402 on Solana) plus an HTTPS endpoint. These are details the annotations do not convey.

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

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

Front-loads the core function, then capabilities, then validation behavior, then pricing/alternate endpoint. Dense but every clause carries 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 explains the return (explanation plus next N run times), validation failure behavior, and cost/auth model—everything an agent needs to call it correctly and interpret results.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description only restates defaults for count (5, max 20) and zone; it adds no syntax or edge-case detail for 'from' or expression aliases beyond what the schema provides, 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+resource ('Explain a standard 5-field cron expression') and specifies the outputs (plain-English explanation plus next N run times). It is clearly distinct from siblings like timezone_convert or holidays_business_days, which handle time but not cron parsing.

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 scope statements (supports lists, ranges, steps, macros; rejects invalid/never-firing expressions), but there are no explicit when-to-use/when-not conditions or named alternatives. The agent must infer that this is the cron-specific parser rather than a general time tool.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds real value beyond them: per-call pricing ($0.008 USDC via x402), the upstream dependency (crt.sh), and that results are unique and capped. However, 'capped' is not quantified and no latency, rate-limit, or upstream-failure behavior is 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?

Three sentences, front-loaded with what the tool does, followed by result shape and cost. The x402 pricing and HTTPS fallback both earn their place for an agent deciding whether to call; only the raw endpoint URL is slightly incidental.

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 one-parameter read-only tool with no output schema, the description covers mechanism, return shape ('unique hostnames, capped'), and cost. Remaining gaps are the cap value, domain formatting rules, and error/payment-failure behavior, which are moderate rather than fatal.

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

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

There is one required parameter with 0% schema description coverage, so the description must carry the burden and only partially does: 'issued under the domain' implies a bare registrable domain rather than a URL or wildcard, but format expectations, subdomain handling, and validation behavior are never stated.

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?

Names a specific verb (subdomain enumeration via Certificate Transparency), the concrete data source (crt.sh JSON API), and the return payload (unique hostnames under the domain). An agent can distinguish this from generic DNS or domain-intel siblings because the CT/crt.sh mechanism is explicit.

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

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

Usage is only implied: the tool is for finding subdomains through certificate issuance records. There is no statement of when to prefer this over siblings like dns_dump or domain_intel, nor any exclusion or precondition (e.g. only covers hosts with TLS certs). The alternate HTTPS endpoint is provided, but that is an access path, not selection guidance.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so safety is covered; the description adds genuinely new context — public NVD data source, a concrete price ($0.01 USDC per successful call via x402 on Solana), and an equivalent HTTPS endpoint. It omits rate limiting and result-count/pagination behavior, so not 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 search behavior, then returns, then cost and alternate transport — no filler sentences. It is dense and slightly overpacked with the raw URL and pricing details that could be trimmed, but every element is actionable.

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 tool with full annotations and no output schema, the description covers what is returned, where the data comes from, and the payment model. Remaining gaps — pagination, result caps, and overlap with other CVE tools — are minor but real.

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 are self-documented, so the baseline of 3 applies. The description only echoes the product/keyword and severity filter and clarifies that severity is CVSSv3-based — marginal added meaning 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 — 'Search NIST NVD CVE API 2.0 by product/keyword' — and enumerates return fields (CVE ids, scores, vectors, descriptions, reference URLs). It never names the adjacent vulnerability siblings (cisa_kev, epss_score, osv_scan), so an agent must infer differentiation, which keeps it 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?

Usage is only implied by 'by product/keyword with optional CVSSv3 severity filter' — it does not say when to prefer this over cisa_kev (known-exploited), epss_score (exploit likelihood), or osv_scan (package advisories). No explicit when-not or exclusion is present.

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 read-only, idempotent, open-world, non-destructive behavior, so the bar is lower. The description still adds real behavioral facts the annotations do not cover: the upstream resolver (Cloudflare DoH), a per-success charge of $0.005 USDC via x402 on Solana, and an equivalent HTTPS endpoint. It omits error/failure behavior and whether failed lookups are billed.

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, front-loaded with what the tool returns before the pricing and transport details. Every element — record list, resolver, price, alternate endpoint — is actionable information with no filler.

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

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

For a one-parameter, no-output-schema tool the description is nearly complete: it tells the agent what will come back (the record types) and what it will cost. The remaining gap is output shape — grouping, per-type errors, or absence of a record type — which the agent has no other source for.

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

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

There is one required parameter with 0% schema description coverage, so the description must carry the semantics. Saying records are gathered 'for a domain' gives minimal context, but it never specifies accepted format (bare hostname vs. URL vs. subdomain) or whether record types can be filtered. Partial compensation only.

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 the resource precisely (all common DNS records for a domain) and enumerates the exact record types returned (A, AAAA, NS, MX, TXT, CAA), so an agent can distinguish it from narrow siblings like mx_check or ct_subdomains. It stops short of naming those siblings explicitly, which keeps it from 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?

Usage is only implied: an agent can infer this is the tool for a full record sweep of a domain rather than a single record type. There is no explicit when-to-use/when-not and no routing to dns_propagation, mx_check, or domain_intel, which are the obvious alternatives.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the call fans out in parallel to three DoH resolvers, and it costs $0.01 USDC per successful call via x402 on Solana, with an equivalent HTTPS endpoint. It does not describe failure behavior (what happens when a resolver times out or the payment fails).

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 sentences plus a price/endpoint line, with the core capability front-loaded and the commercial detail trailing. Slightly dense but nothing repeated and nothing wasted.

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

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

No output schema exists, and the description compensates by naming the return contents (consensus, per-resolver answers, TTLs, rcodes, differences), plus cost and an alternate endpoint. Missing only failure/timeout semantics and payment-failure handling for a paid, multi-resolver call.

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

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

Schema coverage is 100% with enums and defaults already documented, so the schema does the heavy lifting. The description only restates the core semantics ('resolves one record type', three resolvers in parallel) without adding format, syntax hint, or edge-case guidance for domain IDN handling or the resolvers subset.

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 gives a specific verb and resource — resolves one record type for a domain across three named resolvers — plus the transport (DNS-over-HTTPS, parallel) and the returned consensus data. It's clear enough to call without opening the schema, but it never positions itself relative to close siblings like dns_dump or mx_check, so an agent must 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?

Usage is implied by the phrase 'DNS propagation check' and the multi-resolver scope: use it when you want cross-resolver agreement. There is no explicit when-to-use/when-not, no mention of prerequisites (e.g., only one record type per call), and no named alternatives such as dns_dump for full records or mx_check for mail config.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds genuinely non-inferable behavior: it is offline, charges $0.005 USDC per *successful* call via x402 on Solana, and is additionally reachable over HTTPS at a named endpoint. The return contract (0-100 score, letter grade, actionable fixes) is also disclosed despite there being no output schema.

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 identity, then rules, output, exclusions, and pricing in a logical order. Dense and mostly waste-free, though the long parenthetical rule list and the trailing pricing/endpoint sentence make it read as one run-on rather than clearly separated blocks.

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, no-output-schema tool, the description covers output shape, cost, transport alternatives, and scope boundaries—well beyond expectations. The remaining gap is input semantics (what exactly to pass), but otherwise 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 coverage is 0% and the single `dockerfile` parameter is undocumented, so the description carries the full burden. 'Parses stages/continuations' weakly implies raw Dockerfile text rather than a path, URL, or repo reference, but that ambiguity is never resolved, and the schema's 'required: 0' raises the question of what happens with no input—unaddressed.

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 ('Dockerfile linter') and enumerates the actual rule surface (latest tag, curl|bash, secrets in ENV/ARG, runs-as-root, chmod 777, ADD-vs-COPY, apt cache, HEALTHCHECK, multi-stage), so an agent knows exactly what class of findings to expect. It also scopes out what it will not do ('Does not build or pull images'), which no sibling covers.

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?

Clear context for when to reach for it (static analysis of a Dockerfile before building) plus an explicit exclusion: it does not build or pull images. However, it never names a complementary or alternative tool (e.g. a general format/schema validator among the siblings), so routing guidance stops at the self-contained 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?

Goes well beyond the annotations by disclosing how the lookup resolves (IANA bootstrap selection), how availability is inferred (RDAP 404), the exact fields returned for registered names, the DNS NS fallback for non-RDAP TLDs, subdomain flagging, and — critically — the paid x402/Solana billing model at $0.005 per successful call. Cost and payment requirements are exactly the kind of behavioral context 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?

Four tightly packed sentences with the core purpose and limits first, then result semantics, then fallback, then pricing and the HTTPS mirror. Every clause earns its place, though the density borders on telegraphic and the pricing/endpoint sentence could be split for readability.

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 single-parameter, no-output-schema tool, the description supplies the return-field inventory (registrar, IANA id, dates, status, nameservers), the availability signal, the TLD fallback path, and payment terms — everything an agent needs to call it and interpret the response without opening a 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 100% and the schema already specifies comma-separated input, max 20, ASCII/punycode, and the 'domain' alias. The description only restates the 20-domain cap, adding no format or edge-case detail (e.g., how invalid or duplicate entries are handled). Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

States a specific verb and resource — bulk domain availability via authoritative RDAP lookup — with the operational scope (up to 20 domains) front-loaded. It is clearly distinguishable from siblings like domain_intel, rdap_age, and dns_dump because it frames itself as a registry-authoritative availability check with per-domain result fields.

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 bulk framing and 'up to 20 domains' limit imply when this tool applies, and the RDAP/DNS-fallback note tells the agent how results are derived. However, no sibling is named (e.g., domain_intel for richer intel, rdap_age for single domain age) and there are no explicit exclusions or when-not-to-use conditions.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world, so the remaining burden is low. The description adds genuinely non-obvious behavior: a $0.01 USDC charge per successful call via x402 on Solana, plus an equivalent HTTPS endpoint — details an agent cannot infer from any structured field. It stops short of stating failure/charges behavior or expected latency.

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, both front-loaded: capability inventory first, then the operational caveats (use case, price, transport). No filler or restatement of the title, and the signal list is dense rather than padded.

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 enumerates what comes back (registration dates, record types, cert issuer/expiry/SANs/trust, subdomains, risk flags), which is what an agent needs to decide whether one call suffices. The cost model is disclosed, but edge behavior (invalid domain, upstream failure, whether a failed call is billed) is not.

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?

Single parameter with 100% schema description coverage ('Registrable domain, e.g. example.com'), so the schema carries the load and the baseline is met. The description adds no input detail and leaves one real ambiguity unaddressed — whether a subdomain can be passed given that CT subdomain enumeration is part of the payload.

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 ('One-call domain due-diligence') and enumerates exactly which signals are combined: RDAP age/expiry/registrar, DNS record types, live TLS cert, CT subdomains, and risk flags. This clearly positions it as an aggregator distinct from narrow siblings like rdap_age, dns_dump, ssl_cert_info, and ct_subdomains.

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 explicit use case: 'phishing/scam triage of links before an agent visits or pays them,' which tells the agent the moment to reach for it. It does not name when to prefer the cheaper single-signal siblings (rdap_age, ct_subdomains, phishing_score) instead, so the alternative-selection guidance is implied by 'one-call' 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 cover the read-only/idempotent safety profile, and the description adds context they cannot: a per-call cost of $0.01 USDC via x402 on Solana, charged only on successful calls, plus an equivalent HTTPS endpoint. Cost and payment rail are exactly the kind of operational behavior an agent must know 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?

Purpose and filter capability are front-loaded in the first sentence, followed by return fields, pricing, and the alternate endpoint. High information density 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 13-parameter, no-output-schema tool, the description compensates by naming the returned fields (magnitude, place, time, coordinates, depth, tsunami flag, PAGER, felt reports, links) and disclosing cost/transport. Nothing material 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 the baseline is 3, but the description adds value the flat 13-param schema doesn't: it groups the params into two coherent spatial modes (box vs circle) and two time modes (days vs start/end), telling the agent these are alternatives rather than independent inputs. It also previews which fields are returned without a formal output 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+resource ('Recent earthquakes from the USGS') with an explicit and unique data source, and enumerates the supported filter axes (bbox, circle+radius, magnitude, time window). No sibling tool covers seismic data, so the agent can identify it instantly.

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 the two spatial query modes (bounding box vs center point + radius) and the two time-window modes (last N days vs start/end dates), which is real selection guidance. It stops short of explicit 'use X when Y' exclusions, but there are no competing earthquake siblings to disambiguate against.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive; the description adds genuinely new behavioral facts: cost of $0.005 USDC per successful call via x402 on Solana, and that the same tool is reachable over HTTPS at a specific URL. It also indicates the output is a scored result with actionable issues. No auth/rate-limit notes beyond the payment model, and no failure/refund 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?

Dense but front-loaded: capability list first, use case second, pricing/endpoint last. Every clause carries information, though the record-type enumeration is packed into one long sentence.

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 must convey what comes back — it does so by listing the record types inspected and stating results are 'scored with actionable issues'. It stops short of describing the response shape (score range, per-check structure), but is sufficient to select and call the tool.

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

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

Single required parameter with 100% schema description coverage ('Domain name, e.g. example.com'), so the schema carries the semantics. The description does not clarify edge cases such as subdomains, IDN, or whether bare domains without scheme are accepted.

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?

Starts with a specific verb+resource ('Email authentication & deliverability posture for a domain') and enumerates the concrete checks (SPF qualifier/lookup count/duplicates, DMARC policy/rua/pct, DKIM selectors, MTA-STS, TLS-RPT, BIMI, MX). This makes it distinguishable from plain MX/DNS tools, though it never names a sibling 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?

'Useful for spoofing-risk and vendor checks' hints at context but gives no explicit when-to-use versus email_validate, mx_check, dns_dump, or phishing_score. The agent must infer that this is the multi-record, scored posture check rather than a single-record validator.

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 (readOnly, idempotent, non-destructive, open-world), but the description adds useful behavioral detail beyond them: no email is sent, MX/A lookup is null-MX aware, disposable-domain coverage is roughly 10k domains, typo correction is included, and pricing is $0.005 USDC per successful call via x402 on Solana. It does not cover rate limits or failure-charging semantics, so it falls 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?

The definition is front-loaded with the core purpose and immediately follows with the checks performed, then pricing and the HTTPS alternative. Every clause 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?

Given that there is no output schema, the description does a good job listing the checks and the overall verdict. It is nearly complete for calling the tool, but it does not describe the shape of the verdict or how the individual flags are returned.

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 parameters are already well documented in the schema. The description mentions MX/A lookup and the overall check suite, but it does not add parameter-specific semantics 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?

The description gives a specific verb and resource (validate an email address) and enumerates the exact checks performed, including syntax, MX/A lookup, disposable-domain detection, role/free-provider flags, typo suggestion, and verdict. This scope distinguishes it from narrower sibling tools like mx_check and email_auth by making clear it is a comprehensive validator.

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 phrase 'without sending mail' gives implicit usage context, and the checks listed imply when the tool is appropriate. However, it does not explicitly say when to use this instead of siblings such as mx_check or email_auth, nor does it state exclusions or prerequisites.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond that: public RPC usage, a $0.005 USDC per successful call x402 payment model on Solana, and an equivalent HTTPS endpoint. It does not clarify failure charging or rate limits.

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: resolution behavior comes first, followed by read-only access, pricing, and an HTTPS alternative. Every sentence carries useful information for an agent deciding whether and how to call the tool.

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 three-parameter resolver with no output schema, the description covers the main return semantics: an address plus optional text records on forward lookup, or a forward-verified primary name on reverse lookup. It also covers payment and transport, but does not address parameter conflict or detailed output 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 input schema already documents name, texts, and address. The description reinforces the forward/reverse distinction and text-record examples, but adds no syntax details or guidance on what happens if both name and address are supplied.

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, 'Resolve', and clearly covers both forward ENS-to-address resolution and reverse address-to-primary-name resolution, including optional text records. An agent can distinguish both modes without opening the 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?

The description clearly explains the two usage modes and the schema notes that address should be used instead of name for reverse lookup. It does not explicitly compare against sibling tools such as evm_read or domain_intel, so there are no named alternatives 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new operational context: a $0.005 USDC x402/Solana cost per successful call and an equivalent HTTPS endpoint. Rate limits and failure/refund behavior on unsuccessful calls are not stated, keeping this 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 decision-relevant question, then the return payload, then matching/batch mechanics, then pricing/endpoint. Dense but every clause carries information; the enumerated return fields make it long, though none are clearly 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?

With no output schema, the description must enumerate return values, and it does: status taxonomy, release, support/EOL dates, days until EOL, LTS flag, latest patch and upgrade recommendation. Combined with pricing and endpoint info, an agent has everything needed to call 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?

Schema coverage is 100%, so the schema already documents product, version and items. The description still adds value by clarifying the batch alternative (comma list, max 10), the fuzzy-matching fallback, and that omitting version returns all current cycles.

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?

Opens with a specific question — 'Is this software version still supported?' — and names the resource and data source (endoflife.date, 400+ products). An agent can immediately distinguish this from sibling tools like package_risk or osv_scan, which cover vulnerability risk rather than lifecycle support.

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 the use case (checking support status), the batch mode limit (up to 10 product@version items), and that fuzzy matching with suggestions is available when the product name is imprecise. It does not explicitly say when to prefer this over package_risk or osv_scan, so a 4 rather than 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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuinely non-structured context: a per-call price ($0.01 USDC via x402 on Solana), the batch cap of 100 CVEs, and the fact that historical dates are supported. It does not cover error behaviour for invalid or unknown CVE ids, 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?

One dense paragraph, front-loaded with what the tool returns before sibling routing, pricing and the HTTPS mirror. Every sentence carries information, though the payment and endpoint details could be split for faster scanning.

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 naming the returned fields (probability, percentile rank, band) and the model-run semantics. Combined with annotations and a fully documented two-parameter schema, 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?

Schema coverage is 100%, so production and error semantics for both parameters are already documented in the schema. The description restates the 100-CVE cap and the latest-vs-historical date choice but adds no syntax or format detail beyond the schema, 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?

States a specific resource (FIRST EPSS exploit-prediction scores), a concrete scope (up to 100 CVEs) and what the values mean (probability of exploitation in next 30 days, percentile rank, band). It names the sibling tools it complements (cve_lookup, cisa_kev), so an agent can place it against alternatives 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?

It gives clear context — 'Complements /v1/cve-lookup and /v1/cisa-kev for vulnerability prioritisation' — which tells the agent when this tool fits into a workflow. It does not state exclusions or say what to use instead when a single-CVE lookup is all that's needed, so it stops short of full when/when-not guidance.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the per-call price ($0.01 USDC via x402 on Solana), the live external dependency on VIES, and the fact that trader name/address are only returned where the member state discloses them. The GR→EL and XI→Northern Ireland normalization rules are behavioral details an agent cannot infer from structured fields.

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 dense sentences, front-loaded with the core purpose before edge-case format rules, pricing, and the alternate endpoint. Every clause (VIES, input forms, country mapping, price, HTTPS URL) carries information an agent would otherwise lack.

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 still tells the agent what comes back (validity flag plus optional trader name/address) and flags the partial-disclosure caveat. Pricing, external dependency, and normalization rules cover the remaining gaps for a 2-parameter read-only lookup.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by documenting the country-prefix mapping conventions (GR mapped to EL, XI meaning Northern Ireland) that the schema does not state. It reinforces the required prefix-with-optional-country pattern but adds little beyond that example.

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 ('Validate an EU VAT number') plus the authoritative source (European Commission VIES) and the return payload (valid/invalid, trader name and address). An agent can distinguish this from siblings like iban_validate or validate_batch without opening a 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?

Explains accepted input shapes ('IE6388047V style input or ?country= + number') and offers a fallback access path over HTTPS, giving clear context for invocation. It stops short of explicitly naming when to prefer a sibling (e.g. batch validation) or when not to use it.

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 read-only/idempotent/destructive-free, and the description still adds non-obvious behavior: it flags max-uint unlimited approvals, states it performs no log scan (so historical approval events are out of scope), defaults to verified on-chain spenders, and discloses the $0.005 USDC per-successful-call x402 charge plus an HTTPS fallback 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?

Dense but front-loaded: capability first, then limits, flags, pricing, and alternate transport. A few elements (the raw URL, parenthetical verification note) are reference detail rather than decision-relevant, but nothing is wasted enough to hurt.

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, and the description compensates by stating what is reported (ERC-20 allowances, setApprovalForAll, unlimited-approval flags). The remaining gap is the invocation surface — the owner address format and whether the token/spender sets are configurable — which an agent needs 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 0% and the single required parameter is undocumented. The description mentions 'owner' and references token/spender dimensions, but never says owner is an EVM address (EOA vs contract) or gives a format example, and it leaves ambiguity about whether tokens/spenders are configurable since only owner is 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?

States a precise verb+resource: an ERC-20 allowance matrix for an owner across tokens × spenders, plus ERC-721/1155 setApprovalForAll. This is clearly separable from siblings like evm_balance, evm_read, and evm_token_transfers (which the 'no log scan' note implicitly contrasts).

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 scope context (10×10 matrix, default stables/WETH × known spenders, no log scan) but never says explicitly when to pick this over evm_read or evm_token_transfers. Usage is implied by 'allowance matrix' rather than routed.

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 read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new operational facts: public RPC dependency, a per-successful-call price of $0.005 USDC via x402 on Solana, and an equivalent HTTPS endpoint. It does not describe failure/refund behavior when a call fails, which is the one notable gap 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?

Four tight sentences, front-loaded with what is returned and where, followed by the token-count limit, the read-only note, and pricing. The bare URL at the end is slightly tacked on but still earns its place as an alternate access path.

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 return-shape duty, and it does say balances are returned per native ETH and per ERC-20 token across the chosen chain. It stops short of describing result structure or how zero balances appear in the response, which would matter since include_zero defaults to true.

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. The description still adds information the schema lacks: the cap of 20 token contracts and which tokens constitute the 'major' default set (USDC, USDT, WETH, DAI/ARB), which materially affects what an agent should pass.

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?

Names the specific verb+resource (native ETH and ERC-20 token balances for an address) and constrains scope to three named chains. It is clearly distinguishable from evm_token_transfers, evm_read and wallet_risk_basic without opening a 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?

Gives real usage context: omit tokens for the default set, pass up to 20 contracts, chain defaults to eth. But it never names an alternative sibling (evm_read, evm_token_transfers, sol_balance) or states when a caller should prefer those instead, so the routing guidance is implied 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, idempotentHint, destructiveHint=false and openWorldHint, and the description adds material context beyond them: static-analysis (not simulation) semantics, the scope of the selector scan (145 signatures), the 0-100 risk score output, the $0.01 USDC per-successful-call pricing model via x402 on Solana, and a same-tool HTTPS fallback. That is exactly the kind of cost/auth/limitation 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?

Front-loads purpose and capabilities, then closes with the two most decision-relevant facts (pricing and static-analysis caveat). The first sentence is a very long clause chain, but nearly every clause carries distinct information an agent needs; there is little pure 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 the work of enumerating return fields (metadata, proxy detection, standards, selector-derived capabilities, risk score), and it discloses cost and transport. Remaining gaps are error behavior and rate limits, which are minor for a read-only, idempotent lookup.

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% with two parameters, so the description must compensate. It effectively enumerates the accepted `chain` values (Ethereum, Base, Arbitrum, OP Mainnet, Polygon, BNB Chain), but says nothing about the `address` format, required casing/checksum, or whether non-contract addresses error — leaving the required parameter undocumented in both schema and description.

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

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

States a specific verb (introspection of an EVM contract) and enumerates exactly what is returned: bytecode size/hash, proxy patterns, ERC standards, token metadata, owner()/paused(), selector scan, and risk score. It also names the chains covered, so an agent can distinguish it from sibling read tools like evm_read or evm_selector_decode without opening any 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?

Includes an explicit exclusion — "Static analysis only — not a honeypot simulation" — plus a read-only statement and an alternate HTTPS endpoint, giving clear context for when this tool fits. It does not name sibling alternatives (e.g. wallet_risk_basic for wallet-level risk or evm_selector_decode for a bare selector lookup), so routing between similar tools is still partly inferred.

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, idempotentHint, and openWorldHint, but the description adds critical behavioral context beyond them: pricing ($0.005 USDC per successful call), payment rail (x402 on Solana), and an HTTPS alternative endpoint. These details materially affect invocation and cost decisions.

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 and then packs useful metric, pricing, and endpoint details into a compact two-sentence block. It is dense but every clause contributes information, with only minor room for trimming.

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?

Because there is no output schema, the description appropriately enumerates the returned gas metrics (head block age, base fee, percentiles, maxFeePerGas tiers, transfer costs). The main remaining gap is the optional 'chains' parameter semantics, which prevents a perfect completeness score.

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

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

There is one optional 'chains' parameter with 0% schema description coverage. The description lists supported chain names (Ethereum, Base, Arbitrum, OP Mainnet, Polygon, BNB Chain), but it does not explain the parameter format, casing, delimiter, or default behavior when omitted, leaving a key semantic gap for a low-coverage 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 opens with a specific verb+resource: 'Live gas tracker' across named chains. It clearly distinguishes gas tracking from siblings like evm_balance, evm_tx_info, and evm_read by enumerating the exact gas metrics it provides.

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 'Live gas tracker' and the listed metrics, so an agent can infer it is for gas estimation across supported chains. However, there is no explicit when-to-use/when-not guidance or comparison to any sibling tool such as evm_read or evm_tx_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 cover readOnly/idempotent/non-destructive, and the description adds real substance: ABI arg encoding, decode coverage across types, revert-reason surfacing, a per-call price of $0.005 USDC via x402, and an HTTPS alternative endpoint. Gaps remain: 'six chains' are never named, and the schema offers no chain parameter, so chain selection is unexplained.

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 operation and an inline example, followed by behavior, chains, cost, and an alternate transport in roughly descending priority. Dense but every clause carries information; slightly heavy with the pricing/HTTP tail.

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, and the description does describe decoding and revert handling, which covers most of the return-value story. But for a tool whose core mechanic is encoding function arguments, it never explains how arguments are supplied, nor which six chains are supported — both are things an agent needs 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 0%, so the description must carry the load. It does well on `signature` (human-readable form, human-readable vs. Solidity-style examples), but `contract` is never explained, the fact that `signature` is optional while `contract` is required is undiscussed, and the description promises to 'ABI-encode args' while no args parameter exists in the schema — a real semantic 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: 'Read-only eth_call of any view/pure function,' with two concrete signature examples that make the input form unambiguous. It is clearly the generic escape hatch among the evm_* siblings, but it never explicitly contrasts itself with evm_balance or evm_allowance, leaving that inference to the agent.

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 'any view/pure function' and reinforced by 'No state change,' so an agent can tell this is for arbitrary read calls. However, there is no explicit guidance on when to prefer the specialized siblings (evm_balance, evm_allowance, evm_contract_info) over this generic one, and no stated prerequisites.

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 read-only, idempotent, non-destructive, open-world behavior, and the description adds substantial context beyond that: external lookup in 4byte.directory, built-in signature table, Keccak-256 re-hashing, candidate ranking, ABI decoding details, and pricing. There is no contradiction with the annotations.

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

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

The description is front-loaded and dense with useful information, but it is essentially one long multi-clause sentence with a lengthy type enumeration. It earns most of its space, yet could be structured more cleanly.

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 no-output-schema, fully optional-parameter tool, the description gives strong behavioral context and explains candidate ranking and decoding. It omits the expected response shape and does not state that at least one of selector, topic, calldata, or signature must be supplied, which is a meaningful 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining that calldata is ABI-decoded against candidates, signatures are hashed into selectors/topics, and candidates are ranked by clean decoding, though it does not clarify the required combination of optional parameters.

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: decoding EVM function selectors, calldata, and event topics, plus computing selectors/topics from signatures. It clearly distinguishes this selector-decoding utility from general EVM read/info tools in the sibling list.

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 a clear context for use by naming the input modes (selector lookup, topic lookup, calldata decoding, signature hashing). However, it does not explicitly state when to prefer this over adjacent tools such as evm_read or evm_contract_info, nor does it state exclusions.

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

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

Annotations already declare read-only/non-destructive, yet the description adds genuinely new behavioral facts: an adaptive eth_getLogs window that auto-shrinks on provider range caps, the decoded return fields including mint/burn tags, and a payment requirement ($0.01 USDC per successful call via x402 on Solana). Disclosing cost and the HTTPS alternative endpoint is exactly the kind of context 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?

Five compact sentences with the core purpose front-loaded and operational/pricing details trailing, which is the right ordering. Slightly dense in the middle (eth_getLogs mechanics) but no sentence is wasted.

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

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

With no output schema, the description helpfully enumerates return fields (from/to/value or tokenId, approx age, mint/burn tags), and it discloses cost and chain coverage. The only real gap is the mismatch between mentioned wallet/direction filters and the actual one-parameter 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 0% for the single 'token' parameter, so the description must carry the load; it does clarify that 'token' means a token contract address. However, it advertises '(optionally filtered to one wallet, in/out/both)' when the schema exposes only 'token', creating ambiguity about parameters that do not exist in the input 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 ('Latest ERC-20 or ERC-721 Transfer events for a token contract') plus scope (six EVM chains), which is far more precise than the title alone. It does not explicitly differentiate itself from nearby siblings like evm_read, evm_tx_info, or nft_metadata, so it stops 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?

The word 'Latest' and the event-type scoping imply when this tool applies, but there is no explicit 'use this when... instead of X' guidance and no stated exclusions or prerequisites. An agent can infer usage but must guess against alternatives such as evm_tx_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 establish readOnly/idempotent/non-destructive, and the description adds genuinely new operational context: $0.005 USDC per successful call via x402 on Solana, plus an equivalent HTTPS endpoint. It does not cover failure behavior (unknown hash, reorged/unsupported chain), which keeps it below 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 action and payload list, then moves to the operational facts (read-only, price, HTTPS alternative). The returned-field enumeration is a long run-on list but every element is informative; no filler sentences.

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 burden of describing return values, and it does so thoroughly by enumerating the decoded fields. Missing pieces are error/edge-case behavior and pagination/response shape, which for a single-transaction lookup are minor.

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% — both 'hash' (0x-prefixed 32-byte) and 'chain' (enum with default 'eth') are fully documented in the schema. The description only restates the chain names in prose and adds no syntax, format, or default guidance beyond what the schema already provides, 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?

Specific verb + resource ('Decode an EVM transaction') with the supported chains (Ethereum, Base, Arbitrum) and a full enumeration of what is returned (status, gas, fee, selector, ERC-20 Transfer/Approval events). It does not explicitly distinguish itself from nearby siblings such as evm_selector_decode, evm_token_transfers, or evm_read, so it stops 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?

The description establishes the operating context (read-only, public RPC, paid per call) but never states when to pick this over evm_token_transfers (for event logs only) or evm_read (for arbitrary contract reads). Usage is implied by the resource type rather than guided.

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 read-only, idempotent, open-world, non-destructive behavior, so safety is covered. The description adds genuinely new context the agent cannot get elsewhere: a per-call price of $0.01 USDC via x402 on Solana and a mirror HTTPS endpoint, plus the default of compact (non-full) records. It still leaves some behavior unstated, such as paging limits of the raw search or error handling.

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 front-loads the datasets and filtering capabilities, then closes with the pricing and alternate endpoint in one line. It is dense but virtually every clause carries information; the only slight drag is the URL string, which is necessary operational 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?

For a 13-parameter, fully documented, read-only query tool with no output schema, the description covers enough: which datasets, what can be filtered, compact versus full records, counts versus listings, and the cost model. An agent could invoke it correctly, though the absence of an output schema means the response shape (and paging behavior past the 25,000 skip cap) is only loosely implied.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning on top of the schema by tying parameters together: it explains that 'count' produces aggregations on any field, with the concrete example of top reactions for a drug, and that 'search' can be used as a raw openFDA fallback. It also frames 'full' versus compact reports as an output-shape choice.

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 the exact resource (openFDA adverse-event reports) and enumerates the three underlying datasets it spans: FAERS for drugs, MAUDE for devices, CAERS for food/supplements. That level of specificity makes it distinguishable from neighboring tools like fda_device, fda_recalls, and openfda_drug.

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 lists the filtering axes (drug, product, reaction, dates, raw search) and the two output modes (compact reports or counts), which implies when the tool is useful. However, it never states when to reach for this instead of fda_device, fda_recalls, or openfda_drug, and there are no exclusions or prerequisites beyond the price note.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower. The description still adds material context beyond annotations: a per-call price ($0.01 USDC via x402 on Solana), an alternate HTTPS endpoint, and the 'GMDN removed' data caveat. It does not describe pagination or result shape.

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?

Dense, front-loaded, and waste-free: resource, datasets, query surfaces, caveat, and pricing in a short block. The payment/endpoint note is separated cleanly rather than buried mid-sentence.

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 13-parameter read-only search tool with full schema coverage and rich annotations, the description covers scope, datasets, query surfaces, and payment mechanics. The main remaining gap is any hint about result shape or pagination interaction between skip/limit, which no output schema documents.

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

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

Schema coverage is 100% with per-param descriptions and enums for dataset and deviceClass, so the baseline is 3. The description reinforces count semantics ('count by any field') and the searchable field set, but adds little that the schema does not already state.

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 resource (FDA device records) and enumerates the concrete datasets covered: 510(k) clearances, PMA approvals, classification, and GUDID/UDI. The scope implicitly separates it from siblings like fda_recalls and fda_adverse_events, but no sibling is named 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?

It gives the query surfaces (name, product code, applicant, number, raw search, count) and notes the default dataset is 510k, which is useful context. However, it never states when to prefer this over fda_recalls or fda_adverse_events, nor any prerequisites 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?

Annotations already carry the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description adds genuinely new behavior: a $0.01 USDC per-call cost via x402 on Solana, the HTTPS fallback endpoint, and default ordering. It does not state pagination limits in prose (they are in schema), which keeps 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?

Dense but front-loaded: what it is, what it returns, how to filter, then cost and alternate endpoint. Every clause carries information; the parenthetical field list is slightly packed 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 15-parameter, fully-documented, read-only search tool with no output schema, the description covers source scope, defaults, and cost — enough for an agent to call it correctly. Return shape is unspecified but the field list partially compensates.

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 all 15 parameters including enum values and range hints. The description reinforces a few semantics (count by any field, newest-first default sort, source=recall device-only) but adds little 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?

The description opens with a specific resource and source (FDA recalls via openFDA enforcement reports for drug/device/food) plus the device recall database, and lists the fields returned. It is clearly distinguishable from fda_adverse_events, though it never names a sibling directly (fda_device overlap on device recalls is only implied via source=recall).

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 enumerates the filtering capabilities (firm, product, class, status, state, dates) and defaults (source enforcement, category drug, newest first), which implies how to drive the tool. But there is no explicit when-to-use vs when-not guidance, and no routing to siblings like fda_device or fda_adverse_events.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds real value beyond that: the $0.01 USDC per-successful-call pricing via x402 on Solana, and the equivalent HTTPS endpoint, which are material to an agent deciding whether and how to invoke it. It does not mention rate limits or failure/refund behavior for paid 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 sentences, front-loaded with the search scope, then the return payload, then the payment/transport detail. No filler; each sentence carries distinct information. Slightly dense but well ordered.

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 well by enumerating the returned fields (document number, title, type, agencies, action, abstract, citation, effective/comment-close dates, EO number, docket ids, RINs, HTML/PDF links). Combined with full schema coverage for inputs, an agent has enough to call it correctly; only refund/failure semantics for the paid call are 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 description coverage is 100%, so all nine parameters are already documented with types, formats, and defaults. The description's parameter-related content (agency names, short names, slugs, type filters, date ranges) largely restates what the schema already says. 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 and resource ("Search the U.S. Federal Register") and enumerates the document classes covered (rules, proposed rules, notices, presidential documents, executive orders) plus the filterable dimensions. This clearly separates it from siblings like sec_edgar_search or usaspending_awards, which target different corpora.

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 tells the agent what dimensions can be filtered and gives a concrete example of agency shorthand ("EPA"), so a caller knows how to frame a query. It stops short of stating when to prefer a sibling tool (e.g., SEC filings vs. Federal Register) or what happens if zero results match, so no explicit exclusions or alternatives.

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

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

Annotations already cover read-only/idempotent/open-world, and the description adds genuinely new behavior: SSRF-safe fetching, a probe-then-parse cascade, the exact output item fields, and — critically — a per-success price of $0.005 USDC via x402 on Solana plus an alternate HTTPS endpoint. Cost and payment mechanics are absent from annotations and schema, so this is high-value 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 with the core action and mechanism, then tapers into format support, output shape, safety, and pricing. It is a single dense paragraph with little waste, though the trailing endpoint URL and price sentence make it longer than strictly necessary for selection.

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 naming the returned fields (title, link, ISO published date, author, summary, categories, enclosure). Combined with the disclosed cost model, SSRF guarantee, and supported feed formats, an agent has everything needed 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 100%, so the baseline is 3. The description reinforces that a feed URL is acceptable for the url param and explains the probe fallback in prose, but it adds no syntax or edge-case detail (e.g. what happens when probing fails, or how items=0 interacts with the probe flag) 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 ('find a website's RSS/Atom/JSON feeds and read the latest items') and enumerates the mechanisms (link rel=alternate parsing, path probing, RSS 2.0/RDF/Atom/JSON Feed parsing). This clearly separates it from siblings like http_probe, robots_sitemap, or opengraph, which fetch pages but do not resolve feeds.

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 context: use it against a site URL for discovery, or pass a feed URL directly to parse it, and notes the fallback probing path. It does not say when NOT to use it or name alternatives (e.g. robots_sitemap for sitemap discovery, url_links_extract for generic link extraction), so it stops short of full routing guidance.

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

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

The description adds substantial context beyond annotations: Open Food Facts provenance and ODbL license, community-data caveat about checking packaging for allergens, GTIN check-digit validation, and paid x402/Solana pricing per successful call. This is exactly the kind of operational and trust context an agent needs before invoking the 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 front-loaded with the core purpose, then packs identifiers, source, returned fields, caveats, and pricing into a single dense paragraph. It earns most of its length, but the long field list makes it less scannable than it could be.

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 listing the returned data categories in detail, including nutrients, scores, allergens, additives, and image URL. It also covers source, licensing, data reliability, and payment, so an agent has enough context to call it correctly.

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

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

Schema coverage is 100%, so parameter documentation is already strong. The description still adds useful semantics by naming accepted barcode standards and noting check-digit validation, though it does not add meaning for the lang parameter beyond the schema.

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

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

The description states a specific verb and resource: retrieving food product facts by barcode from Open Food Facts. It clearly establishes the supported identifier formats and data domain, though it does not explicitly differentiate itself from any sibling 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?

Usage is implied by the barcode lookup purpose and supported formats, and the HTTPS endpoint is offered as an alternate access method. However, there is no explicit when-to-use guidance, prerequisites, or selection criteria versus alternatives.

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

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

Adds substantial behavior beyond the readOnly/idempotent/non-destructive annotations: 256 KB payload limit, line-numbered errors on malformed input, safe-YAML-subset restriction (no anchors/tags), formula-injection guard, and per-call pricing/payment requirements. Missing only a statement of what the returned value looks like, which matters since there is no output schema.

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 and format list are front-loaded and every clause carries information; the options digest is dense but scannable. The pricing/HTTPS-endpoint sentence is operational rather than descriptive but still earns its place for an agent deciding whether it can 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?

Covers input constraints, supported formats, edge-case semantics, error behavior, and cost — enough to invoke correctly. The notable gap is return-value shape (string vs object, how nested/flattened output is packaged), which the absent output schema leaves 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 100%, so the baseline is 3, but the description goes further by explaining the semantics of options: flattening produces dotted CSV columns, XML attributes surface as @keys, repeated elements become arrays, and CSV header/delimiter detection applies. That is meaningful behavior the schema only names.

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?

Opens with a specific verb and resource ("Convert data") plus the full set of target formats and auto-detection of the source. An agent can distinguish this from siblings like json_repair or schema_validate without opening the 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 is implied by 'in one call (auto-detects the input format)' and the mention of what the tool handles, but there is no explicit when-to-use/when-not guidance and no routing away from near-neighbors such as json_repair or html_to_markdown.

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 read-only, idempotent, non-destructive. The description adds the two things annotations cannot: a per-call cost ($0.01 USDC via x402 on Solana) and an alternate HTTPS endpoint, which materially changes how an agent should invoke and budget for 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?

The payload inventory and lookup keys lead, with payment and endpoint details trailing as short sentences. It is dense but every clause carries content; the long field enumeration is the only mildly bloated part.

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 enumerating return fields (CUSIP, ISIN, LEI, share counts, % of net assets, mix breakdowns) so the agent can judge whether the call answers its question. Only the nuance of 'latest' filing staleness is left unstated.

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 properties are already documented with their alias list and the 1-100 range, so the description's main addition is illustrative ticker values (VOO, QQQ, BND). That is a mild aid, not new semantic information — 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 resource (mutual fund / ETF portfolio) and an authoritative source (latest public SEC Form N-PORT), plus the exact payload (holdings, mix, concentration, net assets, returns). This clearly separates it from SEC-adjacent siblings like sec_13f (institutional positions) and sec_financials.

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 names the lookup keys that select a fund (ticker, series id, class id) with worked examples, but never says when to prefer it over sec_13f, ticker_resolver or sec_edgar_search, and gives no exclusions. Usage is implied rather than routed.

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 read-only/idempotent/open-world, so the description correctly spends its words elsewhere: primary vs fallback data source, 150+ currency coverage, an explicit $0.005 USDC per successful call pricing model with x402/Solana payment, and an HTTPS endpoint. The only missing piece is whether failures are billed and what the response shape looks like.

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 what the tool returns and its sources; pricing and endpoint follow. It is dense but each clause carries information, though the parenthetical source list and payment details make the single sentence feel crowded.

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 should say something about return shape; it implies a rate (and converted amount when `amount` is supplied) but never states it. Everything else an agent needs to call it correctly — auth/payment model, data coverage, date limits — is present.

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 parameters are fully documented structurally; the description adds only the framing of 'optional amount conversion' and 'historical date'. Baseline 3 is appropriate since it contributes no format or constraint 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?

Names a specific resource (fiat currency exchange rate) with concrete verb-adjacent behavior: optional amount conversion and historical lookup. Source providers (ECB/Frankfurter, ExchangeRate-API) are stated, which clearly separates it from siblings like ticker_resolver or treasury_rates.

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?

Implies usage through mentions of historical dates and conversion, but never states when to prefer this over treasury_rates, macro_indicators, or ticker_resolver, and gives no exclusions (e.g. crypto pairs). The HTTPS/paid-access note is access guidance, not selection guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's value is the extra disclosure: per-call pricing ($0.005 USDC via x402/Solana), which provider serves which geography, and an equivalent HTTPS endpoint. It omits rate limits and failure/ambiguity behavior, so it is strong but not exhaustive.

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 two modes, followed by short factual sentences on read-only, price, and endpoint. Dense but efficient; the first sentence is long and packs provider selection into a parenthetical, which is a minor readability cost.

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 still indicates what comes back in each direction (lat/lon forward; address plus US county/tract for reverse). Pricing and endpoint are covered, but error handling, multi-result behavior (implied by limit default 3), and ambiguity fallback are not described.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the provider enum values are explained in terms of coverage geography (census = US street addresses, photon = worldwide) rather than just repeated as a name list. It does not clarify lang/limit semantics 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 with both directions spelled out (forward geocoding address/place name to lat/lon, reverse geocoding lat/lon to an address) plus the backing providers. An agent can distinguish it from nearby siblings like census_geographies or timezone_convert without opening the 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?

The description makes the forward-vs-reverse selection explicit and explains the provider routing condition (Census for US street addresses, Photon worldwide). It does not name a sibling alternative or state when not to use it, so it falls short of the top 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?

Goes well beyond the annotations by disclosing unauthenticated rate limits, a per-call price of $0.008 USDC via x402 on Solana charged per successful call, and an alternative HTTPS endpoint. It also states the heuristic nature of the healthScore and that notes are included, giving the agent important operational context beyond readOnly/openWorld 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?

The description is front-loaded with the core purpose, then supplies operational details in a single dense but efficient narrative. Every sentence carries useful information: metrics returned, rate limits, pricing, and the alternate endpoint; 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?

Without an output schema, the description compensates by listing the returned metrics explicitly (stars/forks/issues, license, languages, last push age, latest release & commit, healthScore, notes). It also covers the critical rate-limit, payment, and endpoint behavior, making it complete for a one-parameter read-only summary tool.

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

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

The input schema has 100% description coverage for the single 'repo' parameter ('owner/repo or github.com URL'), and the tool description adds no additional syntax or format guidance beyond that. With schema coverage this high, 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 and resource: 'GitHub repository health summary via public API', and enumerates the included metrics (stars/forks/issues, license, languages, last push age, latest release & commit, healthScore). This clearly identifies the operation, though it does not explicitly distinguish it from the sibling 'repo_posture' 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?

Usage is implied by the description of what the tool summarizes, but there is no explicit 'use this when' guidance, no exclusions, and no named alternative such as 'repo_posture' or 'github_trending'. It mentions 'via public API' and rate limits, which provide context but not selection guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, yet the description still adds material context an agent could not infer: results are cached 30 minutes (staleness expectation), the data comes from the public REST API rather than HTML scraping (reliability/structure), and each successful call costs $0.01 USDC via x402 on Solana (a spend decision the agent must make before calling). It also provides an equivalent HTTPS endpoint for non-MCP callers.

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 and scope in the first clause, then behavior, then pricing/endpoint details. It is dense and long-ish, but every clause carries information an agent needs (cost, caching, auth model, return shape). Minor cost: the sentence runs long before reaching the price, which arguably deserves earlier emphasis.

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 compensates by enumerating the returned fields (full_name, URL, description, language, topics, stars, forks, issues, licence, dates, owner type, velocity). Combined with the disclosed payment model, cache TTL, and data source, an agent has everything needed to decide whether to call and what it will get back.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that the 'since' window constrains repo *creation* date (not push date) and that results are ranked by stars with language/topic/min-stars acting as conjunctive filters. It also enumerates the returned fields including the derived stars-per-day velocity, which is not derivable from the params alone.

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

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

The opening sentence gives a specific verb+resource ('Trending new GitHub repositories') and immediately bounds it: repos created in the last day/week/month, ranked by stars, via the GitHub REST search API. That scope cleanly separates it from siblings like github_health (repo health metrics) and repo_posture (security posture).

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 clear from the stated scope (discovering newly created, high-velocity repos) and the filterable dimensions tell an agent how to narrow results. What's absent is any explicit exclusion or routing advice – nothing says 'use github_health instead when you already have a specific repo', so the agent must infer that from sibling names.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new context beyond them: the tool is offline, costs $0.005 USDC per successful call via x402 on Solana, and the HMAC key is never echoed — all material to an agent deciding whether and how to call 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?

Front-loaded with the capability category, then a dense but information-bearing enumeration; nothing is redundant filler. The long algorithm lists are heavy to read but each item narrows scope for the agent rather than repeating structured fields.

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 9-parameter tool with a nested object and no output schema, the description enumerates what can be produced (digests, HMAC, encodings, identification, generated UUIDs/bytes) so the agent can anticipate results. It stops short of stating the response shape or how multiple requested operations are combined in one 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?

Schema description coverage is 100% and each parameter already documents its defaults and accepted values, so the schema carries the semantic load. The description adds only light reinforcement (e.g. hex or base64 HMAC output) and does not explain how the nested `generate` object or `identify` interaction behaves beyond 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 precise verb-and-resource set: hashing, HMAC, encoding/decoding, identification and UUID/random generation, with concrete algorithm names (Keccak-256, xxHash, base58, EIP-55). An agent can tell this is a crypto/encoding utility distinct from siblings like format_convert or jwt_decode without opening the 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?

The description makes the applicable task domain obvious (hash/HMAC/encode/identify/generate) but never routes the agent between this tool and close siblings such as jwt_decode, format_convert, password_strength or regex_test, and offers no when-not guidance. It does at least note the HTTPS/x402 access path as an alternative invocation channel.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable non-annotated context: pricing at $0.005 USDC per successful call, x402/Solana payment, and the equivalent HTTPS 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 description is front-loaded with the audit scope and uses compact, information-dense sentences. Pricing and the HTTPS endpoint are included without unnecessary prose.

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 audit tool with no output schema, the description gives enough detail about what is audited and that fix recommendations are included. It could be slightly more complete on response expectations or failure behavior, but the core calling context is present.

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 single 'url' parameter is already documented as a public http(s) URL or bare hostname. The description only says 'of a URL' and adds no further parameter semantics, which is the baseline for high schema coverage.

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

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

The description uses a specific verb and resource: 'Graded HTTP security-header audit of a URL.' It enumerates the exact header families checked, which distinguishes it from broad siblings like http_probe or redirect_chain.

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 the security-header focus, but the description does not explicitly say when to choose this tool over alternatives such as http_probe, redirect_chain, hsts_preload, or ssl_cert_info. No exclusions or prerequisites are stated beyond the URL requirement.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description still adds genuinely new behavior: paid access at $0.01 USDC per successful call via x402 on Solana, plus an HTTPS fallback endpoint — details an agent cannot get from structured fields.

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 dense but purposeful sentences: capability and filters first, return payload second, cost and alternate endpoint last. No filler, and the most decision-relevant information (what it searches) leads.

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 10-parameter tool with no output schema, the description usefully lists returned fields (title, URL, points, comments, author, time, comment text, HN links) and discloses cost. Minor gaps remain around pagination limits and how `exact` interacts with sort, but the 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 100%, so the schema already documents all ten parameters including defaults and enums. The description restates the main filters (sort, date range, type, author, minPoints) without adding syntax or edge-case detail, and it omits page/limit/exact entirely — 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 and resource ('Search Hacker News stories and comments') and pins the backing index (Algolia HN). No sibling tool targets Hacker News, and the naming plus scope make the boundary against arxiv_search/pubmed_search/reddit-like siblings obvious.

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

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

The description enumerates available modes (relevance vs newest-first, date range, type filter, author, min points), which implies how to narrow a query, but it never states when to choose this tool over an alternative or any prerequisite/exclusion. Usage is inferable rather than directed.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive, open-world), the description discloses cost ($0.01 USDC per successful call via x402 on Solana) and an equivalent HTTPS endpoint — material traits an agent must know before invoking. It stops short of describing response shape or failure behavior.

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

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

The capability statement is front-loaded in a single dense sentence followed by a short pricing/transport sentence; nothing is wasted. The first sentence is long and enumerates four ops inline, but that density is informative rather than 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 9-parameter, multi-mode tool with no output schema, the description covers coverage breadth, op semantics, weekend rules, cost and transport. The notable gap is that return values for each op are never sketched, which matters more here since no output schema exists to carry that.

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 every parameter is already documented with format and op binding, which sets the baseline at 3. The description reinforces weekend configurability (e.g. fri,sat), subdivision scoping and the 100+ country coverage, but adds little syntax or edge-case 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+resource (public holidays for 100+ countries) plus the four distinct operations it performs in one call: list, add/subtract, is-business-day, count. This is far more specific than the title 'Holidays Business Days' and no sibling tool covers holiday calendars or business-day math.

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 enumerates the four operation modes with the inputs each implies (year for listing, date+days for add, date for is-business-day, start/end for count), giving clear context for selecting an op. It does not state explicit exclusions or point to an alternative tool, but none of the siblings overlap.

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 beyond the annotations by disclosing the data source (hstspreload.org), the concrete checks performed, SSRF-safe fetching, and per-call pricing via x402. That is meaningful operational context the annotation flags do not convey. It stops short of explaining failure/error semantics or output shape.

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, followed by enumerated checks, then pricing and the HTTPS endpoint. Dense but each element earns its place; only the pricing/endpoint sentence is arguably tangential to agent tool selection.

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, yet the description enumerates the components of the response (list status, errors/warnings, header checks, redirect) and the source of truth, giving an agent enough to know what it returns. Combined with SSRF-safe and pricing notes, it is complete for 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?

Only one parameter, 'domain', and schema description coverage is 100%, so the schema already documents it. The description says checks are 'for a domain' but adds no format or edge-case semantics beyond 'registrable domain, e.g. example.com'. 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 and resource (HSTS preload check for a domain) and enumerates exactly what is verified: Chromium list status, preloadable errors/warnings, HSTS header checks, and redirect. It is highly specific, though it never names adjacent siblings (headers_audit, http_probe, ssl_cert_info) that an agent might confuse it with.

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 described scope implies when to use it (want to know if a domain is preloadable/preloaded), but there is no explicit when-to-use, when-not, or named alternative. The only routing hint is a same-tool HTTPS endpoint, not a sibling comparison.

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 read-only, idempotent, non-destructive and open-world traits, so the bar is lower, yet the description adds genuinely useful operational facts: pricing at $0.005 USDC per successful call via x402 on Solana, and an equivalent HTTPS endpoint. It does not describe failure/refund behavior or output format, but the payment model disclosure is exactly the kind of 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?

The purpose is front-loaded in the first sentence and the pricing/endpoint details are compact and useful. The duplicated JSON body fragment costs a few tokens redundantly against a fully documented schema.

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

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

With annotations present and full schema coverage, the description supplies what's missing: payment model, transport alternative, and a no-network guarantee. Only the return shape (a Markdown string, and whether it's wrapped in JSON) is left unstated for a tool with no output 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 description coverage is 100%, so the schema already documents every parameter including the 256 KB cap and the default-true link/image flags. The inline body snippet restates html/base_url/extract_main but adds no semantics beyond the schema, and it omits include_links and include_images entirely.

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

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

States a specific verb+resource (convert HTML string to clean Markdown) and enumerates the output flavors (GFM tables, fenced code, nested lists). 'No fetch' plus the string-input framing cleanly separates it from fetch-based siblings like url_markdown and web_to_text.

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

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

'No fetch' is an effective negative cue: an agent holding a URL rather than markup knows to look elsewhere. However, no sibling is named explicitly (url_markdown, readability_extract, format_convert), so routing requires a small inference step.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts the annotations cannot carry: the per-call price of $0.005 USDC via x402 on Solana billed only on success, and the specific payload returned. It still omits timeout, redirect-following, and error behavior, which prevents 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?

The core capability is front-loaded in the first clause, followed by output details, then pricing and the alternate endpoint. Every sentence carries information, though the trailing HTTPS-endpoint note reads as operational metadata rather than tool behavior.

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 its part by listing the fields returned and the header subset. But for a network probe it leaves out timeout limits, whether redirects are followed, how large responses are truncated, and what constitutes a 'successful call' for billing, so an agent cannot fully predict results.

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

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

Schema description coverage is 0% and the single parameter 'url' is a bare string with no description. The description does not compensate at all: it never says whether a scheme is required, whether http and https are both accepted, or how URLs are normalized before probing.

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 ('Fast HTTP GET probe') and enumerates the returned artifacts (final URL, status, timing, bytes, selected headers), so an agent knows exactly what it does. It does not, however, differentiate itself from close siblings such as headers_audit or redirect_chain, which is the only thing keeping it from 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?

There is no statement of when to prefer this over headers_audit, redirect_chain, tech_stack, or seo_audit, and no prerequisites or exclusions. The only routing hint is the equivalent HTTPS endpoint, which addresses transport, not tool 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?

Annotations already mark the tool read-only, idempotent, non-destructive, and open-world, so the bar is lower. The description adds valuable context beyond annotations: offline processing, no data leaving the server, pricing, returned fields, typo check-digit feedback, and BIC-vs-IBAN country matching.

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 core action is front-loaded, and the dense sentence is information-rich without filler. Pricing and HTTPS endpoint notes are relevant operational context for this paid x402 tool.

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 validator with no output schema, the description covers offline behavior, return fields, national check-digit handling, optional BIC validation, and privacy. An agent has enough context 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 baseline is 3, but the description adds meaning beyond the schema. It explains that the optional bic parameter triggers ISO 9362 structure checking and BIC-vs-IBAN country matching, which is substantive parameter-level semantics.

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

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

States a specific verb, 'Validate', and resource, 'IBAN', then enumerates offline checksum, per-country BBAN structure, national check digits, and optional BIC checks. The resource and scope are unambiguous and distinguishable from sibling validators such as eu_vat_validate or email_validate.

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 IBAN validation and explains that the optional BIC check can be used alone, but it gives no explicit when-to-use/when-not guidance and names no alternative sibling tool. Usage is therefore inferable but not fully guided.

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 (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial non-obvious context: a $0.005 USDC cost per successful call via x402/Solana, a ~190KB input cap tied to the 256KB POST-body limit, and the fact that pixels are not decoded. These cost and size constraints materially affect invocation decisions and are not derivable from annotations or schema.

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 capability and output fields before cost and transport details. It is dense and mostly earns its space, though the body/size-limit detail partially duplicates the schema 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 compensates by enumerating the returned fields (format, dimensions, megapixels, animation, sha256, EXIF summary) and disclosing pricing, input limits, and an alternate HTTPS endpoint. An agent has enough to decide whether to call it and how to supply input 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 parameters (image and include_exif_tags) are fully documented in the schema. The description repeats the base64 body shape and size cap but adds no new meaning for include_exif_tags or the accepted formats beyond what the schema states; 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 ('Inspect') and resource ('an image') and immediately enumerates the exact outputs returned (format, dimensions, megapixels, animation, sha256, EXIF summary), so the agent knows precisely what the tool produces. The 'without decoding pixels' qualifier further distinguishes it from image-manipulation siblings like image_resize or format_convert.

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 the purpose ('inspect an image' when you need metadata), but there is no explicit when-to-use/when-not guidance and no named alternative among siblings such as image_resize or format_convert. The HTTPS endpoint mention is a transport alternative, not a tool-selection guideline.

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

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

Beyond the annotations (readOnly/idempotent/openWorld), the description discloses concrete operational facts: a $0.01 USDC x402 charge per successful call, a 256KB POST body limit working out to ~190KB input, metadata stripping, EXIF auto-orient, and an alternate HTTPS endpoint. It stops short of describing failure/error behavior or the return payload, so it earns a 4 rather than 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?

It is dense but front-loaded: capability and limits come first, the request-body example anchors the shape, and pricing/endpoint go last. Every clause carries information an agent needs, and nothing is wasted.

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

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

The input side is complete, including a hard size constraint that would otherwise cause silent failures. However, there is no output schema and the description never says what comes back (base64 bytes, a URL, dimensions), which is a material gap for an image-processing tool an agent must chain on.

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 all eight parameters including enum values and defaults. The description restates the same facts (width/height up to 4096, fit modes, formats, quality, auto-orient) without adding new semantics; 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 opens with a specific verb and resource ('Resize / convert an image (GD)') and enumerates the operations supported (dimensions, fit modes, output formats). It is clear what the tool does, but it never distinguishes itself from the sibling `format_convert` or `image_info`, which overlap with the 'convert' and image-inspection territory.

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 stated: the size cap and the example body suggest when the tool is viable, but there is no explicit 'use this when you need X, use format_convert/image_info otherwise'. An agent must infer the boundary with the sibling tools.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: upstream sources, the public-IP constraint, per-call pricing of $0.005 USDC via x402 on Solana, and an equivalent HTTPS endpoint. Rate limits and error behavior remain undisclosed.

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

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

Three dense sentences, front-loaded with what the tool does and what it returns, then the constraint, then cost and endpoint. Telegraphic phrasing ('IP ASN + geolocation') is efficient rather than padded.

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 single-parameter tool with no output schema, the description names the returned fields, the data sources, the input restriction, and the payment model, which is enough to invoke it correctly. Minor gaps remain around failure modes and whether private/reserved IPs produce an error or empty 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?

With 100% schema coverage, the single 'ip' parameter is already documented as Public IPv4 or IPv6. The description's 'Public IPs only' reinforces the public/private distinction but adds no syntax or format detail beyond the schema, so the baseline of 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+resource: IP ASN and geolocation lookup, with named data sources and returned fields. The ASN/geo scope implicitly separates it from ip_reputation, but no sibling is named 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?

'Public IPs only' gives a clear input constraint, but there is no guidance on when to choose this over ip_reputation or domain_intel, or when an agent should avoid the paid call in favor of a free 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 declare readOnly/idempotent/non-destructive, and the description adds material context beyond them: the data is from cached published lists, the cost is $0.01 USDC per successful call via x402 on Solana, and an equivalent HTTPS endpoint is given. That price/payment disclosure is exactly the kind of behavioral fact an agent needs before calling.

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?

Scope and list coverage are front-loaded, followed by the disambiguation and then practical details (price, endpoint). Dense but each clause carries information; the separately appended HTTPS endpoint is slightly tacked-on rather than integrated.

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 describing the return payload (matched range/SBL reference, categories, 0-100 risk score). Combined with pricing, input limits, and the sibling boundary, 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 100% and the single parameter already documents comma-separated input, the max-50 limit, and the 'ips' alias. The description only restates the 50-address cap and adds that IPv6 is accepted; useful but marginal over structured data, 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-and-resource pair: blocklist reputation for up to 50 IPv4/IPv6 addresses, then enumerates the exact lists checked (Tor exit, Spamhaus DROP/DROPv6, Feodo C2, FireHOL level1). It explicitly distinguishes itself from the geo/ASN sibling by noting 'Blocklist membership only; complements /v1/ip-intel'.

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

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

It clearly scopes usage ('blocklist membership only') and routes the agent elsewhere for geo/ASN via ip-intel, which is the main disambiguation an agent needs against ip_intel/phishing_score. It stops short of explicit when-not guidance (e.g. no note on single-IP lookups or fallback to plain ip_intel when only geo is required).

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 read-only, idempotent, non-destructive behavior, but the description adds substantial operational context: what is repaired, that fixes and parse errors are reported, size limits, offline behavior, pricing, and an alternate HTTPS endpoint. This is rich disclosure beyond structured annotations and does not contradict them.

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

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

The purpose is front-loaded and the dense enumeration is justified by the tool's complexity. The paragraph is long and somewhat run-on, but nearly every clause contributes concrete capability or operational 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?

There is no output schema, so the description carries the burden of explaining returns. It does this by stating that the tool reports every fix, the original parse error, type and size stats, and optional JSONPath results. Combined with the size limit and payment/endpoint context, it is complete enough 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 baseline is 3. The description adds useful meaning for the optional query parameter by listing supported JSONPath forms such as $.a.b[0], [*], .., slices, unions, and filters, exceeding what the schema alone provides.

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

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

The description states a specific verb and resource: repairing broken or LLM-style JSON into valid JSON. It enumerates the exact repair classes handled, making it easy to distinguish from siblings like format_convert, schema_validate, or validate_batch.

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 a clear usage context: use it for broken or LLM-generated JSON and optionally for JSONPath queries on the repaired value. It does not explicitly name alternatives or exclusions, but the intended use case is clear from the repair-focused framing.

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