Mat Web & Data Toolkit (x402, Cloudflare)

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

With no annotations, the description carries the full burden. It usefully discloses that access requires payment (0.01 USDC on Base via x402, 12 sats Cashu or Lightning), which is real behavioral context an agent must know. However, it says nothing about data freshness, caching, rate limits, or failure modes on unpaid 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?

Two tight sentences, front-loaded with the payload contents before the payment detail. Every clause carries information, though the payment sentence is dense enough to be slightly hard to parse.

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 enumeration of returned fields partially compensates, and the payment disclosure is valuable. But the undocumented 'currency' parameter and total absence of usage guidance leave gaps for a paid, multi-source data 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 coverage is 0%: the single optional 'currency' parameter has no description in the schema, and the description never mentions it. 'Fiat prices' only hints that currency matters, giving no format or default behavior, so the description fails to compensate for the coverage gap.

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

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

Names a specific resource (Bitcoin snapshot) and enumerates exactly what it returns: fiat prices, recommended fees, mempool size, block height, difficulty adjustment. An agent can tell what data it yields, though it never explicitly distinguishes itself from siblings like lightning or crypto.

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 when-to-use guidance and no alternatives named. The payment sentence describes cost mechanics, not selection criteria, so the agent gets no help deciding between this tool and fx_rates, crypto, or lightning.

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

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

With zero annotations the description carries the full burden, and it discloses the most consequential behavioral fact: the tool is paid (0.01 USDC on Base via x402, or 12 sats Cashu NUT-24, or 12 sats Lightning L402). That payment gating and protocol detail is real value an agent cannot get elsewhere. It stops short of describing failure behavior 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?

Two sentences, front-loaded with the capability and domains, then the cost clause. Every element is relevant. The payment enumeration is dense but earns its place given it is a hard gate on invocation.

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 3-param converter with no output schema and no annotations, the description covers purpose, domains, an example call, and payment — enough to attempt a call. It is missing the enumerations an agent needs to avoid an invalid unit code, 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 compensate for three undocumented required params. It partially does: the example shows value as a numeric string and from/to as short unit codes (mi, km), and the domain list hints at valid unit families. However, it never enumerates acceptable unit symbols or case sensitivity, leaving real ambiguity for temperature and data-size units.

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 (unit conversion) plus the full set of supported domains (length, mass, volume, speed, area, data size, time, temperature), which tells an agent exactly what is and isn't convertible. None of the ~40 siblings perform unit conversion, so no sibling ambiguity exists.

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 inline example (value=10&from=mi&to=km) implies how to invoke it, and the payment sentence implies a prerequisite for use, but there is no explicit when-to-use guidance, no statement of when another tool applies instead, and no note on unsupported conversions or error conditions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It helpfully reveals that the tool costs 0.01 USDC on Base via x402, or 12 sats Cashu ecash or Lightning, which is important for an agent to know before invoking. However, it does not discuss rate limits, error handling, response format, or whether the operation is read-only, leaving significant behavioral gaps.

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 tool's purpose and data fields, followed by payment details. It uses two sentences with no obvious filler, though the payment enumeration is lengthy. Every sentence contributes relevant information, but the structure could be slightly tighter.

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

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

Given no annotations, no output schema, and 0% schema coverage, the description should be more complete. It covers the main data fields and coin id format, and it adds payment costs, but it omits the 'vs' parameter entirely and does not describe the shape of the response or any error conditions.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It explains that 'ids' takes comma-separated coin ids and gives examples, which is useful. But it never mentions the 'vs' parameter at all, leaving half of the inputs undocumented and likely ambiguous for an agent.

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 resource and source: 'Crypto prices from CoinGecko' and lists the exact data fields (price, 24h change, market cap and volume). It also names the input format for coin ids, making the tool's scope clear. However, it does not differentiate itself from similar siblings like btc_snapshot or fx_rates, 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?

There is no explicit guidance on when to use this tool versus alternatives such as btc_snapshot or fx_rates. The description only implies usage by saying what data it returns, offering no when/when-not conditions or preferred contexts.

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

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

With no annotations, the description carries the full burden and does well: it discloses the monetary cost and the three payment rails (x402 USDC, Cashu NUT-24, Lightning L402), the 366-day cap, and the default 30-day window. Only error/failure behavior is left 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?

One dense but well-ordered sentence that front-loads the resource and then layers defaults, constraints, return shape, and pricing. Nothing is wasted, though the pricing tail stacks three payment options into a single clause.

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 properly covers the return shape (one row per business day plus a ready-to-save CSV) and the payment prerequisite. It stops short of error handling or rate-limit behavior, but nothing essential to calling it is missing.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it names all four parameters, gives defaults (USD; AUD,EUR,GBP,JPY), and documents the date format (YYYY-MM-DD). It does not explain symbol-value syntax beyond the comma-separated hint.

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: daily FX rate history as a dataset, sourced from ECB reference rates. It is clear what the tool returns, though it never explicitly distinguishes itself from the sibling `fx_rates`, which an agent could easily 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?

Supplies useful operating context (defaults for base/symbols/date range, 366-day cap) but offers no explicit when-to-use-vs-alternative guidance, and the sibling `fx_rates` goes unmentioned. The constraint info is implied usage rather than 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?

With no annotations, the description carries the full behavioral burden and does it well: it discloses the payment rails and cost (0.01 USDC via x402, 12 sats Cashu NUT-24, or 12 sats Lightning L402), the license (CC BY 4.0), and the return shape (rows plus a ready-to-save CSV). It does not mention rate limits or failure behavior, 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?

It is a single dense block, but the core scope (indicator, country, year range) is front-loaded before the return, license, and pricing details. Every clause carries information; the heavy parentheticals make it slightly run-on but 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?

For a 4-param tool with no output schema and no annotations, the description covers the query semantics, result format, cardinality limits, licensing, and payment requirements. Only error/edge-case behavior is absent, which is a minor gap rather than a blocking one.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for all four parameters: indicator (alias list plus a concrete WDI code example like NY.GDP.MKTP.CD), country (up to 20 ISO codes with the AU;NZ;US syntax), and from/to (year range with the from=2015&to=2025 example). Format syntax is supplied for each, which the bare schema lacks 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?

The description names a specific resource (World Bank open data) and precisely scopes it: one indicator, up to 20 ISO country codes, a year range. An agent can tell this apart from dataset_fx by the 'World Bank' qualifier and the WDI indicator vocabulary. It stops short of an explicit verb or a direct sibling comparison, so it lands just below 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 implied by the resource description and the detailed indicator alias list, which signals the intended query type. However, there is no explicit when-to-use / when-not-to-use statement and no named alternative (e.g. dataset_fx, fx_rates) for the agent to route between. This is implied guidance 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?

