FreeTier Agent API

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the critical non-obvious behavior — a $0.01 USDC x402 charge and the fact that a call returns the HTTP request plus payment requirements rather than data, requiring a second paid step. Cost, payment rail, and the two-step retrieval flow are exactly the kind of context annotations cannot express.

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

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

Densely front-loaded: price first, then scope and corpus, then filters, then the payment mechanics. Every clause carries information an agent needs before calling, with no filler.

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

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

With no output schema and no annotations covering payment, the description correctly explains the unusual return value (an HTTP request + payment requirements) and how to complete it. What the final paid payload contains and any rate limits remain unspecified, which is a minor gap for a search tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and largely does: it names all three filters, gives the type enum values (mcp|x402), and constrains limit (<=100). 'q' is not explained (what fields are matched), and the schema types limit as a string despite the numeric bound, but the compensation for 0% coverage is solid.

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 — 'One search across ~13,000 agent tools' — and quantifies the corpus (4,259 MCP servers + ~8,900 x402 APIs), so the agent knows exactly what this covers. It implicitly spans the ground of siblings mcp_servers and x402_services as a unified search, but never names or contrasts with those siblings, so differentiation must be inferred.

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: it gives the payment precondition ('pay with any x402 client') but never says when to choose this over mcp_servers, x402_services, or apis_search. No explicit when-not guidance or alternative routing is provided.

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 discloses that the tool is free and requires no API key, but says nothing about read-only nature, rate limits, response shape, or any other operational trait.

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

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

Two short sentences with no wasted words. The key selling points (free, live, no key) are front-loaded, though the brevity borders on under-specification.

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

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

For a zero-parameter tool with no output schema and no annotations, the description gives only a minimal picture: it says there are five live public APIs and they need no key. It does not describe the return format or what exactly the agent should expect.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4 even though the description adds no parameter information.

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 implies the tool surfaces a sample of five free/public APIs, but it does not state an explicit verb or clarify whether it returns names, endpoints, or metadata. It only weakly differentiates itself from siblings like free_tiers or list_endpoints.

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 mentions that the APIs are free and need no key, which implies a context for use, but it gives no guidance on when to choose this tool over alternatives such as apis_search, free_tiers, or list_endpoints.

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

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

Annotations only cover readOnly/openWorld, so the description carries the interesting behavior and does so well: it discloses the two-step x402 flow (the call returns the exact HTTP request and payment requirements rather than the data itself) and the cost and client needed to complete payment. That is critical context an agent cannot infer from the schema.

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

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

Three dense sentences, front-loaded with the payment requirement and resource scope, with no filler. Slightly telegraphic (filter list is run-together), 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?

There is no output schema, and the description correctly explains what the call returns (HTTP request + x402 payment requirements) and how to finish the flow. Minor gaps remain around pagination, error handling, or what happens post-payment, but the essential picture is complete.

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

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

With only 43% schema coverage, the description compensates by listing all seven filters with their salient values (auth=none, alive=yes, https=yes, limit<=50). It adds real meaning beyond the schema, though 'category' and 'kind' values are left without explanation.

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

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

States a specific verb (Search) and a precisely quantified resource (2,230 link-checked public & free-tier APIs across 59 categories). An agent can immediately distinguish it from siblings like free_tiers, list_endpoints, or x402_services.

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

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

The description flags that this is a paid call ($0.01 USDC via x402), which is a real usage consideration, but it never states when to prefer this over alternatives such as free_tiers or x402_services, nor any when-not condition. Usage is implied through cost rather than guidance.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses that the call is paid ($0.01 USDC via x402), and critically that invoking it returns an HTTP request plus payment requirements rather than the data itself — a two-step flow the agent must understand. Cost and payment mechanics are exactly the kind of behavioral context annotations cannot carry.

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

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

Three sentences, front-loaded with the cost and the returned data, then the payment mechanics. Every sentence carries information an agent needs; there is no filler.

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

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

With no output schema, the description helpfully enumerates what is returned (gas price, latest block, per-transfer ETH cost estimates) and explains the payment round-trip. It could note return encoding or freshness, but for a no-param, no-output-schema tool it is largely 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?

The tool takes zero parameters, so there is nothing to disambiguate; the baseline for a 0-param tool is 4. The description adds no parameter detail because none is needed.

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

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

The description states a specific resource and scope: live Base mainnet gas price in gwei, latest block, and ETH cost estimates for USDC (~65k gas) and ETH (21k gas) transfers. This is far more specific than any sibling (e.g. llm_pricing, currency), so an agent can tell exactly what this returns.

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 describes the payment workflow ('pay with any x402 client to get the data') but gives no explicit when-to-use guidance or comparisons to alternatives such as llm_cost or currency. Usage is implied by the resource name rather than stated, so it is only minimally adequate.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description adds substantial value: the exact price ($0.002 USDC), the x402 payment mechanism, and critically the two-phase behavior where the first invocation returns payment requirements rather than the data. This is exactly the kind of non-obvious behavior an agent needs. Rate limits and failure modes are not covered, 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, front-loaded with the cost signal and then the field list, with no wasted words. The second sentence is dense but every clause (payment requirements, x402 client) 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?

There is no output schema, so the description must explain the return, and it does: it lists the returned fields and clarifies that the first call returns payment requirements rather than data. Complete enough to call correctly, with only minor gaps around error/payment-failure behavior.

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

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

Schema coverage is 100% and there is a single 'q' parameter already documented as 'ISO2, ISO3 or country name'. The description's 'by ISO2/ISO3/name' simply restates the schema with no added syntax or format detail, so baseline 3 applies.

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

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

States a specific verb ('reference lookup') and resource ('country') and enumerates the returned fields (capital, population, continent, currency, time zones, etc.), so the agent knows exactly what it fetches. It does not explicitly differentiate itself from siblings like 'currency' or 'dump_world_reference', which keeps it short of a 5.

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

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

The description explains the payment flow (first call returns the HTTP request and x402 requirements; pay with any x402 client to get data), which is essential usage context. However, it gives no when-to-use vs alternatives guidance and does not mention the 'currency' sibling that overlaps on currency data.

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

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

Annotations only say readOnlyHint/openWorldHint, but the description discloses a highly non-obvious behavioral trait: the tool is paid ($0.002 USDC via x402), and calling it returns the HTTP request and x402 payment requirements rather than the data directly, requiring an x402 client to actually retrieve results. It also states the return includes the rate date. This is exactly the kind of extra context the annotations cannot convey.

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

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

Dense and front-loaded, leading with the paid/cost context and data source before params and return behavior. The 'Params: from, to, amount' line is mildly redundant with the schema but everything else 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 payment-gated API with no output schema, the description covers cost, payment mechanism, data source, and a key return field (rate date). Only the precise shape of the successful response and accepted currency-code format are left unspecified.

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 carry parameter meaning. It only lists the names ('from, to, amount') with no format guidance (e.g., ISO currency codes, how amount is expressed as a string, defaults). The '~30 currencies' hint is the only semantic value added.

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 (currency conversion) and the data source (official ECB euro reference rates, ~30 currencies, daily), which is far more informative than the bare name 'currency'. It is not confused with any sibling tool (country, holidays, base_gas), though it does not explicitly name an alternative.

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

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

Usage is implied by the description (convert between currencies) but there is no explicit when-to-use/when-not guidance or named alternative. It does explain the payment precondition and how to complete a call, which is closer to behavioral than selection guidance.

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

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

Discloses critical behavior beyond the annotations: the $8 USDC cost, the x402 payment mechanism, and most importantly that the call does NOT return the data but rather the HTTP request and payment requirements. readOnlyHint/openWorldHint are consistent with this, though the paid/transaction nature versus a 'readOnly' hint could use one clarifying phrase.

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, front-loaded with the price that most affects an agent's decision, followed by what the call actually returns. 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 zero-param purchase tool with no output schema, the description covers the essential facts an agent needs: cost, payment rail, dataset size/format/license, and the fact that the response is a payment request rather than data. A note on delivery latency or post-payment retrieval would make it fully complete.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds relevant semantics around the invocation (payment via any x402 client) even though there are no arguments to document.

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 (Buy) and resource (full Verified API Directory dataset), plus concrete scope detail (2,230 rows, JSON, license). The word 'full' implicitly contrasts with the free api_directory_sample sibling, but that sibling is never named, so an agent must infer the distinction.

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?

Conveys that this is the paid, complete-data path and that an x402 client is needed to actually pay, which implies usage. However it never states when to choose this over the free sample or the other dataset/endpoint siblings, and offers no exclusions or prerequisites beyond the price.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the critical behavior an agent cannot infer — the operation is paid, and calling it does NOT return data but instead returns the HTTP request plus x402 payment requirements that must be settled with an external x402 client. This two-step, cost-bearing flow is essential and well disclosed.

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

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

Three tight sentences with the most decision-relevant fact (Paid, $7 USDC via x402) front-loaded, followed by scope, licensing/attribution, and the payment mechanics. No filler or repetition.

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

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