With no annotations, the description carries the full burden, and it does disclose a significant behavioral trait: the call costs 0.01 USDC via x402 or 12 sats via Cashu/Lightning, i.e. it is a paid, payment-gated operation. However, it says nothing about return shape, failure modes (NXDOMAIN, timeouts), or whether payment is required before or after resolution.

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, zero waste, and the core capability is front-loaded before the payment details. Every clause carries information the agent needs.

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

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

For a simple one-parameter lookup with no output schema, the description covers the capability and the payment requirement, which is the non-obvious part. It is nearly complete; only the return format and error behavior are left implicit, which is minor for a tool of this complexity.

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 a single required parameter at 100% schema description coverage, so the schema already documents the hostname and its example. The description 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 ("Resolve") and resource (A, AAAA, MX, TXT, NS, CNAME records for a hostname), which is unambiguous and immediately actionable. It does not explicitly distinguish itself from siblings like ipinfo or rdap, but the DNS-record scope is inherently distinct, so an agent can still route correctly.

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 no when-to-use guidance, no exclusions, and no alternatives among the many sibling tools (rdap, ipinfo, ssl, headers). It does disclose the per-call cost, which helps an agent weigh the call, but that is pricing rather than usage direction.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the data source, the returned fields, and — critically — the three payment mechanisms and their prices (0.01 USDC/x402, 12 sats Cashu, 12 sats Lightning). It omits rate limits, refresh/caching cadence, and error behavior, which keeps it short of a 5.

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

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

Two sentences, purpose and filters front-loaded, then return fields, then cost. No filler, and the payment detail is placed last so it does not bury the core purpose.

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

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

No output schema or annotations exist, so the description is the sole information source; it covers the return shape and cost model adequately. The remaining gap is lat/lon format/units and any behavioral limits, but for a read-only data-fetch tool it is nearly complete.

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

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

Schema coverage is 0%, so the description must compensate for all 5 undocumented params, and it largely does: 'minmag' is explained as minimum magnitude, 'period' is given its enum values (hour|day|week|month), and 'radius_km' is tied to lat/lon with a km unit. It does not specify coordinate format or units for lat/lon, leaving a small 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 resource (recent earthquakes) with its data source (USGS) and the exact filter dimensions (minimum magnitude, period, radius around lat/lon). No sibling tool overlaps with seismic data, so the agent can distinguish it immediately 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 implies usage by enumerating the filters ('filter by minimum magnitude, period...'), which tells the agent how to shape a query, but never states when to reach for this tool versus alternatives or any exclusions. With no competing sibling, the omission is tolerable, but there is no explicit when-to-use 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?

With no annotations, the description carries the burden and does disclose two important behavioral traits: it performs no side effects ('no mail is sent') and it requires payment, enumerating three accepted payment rails and prices. It stops short of covering failure behavior, rate limits, or response 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?

The action is front-loaded in the first clause, with no filler or restatement of the name. The payment sentence is long and dense but earns its place since no annotations convey cost or auth requirements.

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 annotations and no output schema, the description covers purpose, side effects, and payment but leaves the return shape entirely unaddressed. An agent knows how to call it but not what it gets 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?

Only one parameter exists and schema description coverage is 0%, so the description must compensate. It says the input is an email address and that syntax is validated, but adds no format, length, or normalization details beyond what the self-evident parameter name 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?

States a specific verb and resource ('checks an email address's syntax and its domain's MX/A records') and scopes the operation tightly as a deliverability signal with no mail sent. An agent can tell this apart from generic DNS siblings like dns_lookup because the resource is the email address itself, not a hostname.

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 'deliverability signal' and the 'no mail is sent' clarification rules out verification-by-sending. However, no explicit when-to-use/when-not guidance or named alternative (e.g., dns_lookup for raw MX records) is offered.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does disclose the critical payment requirement plus three accepted payment rails (x402 USDC on Base, Cashu NUT-24, L402 Lightning), which prevents failed calls. It stops short of stating whether the operation is stateless, whether input is retained, or how invalid encodings fail.

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, purpose and supported formats front-loaded, with parameter semantics before the cost note. No filler or repetition, and the dense payment clause is genuinely load-bearing.

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 annotations, no output schema, and no parameter descriptions, the description still covers purpose, formats, op semantics, default output, and payment requirements. The remaining gap is the return shape and error behavior, which is minor but non-trivial 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 0% across three parameters, so the description must compensate. It clarifies the op parameter's accepted values and implies format selects a single encoding while the default returns all, but it never explains the legal values of format or how text is interpreted, leaving the format parameter under-specified.

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 concrete verb pair (encodes/decodes) on a concrete resource (text) and enumerates the exact encodings supported (base64, base64url, hex, URL-encoding, HTML entities), which cleanly separates it from unrelated siblings like hash or convert. An agent knows precisely what this tool does 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?

It explains the op parameter's two values and the default behavior (all encodings returned when none specified), which implies how to call it. However, it names no alternative sibling and gives no when-not-to-use or precondition guidance beyond defaults.

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

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

With no annotations, the description carries the full behavioral burden and does disclose key traits: data is read live from public RPC and, importantly, the call is paid (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, or 12 sats L402). It does not cover rate limits or error behavior, but the payment requirement is a significant disclosure most definitions omit.

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 well front-loaded: scope and return shape first, then parameter guidance, then the read/payment facts. Each sentence adds information; slightly long but 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 3-param tool with no annotations and no output schema, the description covers scope, chain enumeration, token syntax and defaults, data source, and cost. Remaining gaps (address format, chain default, return structure) are minor but real given zero structured support.

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 compensate. It does explain tokens= (symbols like USDC/USDT/DAI/WETH or contract addresses, comma-separated, with a documented default) and implies the chain values via the enumerated list, but the address parameter and the chain default are never described.

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 ('Wallet balance on an EVM chain') and enumerates the supported chains plus the fact that it returns native coin and ERC-20 balances. It is clearly distinguishable from evm_gas/evm_tx/evm_token by resource, though it never names those siblings 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?

Usage context is implied by the resource and the token-symbol guidance, but there is no explicit when-to-use statement and no exclusions or named alternatives among the evm_* siblings. An agent must infer that this is the balance-lookup tool versus evm_token or evm_tx.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the important non-obvious trait: the tool is pay-per-call at 0.01 USDC on Base via x402, 12 sats Cashu ecash, or 12 sats over Lightning (L402). It also enumerates the returned fields. It does not mention rate limits, caching/freshness guarantees, or error behavior, so it falls short of full 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?

Two sentences, both front-loaded with the most decision-relevant information (what it returns, then what it costs). No filler, no restatement of the name or title.

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-annotation, no-output-schema tool, the description supplies the return fields, the chain selection semantics, and the payment model — enough for an agent to call it correctly. Gaps remain around error handling, rate limits, and freshness, but the core is covered.

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

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