With no input parameters and no output schema, the description carries the return-value burden and does so by explaining that the immediate response is an HTTP request plus payment requirements rather than the dataset itself. It covers scope, cost, licensing, and delivery, leaving only minor details (e.g. response payload size, format of the payment challenge) 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level explanation is needed or missing.

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 ('Full dump: Agent Tool Directory') and quantifies scope (~13,000 MCP servers + x402 APIs in one unified JSON schema). This clearly distinguishes it from the split siblings dump_mcp_servers and dump_x402_services as the combined superset.

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 usage context by flagging the tool as paid ($7 USDC via x402) and explaining the two-step pay-to-fetch flow, which governs whether an agent should call it at all. It never explicitly names an alternative (e.g. the free sample or split dumps) or states when-not to use it, so it stops short of full routing guidance.

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

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

Discloses behavior that annotations cannot: the tool is paid ($5 USDC via x402), and critically, calling it does NOT return the data but returns the exact HTTP request and x402 payment requirements, which must be fulfilled with an x402 client. This two-step, non-obvious interaction model is exactly the kind of context the description must carry.

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

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

Two dense sentences with no filler; the cost and payload are front-loaded before the mechanics of payment. Slightly packed, but every clause (price, contents, license, return shape) 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?

With no output schema, the description does the work of explaining what comes back (JSON pricing table plus free tiers) and what a call actually yields (an HTTP request plus payment requirements). Minor gaps remain about payload size and the post-payment retrieval step, but the core contract is clear.

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 takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. It does not need to compensate for any undocumented inputs.

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 ('Full dump: list prices of ~3,000 AI models ... + verified free tiers') with concrete scope (~3,000 models, JSON output). The word 'Full' plus the dataset contents distinguish it from the sibling sample variants (llm_pricing_sample, llm_pricing) without opening either schema.

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

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

Usage is implied rather than stated: the paid, complete dump is for agents that need the entire table, in contrast to the sample siblings. However, no alternative is named and there is no explicit when-not condition (e.g., 'use llm_pricing_sample for a free preview'), so the agent must infer the routing.

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

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

Annotations only cover readOnly/openWorld, so the description carries the behavioral burden and does it well: it discloses the price, the license/source, and critically that the call returns the HTTP request plus x402 payment requirements rather than the data itself. That non-obvious two-step payment behavior is exactly what an agent needs before invoking.

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

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

Four short sentences, front-loaded with the price and the payload size, then the source and the payment mechanics. Dense but every sentence adds a fact an agent needs; only minor tightening is possible.

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 the return, and it does: the first call yields the HTTP request and x402 payment requirements, and payment yields the data. For a parameterless paid dump, that is sufficient, though it could note the response size or format after payment.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description does not invent parameter semantics, which is correct here.

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 ('Full MCP server directory dump') with a concrete scope ('4,259 servers, JSON'), which immediately separates it from the sibling 'mcp_servers_sample'. An agent can tell it is the complete, paid dump without opening anything else.

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

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

Gives clear context for use: it is paid ($9 USDC via x402) and requires 'any x402 client', which frames when this tool is appropriate versus free siblings. It stops short of explicitly naming the free alternative (mcp_servers_sample/mcp_servers) or stating a when-not-to-use condition, so it is clear context without exclusions.

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

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

Annotations only cover readOnly and openWorld; the description supplies the operationally decisive facts the agent could not otherwise know: it is paid ($6 USDC via x402), the call is a two-step pay-then-fetch flow, and the immediate return is a payment challenge rather than the dataset. That is exactly the context an agent needs to avoid misusing the tool.

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

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

Four terse fragments, price and payload front-loaded, then the crucial return-behavior caveat. Nothing is padded, and the data-source attributions are compact enough to double as provenance 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?

With no parameters and no output schema, the description carries the return-value burden and does so: it specifies JSON and, more importantly, that the first response is an HTTP request plus payment requirements rather than the data itself. An agent has everything needed to invoke and interpret the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly spends no words on argument semantics.

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

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

The description states a specific verb (dump) and resource (world reference) and enumerates the payload precisely: 252 countries, 418 time zones, ~14,000 holidays for 2026-2027. That enumeration implicitly separates it from the granular siblings (country, holidays, currency), though it never names an alternative outright.

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

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

It gives clear, non-obvious invocation context: calling it does not return data but returns the exact HTTP request plus x402 payment requirements, which must be settled with an x402 client. It stops short of saying when to prefer this bulk paid dump over the free per-resource siblings, so selection guidance is left to inference.

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

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