The schema documents the single 'chain' parameter with 0% description coverage and no enum, so the description must compensate. It does: it lists the accepted chain names and explains that omitting 'chain' returns all chains while 'chain=' selects one, adding real semantics beyond the bare string type.

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 ('Live gas snapshot across EVM chains in one call') and enumerates the covered chains, making it immediately distinguishable from siblings like evm_balance, evm_token, and evm_tx. The scope and output content are stated up front.

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 parenthetical '(ethereum, base, arbitrum, optimism, polygon, or chain= for one)' implies the two usage modes — omit chain for all, pass chain for one — but the guidance is embedded rather than explicit. There is no statement of when to prefer this tool over evm_balance/evm_tx, and no exclusions or prerequisites beyond the payment 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?

With no annotations, the description carries the full burden and does disclose two material traits: it is a read against live public RPC, and it is a paid call (0.01 USDC via x402, 12 sats Cashu NUT-24, 12 sats L402) — payment requirements an agent must know before invoking. It does not disclose failure behavior for addresses lacking contract code or non-ERC-20 contracts, which it hints at but never resolves.

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 with no filler: the resource and return fields come first, RPC sourcing second, payment terms last. The pricing sentence is long but every clause is operationally relevant to an agent that must pay. Slightly more compact phrasing of the three payment rails would reach 5.

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

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

There is no output schema and no annotations, so the description has to cover both the return payload (it does, field by field) and the safety/payment profile (it does: read-only, live RPC, priced). The remaining hole is address formatting and error behavior, which matters for a 2-param paid tool but is not 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?

Schema coverage is 0% and there are 2 parameters, so the description must compensate. It does list five accepted chain values (base, ethereum, arbitrum, optimism, polygon), effectively supplying the missing enum for `chain`. However, `address` is left entirely unspecified in both schema and description — no format, hex/checksum, or contract-vs-EOA semantics — so compensation is only partial.

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 (ERC-20 token facts for a contract) and enumerates exactly what is returned: name, symbol, decimals, total supply, and a contract-code check. That field list implicitly separates it from siblings like evm_balance, evm_gas, and evm_tx, which return different data. It never explicitly names a sibling, so it lands just 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 agent can infer this is the tool for token metadata given a contract address, and the parenthetical chain list and price options give practical context. There is no statement of when to prefer this over evm_balance/evm_tx, nor any exclusion (e.g., what happens for non-token contracts or EOAs).

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

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

With no annotations, the description carries full burden and does disclose a major behavioral trait: this is a paid tool costing 0.01 USDC via x402 or 12 sats via Cashu/L402 Lightning, plus it previews the returned payload. It does not cover failure modes (invalid/nonexistent hash), rate limits, or default chain behavior, so it stops short of full 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?

One dense sentence front-loads the purpose, then groups returned fields, then payment options; the long field enumeration earns its place given no output schema. Slightly list-heavy but 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 two-parameter read tool with no output schema and no annotations, the description covers what the tool does, what it returns, and its unusual payment requirement. The remaining gaps are input-side details (hash format, chain default) rather than missing decision-critical context.

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 compensate. It does add meaning for 'chain' by enumerating valid values (base, ethereum, arbitrum, optimism, polygon), but says nothing about the required 'hash' parameter's format (0x-prefixed hex) or whether chain is optional and what the default is.

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 ('Transaction lookup by hash on an EVM chain') and enumerates both the supported chains and the returned fields, so an agent can distinguish it from evm_balance, evm_gas, and evm_token without inspecting schemas.

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

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

Usage is implied: call this when you have a transaction hash and want its details. The five valid chain values are listed, which implicitly guides the chain argument, but there is no explicit when-not guidance or routing to siblings (e.g., use evm_token for token metadata).

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

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

With no annotations, the description carries the full burden. It does disclose two valuable behavioral facts: it only works on public pages and it requires payment (0.01 USDC on Base / 12 sats Cashu / 12 sats Lightning). It says nothing about rate limits, JS rendering, robots.txt handling, redirects, or failure modes.

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

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

Two tight sentences with the return shape front-loaded and the payment terms second. The payment sentence is dense but each element earns its place since pricing is otherwise invisible to an agent.

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 and no annotations, the description compensates by enumerating the returned fields and disclosing the cost model, which is the minimum an agent needs to call it. The remaining gap is not knowing when this tool beats its overlapping siblings.

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

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

There is a single parameter with 100% schema description coverage ('Public http(s) URL'), so the schema already documents it. The description reinforces the public-URL restriction by saying 'public web page' but adds no syntax, normalization, 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?

The description gives a specific verb+resource ('Fetch a public web page') and enumerates exactly what is returned (title, meta description, outbound links, plain text as JSON). However, it never distinguishes itself from close siblings such as meta, links, or readable_text, which appear to expose overlapping subsets of this output.

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 when-to-use guidance and no routing to alternatives, even though siblings like meta, links, readable_text, and markdown plausibly cover the same ground. The only usage-relevant detail is the payment requirement, which is a constraint rather than a selection rule.

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

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

With no annotations, the description carries the full burden and does disclose useful traits: it is free, makes no paid call, and returns either decoded x402 payment requirements or the upstream result on a 200. However, the return behavior is ambiguously worded ('or the result'), and nothing is said about error/timeout handling 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?

Two sentences, front-loaded with the 'FREE' qualifier and the tool identity. No filler, though the second sentence is dense and slightly hard to parse.

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 explain returns, and it partially does (x402 payment requirements or upstream result). For a simple one-parameter tool this is mostly sufficient, but the ambiguous return wording and absent error behavior leave gaps.

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

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

Schema coverage is 100% and the single 'address' parameter is fully documented as a '0x EVM address' in the schema. The description's 'for an EVM address' merely restates that, adding no syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb+resource: a wallet checker for an EVM address returning agent-likeness, sybil flags, and FLAPJAX holding. It is clearly distinguishable from generic siblings like evm_balance or evm_tx, though jargon such as 'agent-likeness' and 'x402' is left unexplained.

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 says what the tool is but never states when to use it versus alternatives such as evm_balance or evm_token, nor any prerequisites beyond providing an address. The 'FREE' marker hints at a cost-based selection reason but no explicit guidance is given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the upstream source (NWS), the granularity (7 days, 12-hour periods), what fields come back, and the three payment rails with exact prices. It stops short of mentioning rate limits, caching, or failure modes for out-of-range or non-US coordinates.

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

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

One dense sentence that front-loads the core purpose (what it forecasts, for what input) before the pricing detail. Every clause carries information, though the payment enumeration makes it somewhat run-on rather than scannable.

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

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