The annotations only declare readOnlyHint and openWorldHint, so the description carries the real behavioral burden — and it delivers: it discloses the $6 USDC x402 gate, that calling the tool returns an HTTP request plus payment requirements rather than the data itself, the ~8,900-record volume, and the CC BY 4.0 attribution obligation. These are non-obvious traits an agent could not infer from structured fields.

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

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

Four dense sentences, front-loaded with cost and scope, then data provenance, then the critical calling mechanic. Every sentence carries information, though the license/attribution clause 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?

With no output schema and no parameters, the description must explain the return path, and it does (payment requirements first, data after paying). It stops short of clarifying whether payment is per-call or one-time and what the payload looks like after settlement, which would fully close the loop.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; the description correctly implies a no-argument full dump and adds no misleading parameter claims.

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 with scope and scale: 'Full dump: ~8,900 x402 pay-per-call APIs with category, price, chains and probe status (JSON).' The word 'Full' distinguishes it from the sibling x402_services (presumably a sample), though it never names that sibling explicitly.

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

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

Usage is only implied: the paid framing and 'Full dump' suggest you use this when you need the complete dataset rather than a sample, but there is no explicit when-to-use/when-not guidance and no named alternative (x402_services, api_directory_sample) to route between.

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

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

Adds substantial behavior beyond the readOnlyHint/openWorldHint annotations: it is paid ($0.005 USDC via x402), explains that the call returns the HTTP request and payment requirements rather than data directly, requires an x402 client to settle, and states addresses are not stored or logged. These are exactly the operational details an agent needs before calling.

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

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

Dense but front-loaded: cost and the no-SMTP constraint lead, followed by the checks, verdicts, and limitations. Nearly every sentence carries distinct information, though the enumeration-of-flags style is slightly list-heavy.

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

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

With no output schema, the description shoulders the return value burden and does so: it names the possible verdicts (deliverable_domain | risky | invalid) and explains the unusual x402 payment-first response flow. An agent knows both what it gets and what it must do to get it.

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

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

Only one parameter with 100% schema description coverage ('one email address'), so the schema already carries the semantics. The description adds no syntax or format detail for the email argument, making the baseline 3 correct.

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 ('Email address check') and immediately scopes it ('WITHOUT sending mail or SMTP probing'). It enumerates exactly what is checked (RFC syntax, MX/A DNS-over-HTTPS, disposable, role-address, free-mail) and the verdicts, which cleanly separates it from siblings like link_check, page_check and robots_check.

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

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

Clear context for use and an explicit boundary ('Cannot confirm that the mailbox itself exists'), which tells the agent not to expect mailbox-level certainty. It does not name an alternative tool for cases this doesn't cover, so it stops short of full when/when-not routing.

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

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

Far exceeds what annotations provide. Discloses pricing ($0.015 USDC via x402), that calling returns an HTTP request and payment requirements rather than data, the LLM-vs-deterministic fallback, that results are type-checked with nulls for missing fields, char/property limits, and an accuracy caveat. This is exactly the behavioral context an agent needs.

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

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

Dense but front-loaded with the cost and the input/output contract; each sentence carries distinct information (payment, fallback, limits, caveat, params, transport). Slightly run-on and packed, but virtually no wasted words.

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

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

For a paid x402 tool with an LLM/heuristic pipeline and no output schema, the description covers the critical gaps: the payment round-trip, output shape (clean JSON, nulls for missing), limits, and reliability caveat. Nothing essential for correct invocation is missing.

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

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

With 67% schema coverage the description still adds meaning: it enumerates the params (text, schema as JSON string, mode=auto|heuristic) and adds constraints absent from the schema, notably 'schema <= 30 top-level properties (flat objects, arrays of scalars)' and the 6,000-char text cap. Not fully exhaustive, but it goes beyond the schema.

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

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

States a specific verb and resource ('Messy text + JSON Schema in, clean JSON out') and names the exact mechanism (LLM with heuristic fallback). An agent immediately understands this converts unstructured text into schema-conformant JSON, which no sibling tool does.

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

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

Explains the internal auto/heuristic mode behavior and invocation transport ('GET query or POST JSON body'), but gives no explicit when-to-use guidance or criteria for choosing mode=auto vs mode=heuristic. Implied usage only, adequate but not directive.

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

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