With no output schema and no annotations, the description steps in to enumerate the returned payload and pricing, which is substantial. The remaining gap is the undocumented 'hourly' parameter and absent guidance on behavior for invalid or non-US coordinates.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that lat and lon are query-style string inputs and implies the default 12-hour granularity, but the third parameter, 'hourly', is never mentioned, leaving its accepted values and effect on the response entirely undocumented.

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 and scope: a US weather forecast for a lat/lon point, sourced from the National Weather Service. It names the returned payload concretely (7 days of 12-hour periods with temperature, wind, precipitation chance, short/detailed text, forecast office, nearest city), which separates it cleanly from the sibling weather_alerts.

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 rather than stated: an agent can infer this is the tool for point forecasts and that weather_alerts covers warnings, but the description never names that alternative or states when-not to use this. The payment-rail sentence gives practical invocation context (x402 vs Cashu vs L402) but is not a use-case 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?

With no annotations, the description carries the full behavioral burden. It does disclose a significant trait the schema can't convey: the call is paid, with three distinct payment rails (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, 12 sats L402). However, it says nothing about rate limits, caching, what the response contains, or what happens when no base is supplied.

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, front-loaded with the core capability before the pricing detail. The pricing sentence is dense but each rail is meaningful and nothing is repeated. No wasted words, though the alternate-payment enumeration is longer than strictly necessary.

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, no annotations, and one undocumented parameter. The description covers the payment dimension well but omits the default base behavior and the shape of the returned rate data, which an agent needs to consume the result. Adequate but with clear gaps.

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

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

One optional string parameter at 0% schema description coverage, so the description must compensate. It adds example values ('e.g. USD, AUD, EUR') but never states the behavior when 'base' is omitted (default currency?) or the accepted format (ISO 4217 three-letter, any case). 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?

States a specific resource with scope qualifiers: 'Latest ECB reference FX rates for a base currency', plus example currency codes. The 'ECB reference' and 'latest' qualifiers help distinguish it from siblings like convert and dataset_fx, though it never names those alternatives 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?

There is no when-to-use guidance at all: nothing says how this differs from convert (which likely does arbitrary conversion) or dataset_fx (which likely serves historical FX data). The payment rails are presented as cost information rather than as a decision cue for the agent.

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

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

With no annotations, the description carries the full burden, and it does add genuinely useful behavioral context: the tool is paid, with three accepted payment rails (x402 USDC, Cashu ecash, Lightning L402). However, it discloses nothing about the return shape (whether one hash or a set is returned) or error behavior for invalid algorithms.

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, front-loaded with the hashing behavior before the payment detail, with no filler. The payment sentence is dense with three price points but each is relevant to calling the tool successfully.

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 hash utility with no output schema and no annotations, the description covers algorithms, default behavior, HMAC, and cost. The main remaining gap is the shape of the returned hashes, which the absent output schema would otherwise need to supply.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the alg values (md5, sha1, sha256, sha512, default all) and that key enables HMAC, which covers two of three parameters meaningfully, but it omits the exact accepted string format for alg and does not describe the text parameter's treatment.

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 (hashes) and resource (text), and enumerates the four algorithms plus optional HMAC, which concretely distinguishes it from vaguer siblings like encode or crypto. An agent can tell what it produces 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?

There is no guidance on when to use this versus siblings like encode or crypto, no exclusions, and no prerequisites beyond the payment note. The default-all-algorithms and HMAC-with-key behavior implies some usage, but no explicit when/when-not is offered.

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

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

With no annotations, the description carries the full burden and does well: it discloses the redirect policy, the HEAD-then-GET fallback strategy, and the payment requirement across three rails (x402, Cashu NUT-24, L402), which is critical operational context. It omits error behavior, timeouts, and return format, but the payment and request-mechanics disclosure is genuinely useful.

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 front-loaded sentences: the capability comes first, followed by request mechanics and pricing. The payment enumeration is verbose but each item is functionally necessary since no other field conveys 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?

For a single-parameter fetch tool with no output schema or annotations, the description covers what is returned and the payment requirement, but leaves error handling, timeout behavior, and result formatting unaddressed. Adequate but with clear gaps an agent would want filled.

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 'url' parameter with 0% schema description coverage, and the description adds no meaning beyond 'for a URL' — it never says whether a scheme is required, whether non-HTTP schemes work, or what format is expected. The single parameter is left essentially undocumented in both places.

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 and output set ('HTTP response headers, status and timing for a URL'), which is clearly distinct from siblings like ssl, meta, and site_audit. It does not explicitly name a sibling to distinguish against, but the scope is unambiguous enough to route correctly.

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 when-to-use guidance or named alternatives are given; the agent must infer that this tool is for inspecting raw HTTP response metadata. The behavior notes ('no redirect following, HEAD then GET fallback') describe how it runs, not when to pick it over site_audit or ssl.

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

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

With no annotations at all, the description carries the full disclosure burden, and it does surface genuinely non-obvious behavior: the tool is paid, at 0.01 USDC on Base via x402, 12 sats Cashu (NUT-24), or 12 sats over Lightning (L402). That payment/auth requirement is exactly the kind of context an agent must know before invoking. It stops short of describing failure modes, rate limits, or what the year parameter defaults to.

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, zero filler. The functional scope and the country-code format lead, and the payment mechanics follow; every clause adds information an agent cannot get from the bare 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?

For a simple two-parameter lookup with no output schema and no annotations, the description covers the return content (dates, local names, regions), the data source, the country format, and the payment requirement. The remaining gap is the optional-year default and the response shape, which the absent output schema would otherwise have had to carry.

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

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

Schema description coverage is 0%, so the description has to compensate, and it does for both parameters: country is specified as an ISO code with concrete examples (AU, US, GB), and year is identified as the year of interest. It does not state the accepted year format or that year is optional and what happens if it is omitted, leaving a small but real gap.

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

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

The description names the exact resource (public holidays), the scoping axes (country and year), and what the response contains (dates, local names, regions) plus the upstream source (Nager.Date). No sibling tool covers holidays, so an agent can route to it unambiguously from the name-plus-description alone.

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 description says it returns holidays for a country/year, from which an agent infers when to call it. There is no explicit when-to-use statement, no mention of what to do when the year is omitted, and no named alternative or exclusion.

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

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

With no annotations, the description carries the full burden, and it delivers the critical non-obvious trait: this call costs money, via three distinct rails (x402 USDC on Base, Cashu NUT-24, Lightning L402). 'Free public sources' also flags data provenance/accuracy limits. It omits rate limits, failure behavior, and IPv4/IPv6 coverage, 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?

Two sentences: purpose first, payment mechanics second. The payment sentence is dense but every clause is load-bearing for an agent that must choose a rail; 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?

No output schema and no annotations, so the description must stand alone. It covers purpose, returned fields, and cost/payment, which is most of what an agent needs; only input format and error/rate-limit behavior are absent.

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

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

One required parameter with 0% schema description coverage, so the schema documents nothing about 'ip'. The description implies it is the address to geolocate but adds no format, version, or validation detail, leaving the schema gap only partially closed.

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 (IP address geolocation) and enumerates the fields returned (country, region, city, timezone, ASN/ISP), which separates it from siblings like dns_lookup and timezone. It does not explicitly contrast itself with those siblings, 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?

There is no statement of when to prefer this over dns_lookup, rdap, or other network tools, and no exclusions. The only usage-adjacent content is the payment rails, which describe how to pay rather than when to call.

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

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

With no annotations, the description carries the full burden, and it does disclose important behavior: the specific diagnostic fields returned and the fact that the tool is a paid endpoint with three distinct payment rails (x402/USDC, Cashu NUT-24, L402 Lightning) and their exact prices. It stops short of stating error behavior on malformed input, rate limits, or whether the pretty-printed copy is always returned.

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, zero filler. What the tool does is front-loaded ahead of the ancillary cost information, and every clause (diagnostic outputs, three payment options with prices) carries information an agent needs.

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

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

For a low-complexity, single-parameter tool with no output schema, the description compensates well by enumerating the return contents and flagging the payment requirement. It would be fully complete if it distinguished the valid vs. invalid JSON response shapes or noted whether payment is per-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 0% and the single parameter 'json' is undocumented, so the description must compensate. Phrasing it as 'Validates a JSON string' usefully clarifies that the parameter is a string containing JSON rather than an already-parsed object, which is real added meaning over the bare schema, though no format or size expectations are given.

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 ('Validates a JSON string') and enumerates the concrete outputs (parse errors with position/line, type, depth, key count, pretty-printed copy), so the agent knows exactly what it returns. No sibling tool does JSON validation, so there is no real sibling to differentiate against, but the definition never explicitly carves out its niche either.

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

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

The description explains what the tool does and what it costs, but gives no when-to-use context, no prerequisites, and no exclusions or alternatives (e.g., when to pick this over a general 'parse' or 'encode' utility). Usage must be inferred entirely from the tool name and description.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the payment mechanics (0.01 USDC on Base via x402, or 12 sats Cashu NUT-24, or 12 sats Lightning L402), which is real behavioral context an agent must know before invoking. However it omits permissions, rate limits, and failure modes.

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, front-loaded with the capability and followed by the cost information. Both sentences earn their place; the payment sentence is long but necessary since cost is a real invocation constraint.

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 and no annotations, the description should do more: it never clarifies that zero parameters are required, what happens if both or neither url/text are supplied, or the shape of the returned keyword data. Adequate but with clear gaps for a tool an agent can call with no arguments.

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 both params (url, text) are undocumented in structured data. The description partially compensates by indicating a text-vs-web-page input split, but does not clarify that both are optional, whether one is required, or how conflicts between url and text are resolved.

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 operation (word count plus top keywords/bigrams, stopwords removed) on a specific resource (text or a web page). The function is clearly distinct from siblings like extract_page, readable_text, and readability, so an agent can identify it 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 phrase 'for text or a web page' implies the two input modes but never says when to choose url vs text, whether they are mutually exclusive, or when another sibling (e.g. readable_text) would be preferable. Usage is only implied, not 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?

With no annotations, the description carries the full burden and does well: it discloses the privacy scoping (no personal names, no emails), the per-call row cap, and three distinct payment rails with exact costs. It stops short of return format, errors, or pagination behavior beyond the row cap.

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 resource and its fields, then filters and limits, then cost. Dense but every clause adds call-relevant 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?

No output schema or annotations exist, so the description must explain returns, and it does by listing the record fields. It covers limits and payment, omitting only pagination/format details an agent might want.

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 compensate, and it does name both parameters and their roles (filter by country, filter by q). However it never explains what 'q' searches over or the matching semantics, leaving half the parameter meaning to inference.

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 (small-business web-agency leads for AU/NZ) and enumerates the returned fields, which cleanly separates it from utility siblings like dataset_fx or dataset_worldbank. It lacks an explicit verb ('list'/'fetch'), but the resource and scope are unambiguous.

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

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

It states the filtering options (country/q) and the 25-row cap, which implies usage, but never says when to prefer this tool or what it is not for. No prerequisites or exclusions beyond the field-level privacy 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?

With no annotations, the description carries the full behavioral burden, but it does disclose genuinely useful context that structured fields don't: the tool is paid (0.01 USDC on Base via x402, or 12 sats Cashu/L402) and sourced from mempool.space. It says nothing about data freshness, caching, rate limits, or response latency, which matters for a stats 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?

Front-loaded with the metrics the tool returns, followed by the payment options in a single tight sentence. Every clause earns its place; only the payment enumeration is slightly bulky.

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 tool with no output schema, the description effectively substitutes for a return-value spec by listing the metrics, and it flags the payment requirement. Nothing essential to invoking it correctly is missing, though the default unit and freshness remain 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 0%, so the description must compensate, and it does: it documents the single parameter's accepted values (btc|sats) and scopes it to capacity only. This is meaningfully more than the bare schema provides, though it doesn't state the default unit.

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 (Bitcoin Lightning Network statistics) and enumerates exactly which metrics are returned: channel and node counts, total capacity, average/median fees and channel sizes. It also names the data source (mempool.space). It does not explicitly differentiate itself from siblings like btc_snapshot or crypto, 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 explicit when-to-use or when-not-to-use guidance, nor any mention of the sibling tools (btc_snapshot, crypto) that an agent might confuse this with. Usage is only weakly implied by the resource name, so the agent has to infer the routing decision itself.

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

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

With no annotations, the description carries the full disclosure burden and does a good job: it reveals the 50-link cap, the three result categories, and — critically — the payment/auth requirements (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, or 12 sats L402). It stops short of stating timeout, redirect-following behavior, or what a partially fetched page yields.

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, front-loaded with the core behavior before the pricing detail. The payment sentence is dense but justified because cost is decision-relevant for an agent choosing this tool; only mild verbosity in enumerating three payment rails.

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-annotation, no-output-schema tool with one parameter, the description covers purpose, limit, result categories, and cost — most of what an agent needs before invoking. Gaps remain around timeout/error behavior and whether the caller is charged for failed fetches.

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

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

The single url parameter has 0% schema description coverage, so the schema contributes nothing. The description implies the parameter is the web page whose links are checked, which is marginally useful, but it never clarifies format expectations (scheme required, single URL vs. list, depth of crawl).

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 — checks every link on a web page (capped at 50) and reports each link's HTTP status as broken, redirected, or OK. The scope and output categories are unambiguous. It does not, however, differentiate itself from adjacent siblings such as site_audit, unshorten, or headers.

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 guidance on when to reach for this tool versus alternatives like site_audit or unshorten, nor any prerequisite (e.g., page must be publicly reachable). The payment sentence describes cost, not usage context, so the agent is left to infer the trigger conditions.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose a genuinely important trait: the call is paid, with three concrete rails and exact prices (0.01 USDC via x402, 12 sats Cashu NUT-24, 12 sats L402). It omits anything about failure behavior, whether payment is automatic, or payload limits, keeping it out of 5 territory.

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, zero filler, and the core purpose is front-loaded before the pricing detail. Every clause earns its place.

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

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