Annotations already declare readOnlyHint and openWorldHint, yet the description adds the critical non-obvious trait: the tool is paid ($0.01 USDC via x402) and a call returns the exact HTTP request and payment requirements rather than data, requiring an x402 client to complete. That two-step payment flow is exactly the kind of behavioral context structured fields do not cover, though it omits per-call vs. repeated-charge or idempotency details.

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 front-loaded with the most decision-relevant fact (paid, $0.01 USDC via x402) and packs purpose, scope, filters, and return behavior into three sentences with little waste. The terse 'Filter: q, category' fragment is the only structurally weak element.

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 explains that a call returns an HTTP request plus payment requirements. But given 0% schema coverage and no enums for category, the missing semantics of q and category leave an agent unable to call the tool optimally; the payment/return story is complete while the input story is not.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only lists the parameter names ('Filter: q, category'). It never explains what q matches, what values category accepts (no enum in the schema), or how the two interact, so an agent cannot form a correct query from this text alone.

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

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

The description states a specific resource: current free-tier limits for developer services (hosting, DB, auth, email, CI, monitoring) and AI/LLM APIs, with official source URLs. That is concrete and distinguishable from pricing siblings like llm_pricing or dump_llm_pricing. However, it never explicitly contrasts 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?

It implies usage by naming the filter parameters (q, category), which tells the agent this is a searchable lookup. But it gives no when-to-use guidance, no exclusions, and does not point to any alternative tool for related data such as llm_pricing or apis_search.

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

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

Annotations only declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered elsewhere. The description adds genuinely useful behavior beyond that: the exact cost ($0.002 USDC), the x402 payment flow, and the fact that the call returns an HTTP request plus payment requirements rather than data directly. It does not cover rate limits or failure/refund behavior, 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, front-loaded with the critical paid/x402 context before the data description. Efficient overall, though the payment mechanics and the data scope are interleaved rather than cleanly separated.

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

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

With no output schema, the description carries the burden of explaining returns, and it does explain the unusual x402 request/payment-requirement response. It stops short of describing the holiday payload shape or the is_holiday return format, but for a 3-parameter lookup tool it is largely 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 only 33%, so the description must compensate. It adds the date format (YYYY-MM-DD), the country scope (~490 countries/territories), and the year range, but the date parameter's effect is described only obliquely and the country ISO2 meaning is left to the schema. Partial compensation 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?

The description gives a specific verb+resource: public holidays for ~490 countries/territories for 2026 and 2027, with an optional date lookup that answers is_holiday. This is far more concrete than the bare name 'holidays'. However, it makes no attempt to distinguish itself from the closest siblings (country, currency), 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?

Usage is only implied: 'optional date=YYYY-MM-DD answers is_holiday' tells the agent what the date parameter buys you, and the year enum implies year-scoped lookups. There is no explicit statement of when to reach for this tool versus alternatives, nor any 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?

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the exact price ($0.05 USDC via x402), the two-step protocol (calling returns the HTTP request and x402 payment requirements, then you pay with an x402 client), and the batch ceiling. Cost and payment mechanics are precisely the behavioral facts an agent needs before invoking.

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

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

Three tight sentences, front-loaded with the cost and scope, then the returned fields, then the payment mechanics. No filler and 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?

There is no output schema, so the description compensates by enumerating the returned fields, and it fully explains the payment gate that stands between the call and the data. Nothing an agent needs to invoke and interpret this tool is missing.

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

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

Schema coverage is 100% for the single 'urls' parameter, so the schema already documents format ('comma-separated absolute URLs, max 20'). The description's 'up to 20 URLs' merely restates that limit without adding syntax or validation detail. Baseline 3 applies.

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

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

States a specific verb and resource (check URLs), the batch limit (up to 20), and enumerates exactly what is returned (status, final URL, redirect count, latency, content-type, ok flag). It does not, however, differentiate itself from close siblings like page_check or robots_check, so an agent must infer the distinction from the return fields.

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

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

Usage is implied by the batch scope ('check up to 20 URLs in one call') and the payment flow is described, but there is no explicit when-to-use vs. alternative guidance and no exclusions relative to the many sibling checkers.

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 does disclose that invocation is free and what each entry contains (price in USDC on Base via x402, description, example query), but says nothing about read-only nature, result size/pagination, or failure modes for a catalog-listing 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?

A single dense sentence with the cost qualifier ('Free.') front-loaded and the payload described after the verb. Efficient, though the telegraphic fragment plus stacked parenthetical adds mild parsing friction.

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 parameters, the description must stand in for the return shape, and it does name the three fields included per endpoint. It stops short of describing ordering, result count, or format, which is a minor gap for a catalog tool.

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

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

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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

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

States a clear verb ('List') and a specific resource ('paid FreeTier Agent API endpoint'), and enumerates the returned fields (price, description, example query). It does not, however, distinguish itself from close siblings such as x402_services, dump_x402_services, or free_tiers, so an agent must still infer which listing tool to pick.

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 only usage signal is the leading 'Free.', which implies no cost concern, but there is no statement of when to choose this over x402_services, dump_x402_services, or free_tiers. No exclusions or triggering conditions are 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?

Annotations cover only readOnlyHint and openWorldHint, so the description carries the critical extra burden and does so well: it discloses that the tool is paid ($0.01 USDC via x402), that calling it does NOT return data but instead returns the exact HTTP request and x402 payment requirements, and that a payment client is needed to actually get the result. This two-step payment behavior is essential and not derivable from structured fields.

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

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

It is a dense but well front-loaded paragraph: purpose first, then the paid/x402 behavior, then parameter notes. Nearly every clause earns its place, though the sentence packing model ids and constraints is slightly heavy.

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

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

For a 5-parameter, no-output-schema tool this is close to complete: it explains the payment/return contract, the parameter list, and the token-vs-text input modes. The undefined 'calls' parameter and the exact response shape are the only remaining 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 0%, so the description must compensate, and it does for most parameters: models is explained with concrete id examples and a 'max 15' constraint; text vs input_tokens/output_tokens alternatives are clarified; output_tokens is named. Only 'calls' is listed without any explanation of its meaning or format.

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

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

The description names a specific verb and resource: 'Token & cost calculator' that estimates tokens and prices them across models. It is clear what the tool does, but it does not differentiate itself from close siblings like llm_pricing or dump_llm_pricing, which an agent must distinguish on its own.

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

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

It gives input paths ('pass a text' vs 'pass input_tokens/output_tokens'), which implies usage, but never states when this tool should be chosen over the pricing siblings. No exclusions or alternative-routing guidance is provided.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the critical non-obvious behavior that this is a paid tool ($0.02 USDC via x402) whose call returns payment requirements rather than data, requiring a second paid step. That two-phase payment flow and the cost are exactly the kind of behavioral detail an agent cannot infer from structured fields.

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

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

The paid cost and data scope are front-loaded, followed by filters and the payment mechanism. It is a single dense paragraph that is slightly run-on, but nearly every clause 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?

With no output schema and thin annotations, the description does the heavy lifting: it discloses the payment flow, the data fields returned (prices, context window, flags), the provider coverage, and all filter names. Only minor ambiguities (query semantics, unit conventions, response shape after payment) are left unstated.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it names all nine parameters (q, provider, free=yes, max_input_per_m, min_context, vision=yes, tools=yes, sort=input|output|context, limit<=100) with their enum values and the limit cap. Gaps remain: 'q' and the units of min_context/max_input_per_m are not spelled out.

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 (AI model list prices per 1M tokens, context window, capability flags) and scale (~3,000 models across named providers), so the agent knows exactly what data is behind it. It does not explicitly differentiate from siblings like llm_pricing_sample, llm_cost, or dump_llm_pricing, leaving some routing ambiguity.

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

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

The description explains the calling mechanism ('returns the exact HTTP request and x402 payment requirements; pay with any x402 client'), which is useful operational guidance. However, it never says when to prefer this paid tool over the free sample or llm_cost sibling, nor any exclusions.

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

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

No annotations exist, so the description must carry behavioral context; it usefully discloses cost (free), data provenance (LiteLLM table), license (MIT), and price unit. It does not state freshness, caching, or rate behavior, so it is helpful but incomplete for a tool with zero annotation coverage.

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

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

A single dense sentence, front-loaded with the free/cost qualifier and otherwise carrying only essential scope, unit, and provenance. No waste.

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

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

For a zero-param, read-only list tool with no output schema, the description supplies enough (model count, price unit, source) to call it correctly. Slightly more detail on return fields would make it airtight, but nothing critical 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?

Zero parameters, so per the rubric the baseline is 4; the description adds that prices are in USD per 1M tokens, which is useful framing but not a parameter concern.

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 ("List prices") plus scope ("five popular LLMs") and unit (USD per 1M tokens), which separates it from the likely full sibling llm_pricing and the llm_cost sibling. An agent can identify it as a lightweight pricing lookup 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?