For a one-parameter converter with no output schema, the description covers what it does, what it produces (HTML), and the unusual cost model. The only gap is that output shape (e.g., returned HTML string vs. file) and input limits are never addressed.

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 'md' parameter is undocumented in both schema and description. The description at least makes the input meaning inferable ('Markdown ... to HTML' implies the string is the Markdown source), but it adds no format, encoding, or size guidance, so it only marginally compensates.

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 ('Converts Markdown ... to HTML') and even enumerates the supported Markdown constructs (headings, links, tables, etc.), so the function is unambiguous. However, it never differentiates itself from the potentially overlapping 'convert' sibling, 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?

There is no when-to-use guidance, no mention of when this is preferable to 'convert' or 'readable_text', and no note on input size limits or when conversion would fail. The agent is left to infer all routing 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?

With no annotations, the description carries the full burden, and it does disclose the most important non-obvious trait: this is a paid call requiring 0.01 USDC on Base via x402, 12 sats Cashu (NUT-24), or 12 sats Lightning (L402). It says nothing about what happens on payment failure, rate limits, redirects, or whether non-HTML URLs error out, so the disclosure is partial.

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, zero filler: the returned fields are front-loaded and the payment options follow. Slightly compressed by the dense list and the three payment rails, but every clause carries information.

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

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

For a one-parameter read tool with no output schema, the description covers what fields are returned and the payment requirement, but it omits input format for url, behavior on non-HTML or failed fetches, and any routing versus sibling extraction tools. Adequate but with clear gaps.

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

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

The single url parameter has 0% schema description coverage and the description never mentions it, so nothing states whether it accepts a full URL, scheme, relative path, or handles redirects. The context ('page metadata') makes the parameter guessable, which keeps this above a 1.

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 resource (page metadata) and enumerates the specific fields returned — title, description, canonical, Open Graph, Twitter card, favicon, language, JSON-LD types — so an agent knows what comes back. The verb (extract/fetch) is only implied, and it never distinguishes itself from near siblings such as extract_page, readability, readable_text, or headers.

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 when-to-use guidance at all: nothing says to prefer this over extract_page, readability, or headers when the goal is page metadata. The only conditional content is pricing, which tells the agent it must pay but not when this tool is the right choice.

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

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

With no annotations, the description carries the full burden and does well: it discloses exact costs (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, or 12 sats L402), that validation happens before payment, and the naming/availability rules. It does not describe the success/failure response or whether registration is permanent.

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?