"Free" and "sample" of only five models imply a cheap/quick first stop versus llm_pricing or llm_cost, but no alternative is named and no explicit when/when-not condition is given. Usage is inferable but 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the price ($0.02 USDC via x402), that invoking it returns an HTTP request plus x402 payment requirements rather than data, and that payment via any x402 client is required to actually get results. This is the kind of paid/two-phase behavior an agent cannot infer from structured fields.

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

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

Dense and front-loaded with the price and action, with no wasted prose. It loses a point only for restating enum values (cloud/local, python/typescript...) that the schema already declares.

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 explains both the payload (repo URL and description) and the payment round-trip. Only the undocumented limit parameter and the absence of a free-vs-paid sibling comparison leave minor 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 description coverage is 0%, so the description must carry the load, and it does for five of six parameters (q, category, language with example values, scope, official). The limit parameter is never explained, which is the only substantive gap.

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

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

States a specific verb (Search) and resource (MCP servers) plus the exact filter dimensions, and implicitly distinguishes itself from siblings like mcp_servers_sample and dump_mcp_servers by naming the full searchable corpus size (4,259). An agent can tell what this 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?

Usage is implied by the description of filters and the payment flow, but there is no explicit when-to-use guidance and no routing to the obvious alternatives (mcp_servers_sample, dump_mcp_servers) that a sibling-aware agent would want to weigh against paying $0.02.

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 two useful traits: cost ("Free") and licensing ("MIT source"). However, it says nothing about how the five are selected (first five, random, curated), the return format, or any pagination/rate behavior.

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

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

A single tight sentence with no filler, and the distinguishing constraint ("Five sample") appears early. It is arguably too terse rather than bloated, which is a completeness issue, not a conciseness one.

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 parameters, the description is the only documentation the agent gets. It omits the return shape, how the sample is chosen, and any relation to the full-directory siblings, leaving meaningful gaps for a tool whose entire value is its curated content.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds nothing parameter-related, but nothing is needed — there are no inputs to disambiguate and schema coverage is 100%.

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 identifies the resource (MCP servers) and the scope (five samples drawn from a 4,259-server directory), so an agent can guess what comes back. But it is a noun phrase with no action verb, and it never distinguishes itself from siblings mcp_servers or dump_mcp_servers. Purpose is inferable rather than stated.

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

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

There is no when-to-use guidance. The word "sample" faintly implies a preview, but the description never says to use this instead of mcp_servers when you only need a few examples, nor names any alternative. An agent must infer the tradeoff 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?

Beyond the annotations (readOnlyHint, openWorldHint), it discloses the exact cost ($0.03 USDC via x402), the fact that calling first returns the HTTP request and payment requirements rather than data, and that an x402 client is needed to complete payment. This two-step payment behavior is critical context the annotations cannot convey.

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

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

Front-loaded with the cost and payment model, then the audit scope, then the payment mechanics. Dense but every clause adds information about what is returned or how to invoke it; no filler.

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

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

With no output schema, the description usefully enumerates the returned fields and explains the payment flow, which is the key non-obvious behavior. The only meaningful omission is the format/validation expectations for the url argument.

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 carries the burden, and it never describes the single 'url' parameter's expected format or examples. The parameter name is self-evident in the context of a page audit, so the gap is minor, but no meaning is added beyond the schema.

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

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

The description states a specific verb+resource ('one-call page audit') and enumerates the exact scope: HTTP status, redirects, latency, meta tags, Open Graph, JSON-LD, headings, word count, plus agent-friendliness checks. This clearly differentiates it as a comprehensive audit, though it never names the siblings it overlaps with (page_meta, robots_check, page_markdown).

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 'for agents' and the enumerated outputs, and the payment flow tells the agent this is a paid tool that must be paid before data is returned. However, there is no explicit when-to-use guidance and no routing to cheaper siblings like page_meta or robots_check that cover subsets of the same data.

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

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

Annotations only cover readOnlyHint and openWorldHint; the description adds substantial behavior on top: the $0.03 USDC x402 price, that the call returns the HTTP request plus payment requirements rather than data, that robots.txt is respected, and the ~60k character ceiling. This is exactly the kind of non-obvious operational detail annotations cannot convey.

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

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

Two sentences, front-loaded with cost and action, with the output shape and limits packed efficiently. Slightly dense but no wasted clauses; the parenthetical field list earns its place by defining output fidelity.

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 one required param, no output schema, and only safety annotations, the agent still learns price, payment mechanics, content filtering, size limits, and robots compliance. The notable remaining gap is failure behavior for private/inaccessible pages or payment rejection, but the definition is otherwise sufficient to invoke correctly.

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

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