Information-dense but front-loaded: identity and target, then serving path, then name rules, then cost/payment options. Each sentence earns its place, though the telegraphic style packs several distinct facts per 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 paid, unannotated, no-output-schema registration tool, the description covers purpose, constraints, pricing, and payment rails well. The main remaining gap is post-registration behavior (what is returned, reversibility), which no structured field supplies.

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 compensate, and it does: it explains name syntax (a-z0-9._-, max 30), pubkey type (hex), and relays format (optional, comma-separated wss:// URLs). This meaningfully fills the schema gap for all three 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?

States a specific verb (Registers) and resource (Nostr NIP-05 identity name@domain for a hex pubkey), and names the serving location (/.well-known/nostr.json). No sibling tool overlaps, but the purpose is unmistakable and self-contained.

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 operating context: name constraints, first-come-first-served, and that invalid/taken names are refused before payment. It also routes the agent to the free availability check (/nip05/check?name=) as an alternative pre-step, though it stops short of 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the call is paid (0.01 USDC via x402, 12 sats Cashu, 12 sats Lightning), which is genuine behavioral context an agent needs. However, it says nothing about failure modes, malformed feeds, redirects, or timeouts that matter for a network-fetch tool.

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

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

Two sentences, front-loaded with the purpose before the pricing detail, with no filler. The payment clause is dense but each token carries information.

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

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

There is no output schema, but the description does sketch the return shape (title and items with title, link, date, summary), which compensates. It still omits the URL parameter contract and any failure behavior, leaving gaps for a fetch 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 0% for the single required 'url' parameter. The description implies the URL points at an RSS/Atom feed, which adds marginal meaning, but it gives no format, scheme, or error guidance for that 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 states a specific verb ('Parse') and resource ('RSS or Atom feed') and even enumerates the returned structure (title and items with title, link, date, summary). This is unmistakable versus siblings like extract_page or readability, though it never names an alternative 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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives. The cost sentence describes payment mechanics, not when this tool is the right choice over extract_page or readability.

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

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

With no annotations the description carries the full burden, and it usefully discloses three payment rails (x402 USDC, Cashu NUT-24, L402 Lightning) which is real behavioral context. It does not cover error behavior, rate limits, or what happens on an unresolvable domain.

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 front-loaded sentences: the payload summary first, then the pricing rails. Minimal waste, though the multi-rail pricing string is dense.

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

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

Given no annotations, no output schema, and 0% parameter coverage, the description covers what is returned and the payment model but omits the domain input format and failure semantics. Adequate but with a clear gap on the single parameter.

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 ('domain') at 0% schema description coverage and the description says nothing about its expected format (bare domain vs. URL, IDN handling, TLD requirements). With zero schema documentation, the description needed to compensate and does not.

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 ('Domain registration data via RDAP') and enumerates the returned fields (registrar, created/expiry dates, status, nameservers). It is distinguishable from the adjacent dns_lookup/ssl tools by the registration-data focus, though it never explicitly contrasts with 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?

No guidance on when to choose this over siblings like dns_lookup, whois-style lookups, or ssl, and no exclusions or prerequisites beyond the payment options. The cost sentence hints at paid usage but not at selection criteria.

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

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

With no annotations, the description carries the full behavior burden, and it does disclose meaningful operational context: the cost (0.01 USDC, 12 sats via Cashu/L402) and payment rails, which an agent genuinely needs before calling. It omits other traits such as whether the URL is fetched live, timeout/failure behavior, or any rate limitations.

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, front-loaded with the purpose and metrics before the cost detail. The pricing clause is dense with bare acronyms (x402, NUT-24, L402) but still earns its place since no annotations carry it.

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

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

With no output schema, the description usefully enumerates the returned metrics, which is the right call. But for a two-parameter tool with zero schema coverage and no annotations, the missing input semantics and usage conditions leave it only minimally complete.

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

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

Schema coverage is 0% for two undocumented parameters, so the description must compensate. 'Text or a web page' loosely maps to text/url but never names them, states exclusivity, format expectations, or what happens if both or neither are supplied. 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?

States a specific resource and names the exact outputs (Flesch reading ease, Flesch-Kincaid grade, sentence/word/syllable counts), so an agent knows precisely what it gets. It does not, however, distinguish itself from close siblings like readable_text or extract_page.

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

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

There is no guidance on when to use this versus nothing else, no statement of prerequisites, and no indication that url and text are alternative input modes rather than complementary. The pricing sentence is the only extra context, and it is about cost, not usage selection.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses important cost and payment information (0.01 USDC on Base via x402, 12 sats Cashu ecash, or 12 sats over Lightning), which is valuable context. However, it omits other behavioral traits such as rate limits, error handling, or whether payment is required on every call.

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 uses two efficiently structured sentences: the first front-loads the tool's purpose, and the second provides payment details. Every sentence earns its place, though the payment sentence is dense with three separate rails.

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 a simple one-parameter tool with no output schema and no annotations, the description covers purpose, return format, and cost. It still leaves out parameter specifics, usage guidance, and payment mechanics, which are important for an agent to invoke the tool correctly without prior knowledge.

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% for the single 'url' parameter. The description implies a web page URL but gives no format, constraints, or examples to compensate for the missing schema documentation. An agent must infer the parameter's role entirely from the parameter name.

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: 'Return the main readable article text of a web page as paragraphs.' This clearly conveys what the tool does. However, it does not differentiate itself from the sibling tool 'readability' or 'extract_page', which likely have overlapping purposes.

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 no guidance on when to use this tool versus alternatives such as 'readability' or 'extract_page'. There is no mention of prerequisites, exclusions, or conditions for selecting this tool over its siblings.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that this is a write admission, the exact cost and payment mechanisms (x402 USDC on Base, Cashu NUT-24/Lightning L402), that refusals happen before payment, and that the NIP-05 bundle is free. This is unusually rich disclosure for a mutation 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?

Purpose and price are front-loaded, and each clause earns its place (payment, bundle, refusal, free check). It is dense and the raw status URL is slightly awkward, but there is little padding.

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

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

For a mutation tool with no annotations and no output schema, the description covers payment, prerequisites, refusal conditions, and the identity bundle. It stops short of describing the successful response or reversibility, but is otherwise sufficient 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, but the description adds real meaning: 'add name= to also register name@automatom.matt-d59.workers.dev as your NIP-05 identity' explains the effect and cost of the name parameter and ties the relays param to the NIP-05 record. It goes beyond the terse 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?

Names a specific verb+resource+scope: one-time write admission to a named Nostr relay for a hex pubkey, and clarifies that reads are free. An agent immediately knows this is a paid admission/mutation tool rather than a generic relay operation.

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 strong context: two payment rails with exact prices, a free pre-check endpoint, and the fact that already-admitted pubkeys or taken names are refused before payment. It does not explicitly name the sibling nip05_register as the alternative for identity-only registration, so the when-to-use-this-vs-that differentiation is implied by the bundle clause 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?

With no annotations, the description carries the full burden, and it does disclose a significant behavioral trait: the tool is paid (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, or 12 sats Lightning L402), which the agent must know before calling. It also sketches the parse structure, but says nothing about failure modes (e.g., a site with no robots.txt) 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?

Two sentences, front-loaded with the function and followed by the payment terms; nothing is redundant. The pricing sentence is dense but every clause carries necessary information an agent needs.

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

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

For a one-parameter tool with no output schema or annotations, the description covers what it does, what the parse yields, and the cost of calling it. Still missing are the accepted URL format and behavior when robots.txt is absent or unreachable, which an agent cannot recover from structured fields.

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

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

Only one parameter, and the schema description coverage is 0%. The description implies the URL is the site whose robots.txt is fetched, which adds a little meaning, but it never clarifies whether the value should be a bare domain, an origin, or a full URL including scheme/path.

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 ('fetches and parses a site's robots.txt') and enumerates the parsed outputs (user-agent groups, allow/disallow, crawl-delay, sitemap URLs). It does not explicitly distinguish itself from the sibling 'sitemap', which covers the related adjacent artifact, so differentiation relies on the agent's own inference.

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 the purpose: fetch this when you need a site's crawl rules. There is no explicit when-to-use, no exclusions, and no routing to alternatives such as 'sitemap' for derived sitemap URLs or 'site_audit' for broader checks.

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

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

With no annotations, the description carries the full burden. It does disclose genuinely important behavior the schema cannot convey: the tool is paid, with three payment paths (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, 12 sats Lightning L402). However, it omits read-only confirmation for a clearly non-mutating audit, rate limits, and what happens on unreachable/redirecting URLs.

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, front-loaded with the capability list before the pricing detail, with no filler. The payment sentence is long but every element (three methods, prices, protocols) is operationally necessary.

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 and no annotations, the description does well to enumerate the audited signals (effectively describing the return payload) and the payment requirement. Still missing are URL format expectations and output shape, leaving gaps an agent must discover by calling.

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 sole parameter is a bare untyped-in-practice "url" string. The description never states whether a scheme is required, how redirects are handled for the URL, or any format constraints, so it fails to compensate for the coverage gap even though the parameter is fairly self-evident.

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?

Specifies a clear verb+resource ("site audit") and enumerates the exact checks performed (status, response time, redirects, TLS expiry, security headers, SEO meta tags). This implicitly distinguishes it from single-purpose siblings like ssl, headers, and meta, though it never explicitly says it aggregates 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?

There is no guidance on when to prefer this bundle over the many overlapping siblings (ssl, headers, meta, robots, sitemap, unshorten). The word "Quick" hints at a one-shot aggregate but the agent is left to infer that, and no exclusions or prerequisites are 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses that invocation is paid (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, or 12 sats via L402), and that output is capped at 500 entries. It stops short of error behavior for non-sitemap URLs, gzip handling, or whether index children are followed.

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 actual function and output shape, with no filler. The second sentence is long because it enumerates three payment rails, but that detail is materially relevant to invocation, so it earns its place.

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

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

No output schema exists, so the description correctly spells out return content (count plus up to 500 entries with lastmod, changefreq, priority). What is missing are the input format specifics and failure modes for a one-parameter parser, but it is largely self-sufficient.

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

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

One required parameter at 0% schema coverage, so the description should compensate, but it never explains the url format (absolute URL, .xml, gzipped, index vs child sitemap). The intent of the parameter is only implied by the tool name.

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: 'Parses an XML sitemap or sitemap index', and immediately characterizes the output (URL count, entries, lastmod/changefreq/priority). This clearly separates it from ambiguous siblings like parse_feed, robots, or links without needing to open 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?

There is no guidance on when to reach for this tool versus siblings such as robots, parse_feed, site_audit, or links, nor any prerequisite/exclusion conditions. The only decision-supporting content is pricing, which tells the agent what it costs but not when it is the right choice.

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

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

With no annotations, the description carries the full burden and does disclose two important behavioral traits: the data comes from a live HTTPS check plus Certificate Transparency logs, and the call is paid (0.01 USDC on Base via x402, or 12 sats via Cashu NUT-24 or Lightning L402). It omits failure modes for unreachable/non-TLS hosts, latency, and whether results are cached, which keeps it short of a 5.

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

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

Two sentences, zero waste: the first front-loads what is returned and the data sources, the second packs the payment options. Nothing is repeated from the schema or 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 annotations, no output schema, and one undocumented parameter, the description covers the two biggest agent questions — what comes back (field list) and what it costs (all three payment rails). It falls short only on error behavior for invalid or non-HTTPS hosts.

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% for the single required parameter, so the description must compensate. It says the value is a host, which conveys the semantic meaning of the field, but gives no format guidance (bare hostname vs URL vs host:port), so an agent could still pass a malformed value.

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 (TLS certificate details for a host) and enumerates the exact fields returned — subject, issuer, SANs, validity dates, days to expiry. It is unambiguous about what the tool does, but never names or contrasts a sibling such as dns_lookup or headers, so sibling differentiation is left to inference.

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 use this tool versus the many other host/domain-oriented siblings, nor prerequisites about when a live HTTPS check applies. The payment-method sentence hints at cost but gives no guidance on which rail to choose or when the tool is the right call.

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

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

With no annotations, the description carries the full behavioral burden, and it does add real value: it discloses that the tool is paid, listing exact costs (0.01 USDC via x402, 12 sats Cashu NUT-24, or 12 sats L402), so an agent can anticipate a 402-style payment flow. However, it says nothing about invalid time-zone handling, DST edge cases, or what happens with omitted optional parameters.

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, front-loaded with the core behavior and the concrete example before the cost details. Nothing is redundant, though the payment sentence is dense with three parallel options that could be summarized more tightly.

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 must convey what comes back; 'reports UTC offsets' gives only a partial picture of the response shape. Combined with missing defaults for the two optional parameters and no error behavior, it is adequate for a simple converter but not fully self-contained.

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

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

Schema description coverage is 0%, so the description must compensate, and the example does establish formats: time as an ISO datetime, from and to as IANA time-zone names. It still never states the default when 'from' or 'time' is omitted (only 'to' is required) or what error occurs for an unrecognized zone, leaving the optional-parameter contract partially undefined.

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 — converts a date-time between IANA time zones and reports UTC offsets — which is far more concrete than the vague tool name 'timezone'. It implicitly separates itself from the generic 'convert' sibling, though it never names any sibling. Clear, but no explicit sibling differentiation.

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

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

Usage is only implied through the inline query example (time=...&from=...&to=...), which does show the intended call shape. There is no when-to-use, when-not-to-use, or named alternative, and the pricing sentence describes payment rather than when to pick this tool.

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

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

With no annotations, the description carries the full burden, and it delivers the single most operationally important fact: this is a paid tool with three settlement paths (0.01 USDC on Base via x402, 12 sats Cashu NUT-24, 12 sats Lightning L402). That is the equivalent of an auth/cost requirement an agent must budget for. It still omits failure modes (unreachable URL, non-redirecting URL) and any 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?

Two sentences, front-loaded with the purpose and the output shape before the cost detail. The payment sentence packs three options into one line, which is slightly dense but every clause is operationally relevant.

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 paid utility with no annotations and no output schema, the description is adequate but incomplete: it outlines the return content in prose yet omits error behavior for non-shortened or unreachable URLs, and gives no hint about how the payment step is triggered or confirmed before the call succeeds.

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

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

The schema has one required parameter with 0% description coverage, so the description must compensate and largely does not. It implies the input is a shortened/redirecting URL, but adds nothing about format (scheme required?), validation, or what happens with a URL that does not redirect.

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 verb 'Expands' plus the resource 'a short or redirecting URL' is specific, and the description even previews the output (full redirect chain, status codes, final destination). It does not explicitly position itself against any sibling, but among the mostly unrelated siblings (dns_lookup, links, headers) its role is unambiguous.

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

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

Usage is implied rather than stated: an agent can infer it should call this when it holds a shortened or redirect-wrapped URL. There is no explicit when-not-to-use, no mention of an alternative tool (e.g. links or headers), and no prerequisites such as requiring a funded wallet.

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

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

No annotations exist, so the description carries the full burden, and it does add meaningful behavior: the tool is paid (0.01 USDC on Base via x402, or 12 sats Cashu ecash, or 12 sats over Lightning/L402), which an agent must know before calling. However it omits any auth, rate-limit, caching, or freshness/reliability traits, and doesn't say what happens on an unpaid or failed request.

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, front-loaded with the core capability and the lookup modes, followed by the payment options. Little waste, though the payment sentence is dense with several schemes that could be tightened.

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, and the description partially compensates by enumerating returned fields, and it discloses full pricing. Gaps remain: the severity filter is unexplained, no guidance on combining area with lat/lon, and nothing about behavior on payment failure — meaningful holes for a paid, 4-param tool with zero annotation coverage.

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% across four parameters, so the description has to compensate. It clarifies 'area' as a US state code (area=TX) and lat/lon as a point lookup, covering three of the four params. The 'severity' parameter is never described as an input filter — the description only lists severity as a returned field — leaving one parameter with no semantic guidance.

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 ('active US National Weather Service alerts') and enumerates what comes back (event, severity, urgency, areas, onset/expiry, headline, instructions). It also names the two accepted lookup modes, so an agent understands the tool's scope. It does not explicitly distinguish itself from the sibling 'forecast' tool, which is the nearest alternative, so it stops short of 5.

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

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

Gives operational guidance on inputs (area=TX state code, or lat=&lon= point) which implies when it applies, but offers no when-to-use vs when-not guidance and never contrasts with 'forecast' or other weather/data siblings. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full burden and does well: it discloses the exact response shape, licensing (CC BY-SA 4.0), and a detailed three-way payment model (x402 USDC on Base, Cashu ecash, Lightning L402). It does not cover failure modes, rate limits, or what happens on no-match, which keeps it short of a 5.

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

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

Front-loaded with the core behavior and return contents, then licensing and pricing. Dense but every sentence adds actionable information; the payment enumeration is long yet necessary since it is the only place cost is stated.

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 enumerating return fields. Payment requirements, the language default, and licensing are all covered. Missing only error/no-result behavior for a tool this simple, so it is close to complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'lang' clearly (other Wikipedias, default en), but 'q' is left entirely undocumented beyond the word 'topic'. Half the parameters get real semantic help, half do not.

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 ('Wikipedia lookup: searches a topic and returns the best-matching article') and enumerates the returned fields (title, description, summary, URL, thumbnail, other matching titles). It never names or contrasts with plausible siblings such as extract_page, readable_text, or readability, so an agent must infer the distinction itself.

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 'searches a topic' and the lang note gives a scoping hint, but there is no explicit when-to-use or when-not-to-use guidance and no mention of alternative tools for retrieving page content or text. The payment options are operationally relevant but do not route the agent between tools.

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