The single url parameter has 0% schema description coverage, so the description carries the burden. It does constrain the target to a 'public web page', implying a public http(s) URL, but adds nothing about format, redirect handling, or accessibility requirements. 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 verb and resource: convert a public web page to clean Markdown. It explicitly enumerates what survives and what is stripped (title, headings, paragraphs, lists, links, code; scripts/nav/footer removed), which cleanly separates it from siblings like page_meta, page_check, and robots_check.

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 'public web page' qualifier and the x402 payment note imply when it applies, and 'pay with any x402 client to get the data' gives a minimal how-to. However, it names no alternative tool and states no explicit when-not condition (e.g., non-public URLs, use robots_check first), so guidance stays implied rather than explicit.

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

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

Annotations already cover safety (readOnlyHint) and open-world scope, so the bar is lower. The description adds real behavioral context beyond them: a fixed $0.02 USDC cost, robots.txt compliance, and the non-obvious fact that the first call returns HTTP/payment requirements rather than data. It does not mention rate limits 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 tightly packed sentences with the capability and cost front-loaded and the unusual invocation flow placed second. Dense 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?

With no output schema, the description compensates by listing the returned fields (title, meta, canonical, OG/Twitter, language, headings, link counts, status). The payment handshake is also disclosed, which is essential to calling it successfully. Minor gap: no mention of error/blocked-page behavior.

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

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

Only one parameter, documented at 100% coverage in the schema ('absolute http(s) URL'). The description adds little beyond that, so baseline 3 is appropriate.

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

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

States a specific verb+resource ('Fetch a public web page') and enumerates the returned metadata fields, which differentiates it from siblings like page_markdown or page_check. It stops short of explicitly contrasting against those siblings, so it is clear but not fully self-locating.

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

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

The payment model and the robots.txt constraint imply when the tool applies, and the two-step x402 flow is explained. However, there is no explicit guidance on when to choose this over page_check, page_markdown, or link_check, leaving sibling selection to inference.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds critical behavior beyond that: the $0.01 USDC x402 cost, that calling it returns HTTP request plus payment requirements, and that an x402 client is needed to actually get data. That payment flow is material and normally would not be discoverable otherwise.

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

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

Four tight sentences with the cost and purpose front-loaded and no filler. It is on the dense side but every sentence (purpose, returns, payment mechanics) 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?

There is no output schema, and the description compensates by enumerating the return fields (allowed, matched rule, crawl-delay, sitemaps) plus the payment requirement. What remains unstated (rate limits, failure/error modes when robots.txt is absent) is minor.

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

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

Schema coverage is 100%, so both parameters (url, ua with default '*') are already documented in the schema. The description's 'for a given user-agent' aligns with the ua parameter but adds no syntax or format detail beyond it, 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 and resource: 'Check whether a URL may be crawled per the site's robots.txt for a given user-agent.' This is clearly distinct from siblings like link_check, page_check, and page_meta, which probe other aspects of a URL.

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

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

The description explains what the tool does but gives no when-to-use guidance, no exclusions, and no routing to alternatives among the many sibling tools. The agent must infer context from the purpose statement alone.

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

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

Annotations only cover readOnlyHint/openWorldHint, and the description adds substantial behavior beyond them: the tool is paid ($0.01 USDC via x402), the data provenance (nohumans.directory probes, verified/unverified), the license, and critically that a call returns payment requirements rather than data. This is exactly the extra context an agent needs before invoking a metered tool.

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

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

Front-loads the cost, then the resource, returned fields, filters, and call behavior in three dense sentences with no filler. Every clause earns its place and the most decision-relevant fact (the price) leads.

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

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

With no output schema, the description does explain the return shape (HTTP request + x402 payment requirements) and the payment model, so the agent knows what a call yields. The only gap is per-filter format detail, but overall it is complete enough for a paid search tool.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It enumerates all six filters (q, category, chain, max_price, status=verified, limit<=100) which maps to every property, but gives no per-parameter format or unit detail (e.g., how max_price is expressed, what q matches against), 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?

States a specific verb+resource: search ~8,900 live x402 pay-per-call APIs, and enumerates the returned fields (name, endpoint URL, category, price, chains, status, score). It is clearly distinguishable from a generic search, though it never names the adjacent sibling dump_x402_services, leaving a small ambiguity the agent must resolve from the name 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?

Explains the calling model well: invoking it 'returns the exact HTTP request and x402 payment requirements; pay with any x402 client to get the data,' so the agent understands this is a two-step paid flow. It gives clear context for when to use it, but states no exclusions or explicit alternatives among the many sibling catalog tools.

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