US Company Intelligence for AI Agents (SEC EDGAR, x402)

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

There are no annotations, so the description carries the full burden. It does a good job: it mentions that pages behind anti-bot/captcha/JS walls are refused before reasoning, and that the task fails explicitly if the model cannot answer from the document. It also discloses the payment model (paid per request, x402, $0.050000/call) and that a free quote endpoint exists. This is beyond what would be assumed for a multi-step tool.

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

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

The description is moderately concise but could be tightened. It front-loads the core purpose and usage, which is good. However, it includes some redundant phrasing ('Give an objective and a budget' is repeated) and the pricing detail might be better placed in annotations rather than the description. The structure is acceptable but not optimal.

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

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

For a tool with three parameters, no output schema, and no annotations, the description covers the main behavioral aspects: capabilities, verification, failure modes, and payment. The only missing piece is the 'source' parameter semantics, which is a clear gap. Despite that, the description provides enough for an agent to understand the tool's role and limitations, so it is relatively 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 explain all three parameters. It explains 'objective' and 'budget' in the prose, but 'source' is not mentioned at all. The description does not clarify what 'source' represents, whether it is optional, or how it interacts with the objective. This is a significant gap given the lack of schema descriptions.

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

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

The description clearly states what the tool does: it takes an objective and a budget, runs capabilities, verifies the result, and returns it with evidence. It distinguishes itself from siblings that perform single capabilities (like search_news or render) by emphasizing orchestration and verification. However, the exact scope of 'several capabilities' is only partially detailed (reading a web page, searching news, combined), so it is not fully precise about all possible use cases.

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

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

The description provides explicit guidance on when to use the tool, including example phrases like 'do this research task for me' and 'give me a verified answer within this budget'. It also contrasts with alternatives by noting that it combines capabilities, implying that for single operations (like just search or just read) other tools should be used. It could be stronger by explicitly naming sibling tools to use instead, but the context signals are sufficient.

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

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

With no annotations, the description carries the behavioral burden and does meaningful work: it discloses that requests exit through a residential IP with a real browser because Amazon rejects datacenter traffic, that calls are paid per request via x402, and that results return as structured data. It does not mention failure modes, rate limits, or locale behavior, but the core operational traits are surfaced.

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

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

The critical information is front-loaded, but the second sentence largely repeats the first: title, price, and availability appear twice before the additional fields of rating, review count, and main image are introduced. The trigger-phrase and pricing sentences add value, but the duplication makes the description longer than 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?

For a single-parameter tool with no output schema, the description covers purpose, use cases, cost, and network behavior. However, it leaves open the ASIN-vs-search-term ambiguity, does not specify which Amazon marketplace is queried, and gives no error or failure context, so it is not fully complete.

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

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

There is zero schema description coverage, so the description must explain parameters. It names ASIN as the identifier and suggests search terms are accepted, but the schema exposes only a required string 'asin' with no explanation of how search terms should be passed or whether they are actually supported. This mismatch leaves an agent uncertain how to satisfy the 'search term' 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?

The description opens with a specific action and resource: 'Get an Amazon product's title, price and availability' and later lists the full data payload: title, price, availability, rating, review count, and main image. It is unambiguous about the tool's purpose, though it does not explicitly contrast it with siblings like search or web_prices, and the 'by ASIN or search term' phrasing is slightly at odds with the schema's single required 'asin' parameter.

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

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

The description provides clear use-case guidance: price tracking, competitor monitoring, and listing verification, plus concrete trigger phrases such as 'search amazon for a product' and 'get the price of this amazon item'. It omits when-not-to-use guidance and does not name an alternative tool, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the data source (Apify's public store data), the outputs, the detection of broken/stale/deprecated actors, and the cost/payment method ($0.010000/call via x402 USDC). It does not explicitly state that the tool does not run the actor, but the framing 'before you pay to run it' and 'public store data' strongly implies a read-only analysis.

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 repeats the opening sentence nearly verbatim: 'Vet an Apify actor before you pay to run it: verdict, 0-100 score...' appears twice with slight variation. This duplication bloats the description and wastes tokens. The content is otherwise organized, but the redundant opening is a clear structural flaw.

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

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

For a single-parameter tool with no output schema and no annotations, the description covers the key operational details: what it returns, what data it uses, how much it costs, how to pay, and when to invoke it. It lacks an explicit statement that it does not execute the actor and could better define the actor parameter format, but overall it provides enough context for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'actor' parameter. It provides an example query (?actor=apify/instagram-scraper) which implies the expected format, but it does not explicitly define the identifier format or explain that it should be an Apify actor owner/name string. The example is helpful but not fully sufficient.

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

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

The description uses a specific verb ('Vet'), a clear resource ('Apify actor'), and enumerates the concrete outputs: verdict, 0-100 score, success/timeout rates, deprecation, users, rating, and pricing. This clearly distinguishes it from the sibling tools, none of which perform Apify actor preflight checks.

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

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

It explicitly states when to use the tool ('before you pay to run it') and provides three concrete trigger phrases: 'is this apify actor reliable', 'check an apify scraper before running it', 'apify actor success rate'. It does not mention exclusions or alternative tools, but the use cases are specific enough to guide an 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 zero annotations, the description carries the full burden and does substantial work: it discloses the per-call cost ($0.050000 via x402/USDC, paid per request), that fresh headlines are collected in one call, and that raw headlines are returned alongside the brief so claims can be verified. It truthfully flags the financial side of the operation, which no structured field conveys. It does not mention failure modes or rate limits, but for a no-annotation tool the disclosure is strong.

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 long but front-loaded with the core purpose and each sentence earns its place—output structure, verification capability, cost comparison, pricing, and trigger phrases. It could trim the cost/benefit framing toward the end, but nothing is repetitive or tautological; the density is justified by the number of facts it must convey.

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 is the only documentation, and it does describe the output shape (summary, key points each citing a numbered source, open questions) plus the raw-headline return. Yet the optional parameters gl and max_items remain undocumented, which is a meaningful completeness gap for a three-parameter tool. The brief's output description partially compensates for the missing output schema, but parameter coverage keeps it from being 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, but it only covers the required q parameter by implication ('Send a topic'). The optional gl (likely a country/language code) and max_items (item count limiter) are left completely unexplained anywhere—not in the schema, not in the description. This is a real usability gap for an agent choosing values for those parameters.

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

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

The opening sentence states a specific verb plus resource 'Get a short news briefing on a topic where each point cites its numbered source,' and the body details the return structure (summary, key points with cited sources, open questions). It distinguishes itself from sibling search tools by explicitly positioning it as a briefing that 'Replaces the two calls agents make today, a news search followed by a summarisation prompt,' so an agent can tell it apart from search_news and us_brief.

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

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

Gives concrete trigger phrases ('summarize today's headlines on x', 'brief me on the news about x', 'sourced news summary') and states it replaces a search-then-summarize sequence, giving clear context on when to reach for it. However, it never explicitly names sibling alternatives (us_brief, search_news) or states when NOT to use it, so exclusion guidance is left implicit rather than direct.

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 largely does so: it discloses cost ($0.005000/call, creation paid, receiving/reading free, x402/USDC payment), rate/volume limits (100 events, 64 KB each), and lifetime bounds (1-24 hours). Not stated: what happens to events after TTL expiry, long-poll timeout behavior, or whether creation and reading are the same invocation.

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?

Heavily duplicated: two near-identical opening sentences both defining the tool, and the pricing message appears three times ('Free to receive and read', 'Receiving and reading are free; only creation is paid', '$0.005000/call'). The redundancy buries the genuinely useful limits and pricing and hurts front-loading.

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

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

Covers what is captured, the limits, and the pricing for a tool with no annotations and no output schema, which is substantial. However, with no output schema it never explains how callback_url/events_url are surfaced to the caller or how the read step is invoked given only label/ttl_hours as inputs, leaving the core loop partially underspecified.

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 supply the meaning. The query example (?ttl_hours=24&label=job-42) combined with 'live 1 to 24 hours' implies ttl_hours is the lifetime in hours, but label is never explained and neither parameter is documented as optional/defaulted. Partial compensation, not full.

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 (a temporary public webhook URL) and the exact workflow: create it, hand callback_url to an external service, then long-poll events_url. It clearly distinguishes itself from siblings like sms_inbox by naming the capture scope (method, query, headers, body) and the intended 'agent without a server' use case.

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

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

Gives explicit trigger phrases ('temporary webhook url', 'receive a webhook without a server', 'request bin for my agent') and names concrete senders (payment processor, job runner, OAuth redirect, another agent). It stops short of naming when NOT to use it or which sibling to prefer for adjacent needs (e.g. sms_inbox).

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. It discloses the data source (Sourcify), the cost ($0.005000/call), the payment mechanism (x402/USDC), and the output contents (full ABI JSON). It does not explicitly state that it is read-only, but that is inherent to ABI queries. Overall, it provides meaningful behavioral context beyond typical descriptions.

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

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

The description is a single, information-dense sentence with a clear progression: what it returns, how to query, cost, and when to use. Each clause adds value, and it is front-loaded with the core purpose. It is concise but could be slightly more structured for readability.

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

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

Since there is no output schema, the description explains the return contents (function signatures, event names, contract name, compiler version, proxy implementations, full ABI JSON). It also covers cost, payment, and usage triggers. It does not discuss error cases or rate limits, but these are not critical for a simple ABI lookup 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 schema has 0% description coverage, and the description does not explicitly define the parameters. However, it provides an example query (address=0x8335…&chain_id=8453) and the phrase 'any EVM chain' implies address is the contract address and chain_id is the chain identifier. This adds some meaning but falls short of fully compensating for the missing schema documentation.

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

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

The description clearly identifies the tool as retrieving the verified ABI of a smart contract from Sourcify, listing specific contents (function signatures, event names, contract name, compiler version, proxy implementations, full ABI JSON). This distinguishes it from sibling blockchain tools like chain_balance or chain_tx.

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

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

It explicitly states when to use the tool with example user queries ('get the abi of this contract', 'verified contract abi', 'smart contract functions'), but does not mention alternatives or when not to use it. This 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?

With no annotations provided, the description carries the full burden and does a good job: it discloses the data source (Blockscout), first-page-only behavior with declared truncation, and the cost/payment mechanism ($0.005000/call via x402 USDC). It does not explicitly state read-only status or rate limits, but the query-oriented wording makes the operation clear.

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

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

The description is information-dense and front-loads the core purpose, then adds source, truncation, cost, and usage triggers. There is minor redundancy ('with x402 settlements identified' appears twice) and the 'truncation declared' phrasing is terse, but overall each sentence adds useful detail.

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

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

For a single-parameter query tool with no output schema, this description is quite complete: it names return aggregates (totals, distinct senders, last settlement time), price, payment method, data source, pagination limitation, and example user requests. The main gap is the missing token parameter in the schema and unclear next-page handling.

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, 'address', with no description, so 0% schema coverage. The description implies 'address' is the wallet to inspect, but it does not specify address format or validation, and it mentions a token query parameter ('?address=&token=') that is not present in the input schema, creating ambiguity about how to override the default USDC token.

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

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

The description clearly states a specific resource and action: USDC/ERC-20 transfers of an address on Base, both incoming and outgoing, with x402 settlements identified. It differentiates itself from siblings like chain_balance, chain_tx, and chain_allowance by focusing on address transfer history plus settlement metadata.

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

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

The description gives explicit trigger phrases: 'read the transaction history of this wallet', 'does this address receive payments', and 'usdc transfers of this address'. It provides clear when-to-use guidance, though it does not explicitly state when not to use it or mention alternative sibling tools.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses read-only get semantics, Base mainnet, USDC default, optional amount behavior, and $0.005/call x402 payment. It does not explicitly mention rate limits or authorization beyond payment.

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 main purpose is front-loaded and the query example plus trigger phrases are useful. The first two sentences repeat the same allowance/balance/verdict information, making the description slightly redundant, but overall it is reasonably concise.

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-parameter tool with no output schema, the description covers return components, optional amount behavior, network, payment, and usage examples. The token/schema mismatch and lack of error/response shape details leave minor gaps, but the core context is 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?

Schema description coverage is 0%, so the description must compensate. It adds a query format and clarifies that amount is optional and USDC is the default. However, it documents a 'token' query parameter that is absent from the input schema, which can mislead an agent about supported parameters.

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

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

The description uses a specific verb and resource: 'Get an ERC-20 allowance' with owner balance and sufficiency verdict. It also gives concrete trigger phrasings, which clearly distinguishes this from generic chain_balance or chain_token siblings.

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

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

It provides explicit trigger intents such as 'usdc allowance of a spender', 'is this approval sufficient', and 'check erc20 allowance on base'. It does not name alternatives or state when not to use the tool, so it falls 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?

With no annotations, the description carries the full burden. It discloses human-readable output, Base mainnet, and per-request payment via x402. However, it contradicts the input schema by describing a `tokens` query parameter that is not present in the schema—only `address` is accepted. This misleading claim undermines trust and is a significant transparency flaw.

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

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

The description is somewhat redundant—the opening sentence is nearly repeated with added detail (decimals resolved, human-readable). It mixes purpose, pricing, and usage examples in a slightly disjointed way, but it does front-load the core capability.

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 output schema, the description should explain return format but only says 'human-readable' without specifics (e.g., structure, units, token symbols). It also omits error handling, rate limits, and ignores the tokens parameter gap. For a paid read-only tool, the definition feels incomplete.

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 only schema parameter is `address`, and schema coverage is 0%. The description implies the address is a wallet address (via example URL) but doesn't explicitly define its format or that it's the target of the balance check. Worse, it mentions a `tokens` parameter that isn't in the schema, confusing parameter 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 clearly states the tool gets ETH, USDC, and up to ten ERC-20 balances for one address in a single call. It includes concrete example queries and distinguishes itself from sibling tools like chain_allowance and chain_token by scope and purpose.

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

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

Provides explicit 'Use when asked' triggers with three example natural-language queries, making it clear when to invoke. However, it does not mention when not to use it or suggest alternative tools for related tasks (e.g., allowances, token metadata), leaving some gray area.

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

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

With no annotations, the description carries the full burden and does it well: it discloses public RPC access, no API key requirement, per-call payment via x402, and the fact that there is no query. It also explains the practical meaning of age in seconds as a lag indicator for the node.

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 action and resource, and each segment is short. However, the first sentence and the field list repeat 'age in seconds, base fee and gas used', adding mild redundancy. Still compact and scannable.

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

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

For a zero-parameter public RPC query with no output schema, the description is complete: purpose, auth, cost, trigger phrases, and returned fields are all covered. An agent can decide when to call it and interpret the result without needing additional schema or annotation 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?

The input schema has zero properties and the description explicitly states 'Query: none', so there is no parameter ambiguity. The baseline for a zero-parameter tool is 4, and the description confirms rather than contradicts that.

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 ('Get the latest Base block') and enumerates the returned fields (number, hash, timestamp, age, base fee, gas used). The trigger phrases further distinguish it from sibling chain tools like chain_gas or chain_tx.

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

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

The description gives explicit use cases: 'latest block number on base', 'current block height', and 'what block is base at'. It does not mention when not to use the tool or name alternatives, so it stops short of a full when/when-not contract.

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 discloses meaningful behavior: bidirectional resolution, avatar inclusion when set, payment model ($0.005/call via x402 USDC). It doesn't detail failure/edge cases or output shape, but for a simple resolution tool it is substantially transparent.

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

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

Two focused sentences with purpose, examples, pricing, and use triggers. Slightly dense but no filler; the only structural issue is the unresolved `?address` reference.

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

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

The description covers purpose, usage, and cost, but the missing address parameter in the schema, lack of any output contract, and no edge-case notes leave an agent guessing about behavior when a name/address isn't found. Adequate but not 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% and the only parameter `name` has no schema description. The description shows `?name=vitalik.eth` but also introduces `?address=0xd8dA…`, an input that isn't represented in the input schema, making it unclear how an agent should pass an address. This is a 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?

Description states exactly what the tool does: 'ENS name resolution in both directions' (name→address, address→primary name), including avatar. Uses a specific verb and resource, and differentiates the two call modes clearly.

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

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

Explicitly provides natural-language triggers ('Use when asked: ...'), which is solid guidance. It doesn't name alternatives or exclusions, but the stated use cases are enough to route an agent for common ENS requests.

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 behavioral burden. It discloses the pricing model ($0.005000/call), the payment mechanism (x402 USDC), and the specific output fields returned. It implies a read-only query operation through 'Get' and 'Query: none'. This is meaningful beyond 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?

The description is front-loaded with the main purpose, but the first two sentences largely repeat the same information ('ETH, ERC-20 or x402 USDC transfer' and later 'an ETH transfer, an ERC-20 transfer and an x402 USDC settlement'). The content is useful but could be trimmed to avoid redundancy.

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

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

For a zero-parameter tool with no output schema or annotations, the description covers the expected return values, pricing, payment method, and example queries. The only minor omission is explicit statement that this is read-only and non-destructive, but 'Get' and the described outputs strongly imply 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?

The input schema is empty with 100% coverage, so the description only needs to confirm there are no parameters. It does so explicitly with 'Query: none', and the rest of the description explains what is being fetched. Baseline 4 is appropriate for a zero-parameter tool.

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

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

States a specific verb ('Get') and resource ('current Base gas price' and transfer costs), and lists the exact outputs: gas price, base fee, priority fee, and ETH costs for ETH, ERC-20, and x402 USDC transfers. This clearly distinguishes it from sibling chain tools like chain_balance or chain_tx.

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

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

Provides explicit trigger phrases: 'gas price on base', 'how much does a usdc transfer cost on base', 'current base fee'. It also clarifies that no query parameters are needed. It does not explicitly compare to alternatives, but the zero-parameter design and specific domain make the usage context clear.

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

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

No annotations are provided, so the description carries the full burden. It mentions the cost ($0.005000/call) and payment via x402, which is useful. However, it does not disclose potential failure modes (e.g., unknown tokens, errors on non-ERC20 addresses) or any side effects, leaving a gap for a read-only tool without annotations.

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

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

The description is a bit repetitive (the first sentence is almost duplicated), but it is relatively concise and front-loads what the tool returns. The redundancy costs a point, but the overall structure is clear.

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

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

Given the tool's simplicity (one param, no output schema), the description covers the essential use cases and response fields. It lacks a mention of error handling or edge cases, but for a straightforward metadata lookup, it is adequate.

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 only one parameter (address) with zero coverage, but the description explicitly indicates the address format (?address=0x…) and its purpose. This adds some clarity but could be improved by specifying the expected format (e.g., checksummed) or examples.

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

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

The description clearly states the tool retrieves ERC-20 metadata from Base, listing the specific fields (name, symbol, decimals, total supply, holder count, contract type, USD rate). It is distinct from sibling tools like chain_balance and chain_tx. The purpose is unambiguous and easily differentiable.

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

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

The description provides clear example queries ('what is this token address', 'erc20 metadata on base') and specifies the input format (?address=0x…). However, it does not explicitly state when NOT to use it or mention alternative tools for non-ERC20 queries, which would strengthen the 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 burden. It discloses that this is a paid per-request call via x402 (USDC), which is important behavioral context. However, it does not mention failure modes, rate limits, or what happens for invalid/nonexistent hashes. The description does not contradict any annotations (none exist), so a 3 is appropriate.

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

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

The description is compact and front-loaded with the core purpose, then adds the query format, pricing, and example use cases. It is slightly dense with repeated phrasing ('every ERC-20 transfer inside it' appears twice), but each sentence earns its place and the structure is logical.

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

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

For a single-parameter tool with no output schema, the description covers the essential context: what it returns (status, block, from, to, value, fee, method, decoded ERC-20 transfers), how to call it, and when to use it. It lacks explicit return-format details (e.g., JSON shape), but the description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 0% and the schema only says 'hash' is a required string. The description compensates by specifying the expected format: '?hash=0x…' and clarifying it is a Base transaction hash. It could add more detail (e.g., whether it accepts ENS names or only hex), but it provides meaningful meaning beyond the bare 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 ('Get'), a specific resource ('a transaction's status, parties, fee and every ERC-20 transfer inside it'), and a specific chain ('Base'). It also gives concrete query examples and distinguishes itself from sibling chain_* tools by focusing on transaction-level decoding rather than address/block/balance data.

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

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

The description explicitly lists trigger phrases: 'did this transaction succeed', 'transaction receipt on base', 'decode this tx hash'. It also specifies the query format (?hash=0x…) and pricing model (x402 USDC per call). This gives an agent clear when-to-use guidance and distinguishes it from siblings like chain_block or chain_address.

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 guarantees that labels outside the supplied list are never returned and that every label is checked against the user's list. It also discloses pricing and the x402/USDC payment mechanism, which is valuable operational context, but says nothing about latency, rate limits, or failure behavior.

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

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

Content is front-loaded, but the constraints are stated at least twice ('2 to 12 supplied labels to each of up to 20 short messages' then again as 'up to 20 messages and 2 to 12 labels per call') and the guarantee is repeated ('labels outside the supplied list are never returned' / 'never invented'). The inline 'Body:' JSON is awkwardly spliced mid-paragraph, reducing clarity.

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 tool with no output schema, the description covers what the tool does, its hard constraints, example inputs, use cases, and cost. Only the return shape beyond 'label + confidence' and any error/permission conditions are left implicit, which is acceptable given the absence of an 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% and the schema types are uninformative (both params typed as plain strings), so the description must compensate. It does: it names both parameters, specifies ranges (2–12 labels, up to 20 messages), and provides a JSON body example showing array structure and the message/label pairing.

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+scope: assign 2–12 supplied labels to up to 20 short messages, one label each, with a confidence. It is easy to distinguish from siblings like llm, extract, or understand because the label-constraint and per-message cardinality 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?

It gives concrete trigger phrases ('classify these messages', 'route tickets to the right team') and named use cases (ticket triage, intent routing, topic tagging, sentiment buckets). It does not state when NOT to use it or point to an alternative (e.g., llm for open-ended generation), so it falls short of a 5.

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

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

With no annotations, the description carries the behavioral load well: it discloses the data source (OKX), a hard limit (up to 10 coins), and crucially the cost model ($0.005000/call, paid per request via x402/USDC), which an agent needs for decision-making. It does not mention auth, rate limits, or failure modes, keeping it short of a 5.

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

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

The opening sentence is a truncated duplicate of the immediately following full sentence ('Live perpetual futures funding rates for up to 10 coins from OKX: rate, annualized rate, which side pays, interval, next funding time and bounds'), which is pure redundancy and wastes space. The rest is front-loaded and efficient, but the duplication is a clear structural flaw.

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 a commendable job of enumerating return fields (rate, annualized rate, side paying, interval, next funding time, bounds), stating the source and coin limit, and giving usage triggers. Only minor gaps (no error/permission notes) remain for a read-only 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 description coverage is 0% and the single 'symbols' param has no schema description, so the description must compensate. It does so by showing the query format (?symbols=BTC,ETH,SOL) and stating the 'up to 10 coins' limit, adding real meaning beyond the bare string-typed schema property.

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: funding rates for perpetual futures from OKX, with a clear list of the values returned (rate, annualized rate, which side pays, interval, next funding time, bounds). This is distinguishable from siblings like crypto_market and token_price-history, which cover price/market rather than funding rates.

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

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

Provides concrete trigger phrases ('btc funding rate', 'eth perpetual funding rate', 'are longs paying shorts') that map directly to the tool's domain. It gives clear context for when to use it but names no alternative sibling or exclusion, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden, and it delivers the key non-obvious behavioral fact: this is a paid call at $0.005000 per request via x402/USDC. That cost/payment disclosure is exactly the kind of trait annotations would normally supply. It still omits return format, latency, or caching behavior, keeping it below 5.

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

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

The description repeats itself almost verbatim: the first sentence and 'Global crypto market snapshot in one call...' restate the same metric list at nearly equal length. That duplication consumes roughly half the text without adding information, though the trigger phrases and pricing are front-loaded and useful.

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, no-output-schema tool, the description adequately covers what comes back (the enumerated metrics) and the cost model. Only the redundant phrasing and the absence of any note on response shape or freshness keep it short of 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, which is the baseline-4 case; there is nothing to disambiguate. The description's statement that there is no query ('Query: none') usefully confirms the no-argument contract rather than leaving it implicit.

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 ('Global crypto market snapshot') and enumerates exactly the aggregate metrics returned (market cap, 24h change, volume, BTC dominance, stablecoin supply/share, asset count, ATH distance). This clearly distinguishes it from asset-level siblings like chain_token, stablecoins, and token_price-history.

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

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

Provides explicit trigger phrases ('total crypto market cap today', 'bitcoin dominance', 'crypto market overview') that map user intent to this tool, which is strong context. It does not, however, name an alternative or a when-not-to-use condition (e.g., vs. stablecoins for stablecoin-specific queries).

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does well: it reveals deduplication, newest-first sorting, the return fields, per-call pricing via x402 (USDC), and the query format. It does not discuss rate limits, auth requirements, or edge cases around pagination, but the core behavioral traits are clearly disclosed. No annotation contradiction exists.

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

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

The description is compact and front-loaded: what the tool does, the sources, the output fields, the dedup/sort behavior, then filters, pricing, and usage triggers. Every sentence adds distinct value, and the example query is a useful illustration rather than filler. It earns its length with no redundancy.

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

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

For a simple two-parameter tool with no output schema, the description is nearly complete: it explains the data sources, return fields, ordering, deduplication, keyword filter, example request, pricing, and typical use cases. Small gaps remain around the required-vs-optional status of q, whether limit has a maximum or default, and any absence of pagination. These are minor for an aggregator of this scope.

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 adds meaning by calling q a "keyword filter" and providing an example query (?q=bitcoin etf&limit=20), which clarifies both parameters. However, it calls the filter "optional" while the schema lists q as required, creating ambiguity. It also doesn't explain limit semantics (max results, page size, default). Partial compensation with a notable gap.

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

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

The description states a specific action and resource: aggregating crypto and blockchain news from four named newsrooms (Cointelegraph, Decrypt, The Block, CoinDesk) in one call. It uniquely distinguishes itself from general search tools like search_news by naming exact sources, output fields, and dedup/sort behavior. An agent can immediately know what this tool returns and when it applies.

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

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

The description explicitly provides usage triggers with example phrasings: "Use when asked: 'latest crypto news', 'bitcoin news today', 'crypto headlines'." It gives clear context for when this tool is the right choice, though it does not name sibling alternatives (like search_news) or state when not to use it. This is strong guidance but stops short of explicit exclusions or alternative routing.

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

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

With no annotations, the description carries the behavioral disclosure burden. It states this is a read operation ('Read from our infrastructure'), lists all returned data categories, and discloses cost and payment method via x402. It does not cover failure modes or edge cases like unreachable domains, but the disclosed behavior is substantially richer than a bare mutation or fetch description.

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

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

The description is front-loaded with the core purpose, followed by a compact enumerated list of checks, then cost and use-case phrases. It is slightly repetitive (domain health, one call on a domain, query ?domain=) but remains organized and reasonably sized for the amount of information conveyed.

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

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

The tool has no output schema, so the description must explain what the agent will receive; it lists categories but not structure or interpretation guidance. It also omits error behavior, timeout expectations, or how to judge 'trustworthy' from the returned data. For a tool with one simple parameter and a well-listed output scope, it is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'One call on a domain' and 'Query: ?domain=', confirming that the only parameter is the domain to check. However, it does not specify the expected format (e.g., bare domain vs. protocol, punycode, trailing dot), leaving some ambiguity for correct invocation.

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

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

The description opens with a specific verb and resource ('Check whether a domain is reachable and healthy') and then enumerates exactly what is checked: DNS records, TLS certificate, redirect chain, and security headers. This clearly distinguishes it from sibling tools and leaves no ambiguity about what domain_health 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?

The description gives explicit trigger phrases ('check whether this domain is healthy', 'is this domain trustworthy', 'check dns records and ssl of a domain') that tell an agent when to invoke it. It does not mention when not to use it or name alternatives, but the context is clear enough for 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 burden of behavioral disclosure, and it does so well: it states that no message is sent, that it does not open an SMTP session, that mailbox existence is explicitly not checked, and that output is NO, RISKY, or LIKELY. It also discloses the cost model, which is useful operational behavior beyond 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?

The description is information-dense and front-loaded with the core purpose. Every clause adds value, including the cost and usage triggers. The only slight redundancy is 'and says so' after 'It does not open an SMTP session,' which could be trimmed without losing meaning.

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

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

For a single-parameter tool with no annotations and no output schema, this description is complete: it covers input, output categories, core limitations, usage timing, query format, and cost. An agent has enough to select the tool, format the call, and interpret the outcome.

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 only declares an 'email' string with no description, so the tool description must compensate. It adds that the query parameter is '?email=' and clarifies that the input is an email address being verified. It could have added URL-encoding guidance or explicitly stated that email is required, but the single simple parameter is largely well-addressed.

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

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

The description opens with a clear verb and resource: 'Check whether an email address is well-formed and its domain can receive mail.' It then enumerates the concrete checks performed (syntax, MX, SPF, DMARC, disposable domain, role address), which fully distinguishes this tool from the sibling list where no other tool targets email deliverability.

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

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

It explicitly says when to use the tool: 'before you send' and gives exact trigger phrases such as 'verify this email address' and 'is this email deliverable.' It also states a clear exclusion by noting that mailbox existence is not checked and no SMTP session is opened, so an agent will know not to use this when mailbox validation is required.

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

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

No annotations are provided, so the description carries the burden. It clearly discloses that this is a paid per-request API call ($0.01/call via x402), which is a critical behavioral trait. It also states that one call checks the official ESMA register, implying a read-only lookup. It does not mention rate limits, failure modes, or what happens for unregistered firms, but the paid-call disclosure and register source are meaningful transparency.

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

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

The description is dense but efficient: it front-loads the purpose, lists outputs, gives query examples, and states pricing and trigger phrases in a compact block. It is slightly long but every sentence adds value. The only minor issue is the LEI example referencing a parameter not present in the 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 single-parameter lookup tool with no output schema, the description is quite complete: it names the register, the input format, the output fields, and the cost. It does not describe the response structure or error behavior for unregistered firms, but the listed output fields give an agent enough to set expectations. The missing LEI parameter in the schema is the main 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% and the schema only has a required 'name' string with no description. The tool description compensates by explaining that 'name' can be a company name or an LEI, and gives concrete examples (?name=Bitpanda or ?lei=...). However, the schema only defines 'name', so the LEI example implies a parameter that is not in the schema; this is a minor inconsistency but the description still adds essential meaning.

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

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

The description opens with a direct question and states the exact resource: the official ESMA register of crypto-asset service providers. It names the query parameters (company name or LEI) and lists the specific outputs (authorised status, home member state, competent authority, authorisation date, services, passporting countries). This clearly distinguishes it from generic crypto or company lookup tools in the sibling list.

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

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

The description gives explicit example queries and quotes natural-language triggers like 'is this crypto exchange licensed in the eu' and 'mica authorisation check'. It also states the payment model (x402, USDC per call), which is essential for an agent deciding whether to invoke a paid tool. This is strong usage 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 burden of behavioral disclosure. It discloses the French residential IP, real Chromium browser, JavaScript rendering, datacenter-block bypass, and the per-call x402 payment model—all useful context for the agent. It does not mention failure modes or timeouts, but for a simple read-only fetch this is fairly complete.

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 first two sentences repeat the same idea: 'Read the main content... as clean markdown' and 'receive the main content of the page as clean markdown'. The pricing and trigger examples add value, but the redundancy makes the description less tight than it could be.

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

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

For a one-parameter tool with no output schema, the description covers purpose, behavior, pricing, and usage triggers. It gives an agent everything needed to select and invoke the tool correctly. Minor gaps like failure behavior are acceptable given the tool's simplicity.

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

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

The input schema has a single `url` property with no description (0% coverage), so the description must compensate. It says 'Send a URL and receive the main content' and the trigger phrases imply the parameter is the target webpage URL. It does not specify URL format or constraints, but with one obvious parameter the meaning is adequately conveyed.

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

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

The description opens with 'Read the main content of a page your own crawler cannot reach, as clean markdown,' giving a specific verb, resource, and output format. This differentiates it from siblings like render, screenshot, and extract-structured by emphasizing markdown output and full JavaScript rendering. The purpose is unmistakable.

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

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

The description explicitly lists trigger phrases: 'retrieve this webpage', 'extract this page', 'get the content from this URL', and states the distinguishing condition 'your own crawler cannot reach'. However, it does not name alternative tools or say when not to use them, so it falls just short of a 5.

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

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

With no annotations provided, the description carries the full burden, and it delivers: determinism ('no model runs in this path, so two calls on the same page return the same verification'), explicit limitations ('does not bypass CAPTCHA or authentication'), pricing ('$0.020000/call, paid per request via x402'), and the disclosure that 'Failed checks are DECLARED alongside the content, never hidden.' It also enumerates what evidence is returned (timestamp, final URL, counts, sha256 checksum), far exceeding minimum behavioral 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?

The purpose is front-loaded in the first sentence, and nearly every subsequent sentence earns its place (checks performed, determinism, non-bypass caveat, price, trigger phrases). It is dense, with one long enumerative sentence in the middle, but that density supplies critical trust-relevant detail. Slightly more line-breaking or shorter clauses would push it to 5.

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

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

For a single-parameter tool with no annotations and no output schema, the description is remarkably complete: it covers the verdict concept, evidence contents, pricing/payment, determinism guarantees, and failure-handling behavior. It falls short of 5 only in not describing the exact shape of the verdict value (e.g., the enumerations of the trust decision) and not spelling out network-failure behavior beyond blocking detection.

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 indirectly: 'Read a page', 'browser-based web content retrieval', and 'final URL after redirects' make it clear the url parameter is a web page to be fetched and verified. It adds meaning beyond the bare 'url: string' schema by conveying redirect handling, blocking detection, and CAPTCHA/auth limits tied to that URL. It is not a full 5 because it never explicitly states url format requirements or what kinds of URLs are unsupported.

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

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

The opening states a specific verb, resource, and outcome: 'Read a page and get a deterministic verdict on whether the retrieval can be trusted, with evidence.' It explicitly differentiates from its closest sibling by noting 'Same retrieval as POST /v1/extract ($0.005), plus what an agent needs to trust the result without re-fetching it,' so an agent can separate it from extract, render, and screenshot. The value proposition (verification with evidence) is unique and clear.

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

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

It gives explicit trigger phrases: 'Use when asked: "read this page with proof", "was this page blocked", "verified page retrieval".' It also implicitly routes price-sensitive agents by contrasting with the cheaper extract endpoint. It stops short of a full 5 because it never explicitly says 'use extract instead when no proof is needed' and doesn't address sibling alternatives beyond extract.

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 entire burden of disclosing behavior. It reveals that this is a 'lite' and 'cheap' operation, states the exact cost ($0.010000/call) and payment method (x402 USDC), and clarifies it's sufficient for 'screening a shortlist of addresses' before committing to depth. It does not explicitly state read-only semantics, but the analysis nature implies a non-destructive read. Minor gaps are the lack of error behavior or rate limits, but the scope and limitations are well communicated.

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 moderately sized but well structured: primary purpose is front-loaded, followed by capabilities, upgrade path, pricing, and usage examples. There is slight redundancy (mentioning price per square metre twice), but each sentence adds value—pricing, upgrade guidance, and trigger phrases are all actionable. It avoids fluff and stays focused on what the agent needs to invoke it correctly.

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

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

For a tool with 2 params, 0% schema coverage, and no output schema, the description is reasonably complete about return contents (price, value, score) and upgrade options. However, it omits critical details: the meaning of 'surface', any address formatting requirements, and whether certain inputs are invalid (e.g., non-French addresses). It also doesn't explain what 'recent sales' means (timeframe, count). This leaves the agent guessing on parameters, so completeness is only partial.

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 'adresse' parameter implicitly ('around a French address'), but it never mentions or defines the 'surface' parameter at all, leaving its purpose and format unclear. There is no description of expected address format (e.g., street number, postal code) or how surface correlates to the output. This is a significant deficiency given both parameters are otherwise 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?

The description opens with a clear verb-resource pair: 'Get price per square metre and recent sales around a French address.' It then enumerates exactly what the tool returns (median price per sqm, estimated value, investment score), which is specific and distinguishes it from the full-fledged sibling 'fr_analyse-immo' by labeling itself as the 'Lite' version for cheap screening.

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

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

Provides explicit when-to-use triggers in quoted natural language examples ('price per square metre at this address', 'recent sales around this french address', 'property snapshot in france'). It also gives an explicit when-not-to-use condition by directing the agent to upgrade to '/v1/fr/analyse-immo' for energy performance, environmental risks, demographics, and rental yield. This routing is clear and actionable.

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

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

With no annotations, the description carries the full burden. It discloses the tool assembles data from official registries and returns a structured file, implying a read-only operation. However, it does not explicitly state the lack of side effects, mention rate limits, authentication, or potential failure modes. For a simple retrieval tool, this is adequate but not rich.

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 well-structured and front-loaded with the main purpose, followed by return value, pricing, and usage examples. It is somewhat verbose with the pricing and example phrases, but each element adds value. It earns a 4 because it is efficient without being terse.

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

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

The tool has one opaque parameter, no output schema, and no annotations. The description explains the content of the dossier and the return concept ('structured file') but does not specify the output format or the exact input expectations. This leaves some ambiguity, making it only moderately complete for an agent 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 input schema has only one parameter 'q' with zero description coverage. The description does not define 'q' directly; it only implies via the usage example 'compliance dossier by siren' that q might be a SIREN number. Since schema_coverage is 0%, the description must compensate, but it does not clearly explain the parameter's format, required value, or examples. This is a significant 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 clearly states a specific verb and resource: assembling a know-your-business dossier on a French company from official registries, listing concrete data points (legal identity, directors, BODACC insolvency). It is clear about the purpose but does not explicitly differentiate from siblings like fr_kyb_partial or fr_entreprise-360, so it lacks the sibling distinction that would earn 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 provides explicit usage context with example queries ('know your business dossier on a french company', 'kyb for onboarding a french supplier', 'compliance dossier by siren'). This gives clear conditions for when to use the tool, but it does not mention alternatives or when not to use it, so it stops short of a 5.

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

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

Discloses the pricing ($0.010000/call, paid via x402 USDC) and the fact it's a paid per-request call, which is behavioral context beyond the schema. It also specifies the data source (official BODACC court announcements), which signals reliability. However, it doesn't clarify whether the synthetic status is always returned even when no proceedings exist, or whether the history is empty in that case. No annotations are provided, so the description carries the burden — it does reasonably well but leaves edge-case behavior unstated.

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

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

The description is compact and front-loaded: starts with a pithy question, then the returns, then the data source, then pricing, then trigger phrases. Every sentence adds value. Minor deductions for the pricing detour in the middle which could be cleaner as an annotation, but it's still appropriately concise overall.

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 an output-free schema, the description covers: what it does, what it returns, where data comes from, and when to use it. It's incomplete only regarding the unambiguous identification of what SIREN means (which is domain knowledge) and edge-case behavior with no proceedings. With no output schema, the agent needs the description to explain returns, which it does well.

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

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

The single parameter 'siren' is a well-known French business identifier (SIREN number) used contextually in the description's trigger phrases ('for a siren'). While the schema provides no description (0% coverage), the tool name 'fr_procedures-collectives' and the description's trigger phrases imply the siren is a French company identifier. However, the description does not explicitly state what format the siren must be (9 digits, etc.) or that it's the official French business registry number. Given a single parameter, the baseline of 4 for 0-param tools doesn't apply; a 3 reflects that the description leverages domain knowledge but doesn't document the parameter 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?

States a clear purpose: checks if a French company is in insolvency proceedings, and explicitly enumerates the returns: synthetic status, full history of court judgments (safeguard, receivership, liquidation), and a registry deregistration flag, sourced from official BODACC court announcements. The verb 'Returns' with the resource 'official BODACC court announcements' is specific and unambiguous, and the answer is directly routed away from siblings like fr_bilans and fr_score-entreprise.

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

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

Provides explicit query phrase examples: 'is this french company insolvent', 'insolvency proceedings for a siren', 'bankruptcy check on a french company'. This gives the agent clear trigger conditions. However, it doesn't explicitly name sibling alternatives or state when NOT to use this tool (e.g., vs fr_bilans for financial statements), but the trigger examples are sufficiently strong for correct routing.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: data provenance (ECB official rates), coverage limits, and an unusual cost/payment model ($0.005000/call, paid per request via x402 USDC), which the agent must know before calling. It omits response shape and failure/latency behavior.

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

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

The opening sentence is duplicated almost verbatim ('Official ECB foreign exchange reference rates for about 30 currencies... from any base...'), wasting roughly half the text. The example query and triggers are front-loaded, but the redundancy is a clear structural defect.

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

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

For a 2-param tool with no annotations and no output schema, the description covers source, scope, pricing, example, and triggers, but leaves return-format unaddressed and introduces a schema/description mismatch around date and amount, so an agent cannot fully predict call semantics.

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 clarifies that `symbols` is a comma-separated list (EUR,GBP,JPY) and `base` is a base currency, which adds value. However, its example URL includes `date` and `amount` parameters that do not exist in the schema at all, which risks misleading the agent about available 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 resource (official ECB foreign exchange reference rates), its scope (~30 currencies, any date since 1999, any base, optional amount conversion), and thereby separates itself from siblings like crypto_market or token_price-history, which cover different asset classes.

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

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

Provides concrete when-to-use triggers via quoted user phrasings ("exchange rate usd to eur", "convert 100 dollars to euros", "historical forex rate on a date"). It doesn't name an explicit alternative tool or state when not to use it, but the invocation context is clear.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that it uses BAN for France and OSM elsewhere, and mentions cost and payment via x402. However, it doesn't describe the output format, error handling, rate limits, or authentication requirements. For a geocoding tool, response structure and failure behavior are important, so this is a notable gap.

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

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

The description is front-loaded with the core purpose, then provides details, an example, cost, and usage triggers. It's information-dense but well-organized. No wasted words, though it could be slightly more concise by removing the redundant second sentence that repeats the BAN/OSM split.

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

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

The description covers the main purpose, service selection, cost, and usage triggers. However, it lacks details on the response format (what the coordinates look like, whether INSEE code is always included), error handling, and rate limits. The undocumented 'country' and 'limit' parameters in the example also create ambiguity. For a simple tool with no output schema, this is incomplete but not severely so.

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 explains that 'q' is the address query and gives an example. However, the example includes 'country' and 'limit' parameters that are NOT in the input schema, which could mislead an agent into thinking those are valid parameters. This introduces confusion and undermines the semantic clarity of the single documented parameter.

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

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

The description clearly states the tool's function: turning an address into coordinates, with specific details for France (BAN registry) and elsewhere (OpenStreetMap). It distinguishes itself from siblings like geo_reverse by explicitly mentioning forward geocoding and even provides example query phrasing. The verb 'turn' and resource (BAN/OSM) are specific and unambiguous.

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

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

The description provides explicit usage triggers: 'coordinates of this address', 'geocode this address', 'latitude and longitude of a french address'. It also mentions cost and payment method, which helps the agent decide if it's appropriate. However, it doesn't mention alternatives like geo_reverse or when NOT to use this tool, so it's not fully explicit about 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 are provided, so the description must carry this burden. It does disclose cost per call, payment via x402/USDC, and provider routing (BAN in France, Nominatim/OpenStreetMap elsewhere), which is useful. However, it does not mention response format, error behavior, rate limits, or coordinate validation, leaving gaps for a no-annotation tool.

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

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

The description is compact and front-loaded with purpose, followed by pricing and usage examples. There is some redundancy between the first two sentences, both describing the nearest-address behavior with slightly different provider labeling, but the text remains short and scannable.

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

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

For a two-parameter reverse-geocoding tool, the description covers purpose, provider behavior, cost, and example queries. However, with no output schema and no annotations, it omits the expected return shape and any failure/edge-case context, making it only moderately complete for an agent deciding whether and how to call it.

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

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

Schema coverage is 0% for the lat/lon parameters, so the description must provide meaning. It does by showing the query format '?lat=48.8698&lon=2.3310' and describing them as coordinates. It does not specify ranges, precision, or required units beyond the example, so it only partially compensates for the missing schema coverage.

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

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

The description states a specific action and resource: 'Turn coordinates into the nearest postal address', with a clear reverse-geocoding scope. It also distinguishes provider behavior by region and includes query examples that make the purpose unmistakable relative to tools like geo_forward.

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

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

The description gives explicit use triggers such as 'address at these coordinates', 'reverse geocode lat lon', and 'what address is at 48.85, 2.35'. It does not explicitly contrast with geo_forward or state when not to use this tool, but the provided trigger phrases are actionable.

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 largely delivers: it discloses output format (base64 data URL), dimensions, latency, model, cost per call, payment rail (x402/USDC), and the optional seed for reproducibility. It doesn't cover failure modes or content restrictions, but the core behavioral profile is clear.

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

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

The description is front-loaded and informative, but the first two sentences repeat '1024x1024' and 'about four seconds', which is redundant. It could be tightened without losing 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, no-output-schema tool, this is very complete: it covers input, output, cost, payment method, latency, and usage triggers. The only omissions are edge-case behaviors, which are minor at 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?

The schema only lists 'prompt' with no description, and coverage is 0%, so the description must compensate. It explains that prompt is a text prompt and adds an optional 'seed' parameter for reproducible output, plus the expected body shape. However, 'seed' is not present in the input schema, creating a minor mismatch that could confuse strict schema-validating agents.

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

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

The description opens with a precise verb-object pair ('Turn a text prompt into a 1024x1024 JPEG'), names the model (FLUX.1 schnell), and lists concrete use cases, making the tool unmistakable among the large sibling set. It doesn't explicitly contrast with sibling tools like 'render' or 'screenshot', but the specificity is enough to identify it.

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

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

It gives explicit trigger phrases ('Use when asked: "generate an image of a cat"...') and states the payment model, so an agent knows when to select it. It does not mention when not to use it or name alternative image-generation routes, so it stops short of a full 5.

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

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

With no annotations provided, the description carries the full burden. It discloses pricing ($0.010000/call), auth-free access, model (DeepSeek v4), output limit (2000 tokens), and payment method (USDC via x402). It does not cover error handling or rate limits, but the core behavioral traits are well documented.

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 detailed but efficiently organized, front-loading the core purpose and then adding pricing, tier, and usage guidance. It is slightly long but every sentence contributes relevant information, and the structure is logical.

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

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

Given the simple one-parameter schema and absence of output schema, the description is largely complete. It covers cost, authentication, limitations, and usage scenarios. It omits error behavior and potential failure cases, but for a straightforward inference call, the provided context is adequate.

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 only one parameter 'prompt' with 0% description coverage. The description mentions 'prompt' in the body but adds no semantic detail beyond naming it. It also introduces optional fields (system, max_tokens) not present in the schema, which could confuse an agent. The description does not meaningfully explain the parameter's meaning or constraints.

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

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

The description clearly states the action: 'Get a short completion from a capable model' with specifics (paid per call, 2000 tokens). It explicitly distinguishes itself from the sibling 'llm_pro' by naming the PRO tier and its larger output budget, making the purpose unambiguous.

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

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

Provides explicit usage triggers: 'Use when asked: "complete this prompt", "short completion from a model", "cheap llm call".' It also names the alternative llm_pro for larger outputs, giving clear direction on when to choose which 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. It discloses the output budget (8000 tokens), the payment requirement (per request via x402/USDC), and the behavioral contrast with the cheaper route (truncation). It doesn't mention rate limits or error behavior, but for a simple inference call, the key traits are covered.

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

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

The description is information-dense but has some redundancy: the first sentence and the second sentence both state the same engine and output budget. However, the structure is logical, front-loading the purpose and then adding usage triggers and pricing. It's not overly long and every sentence contributes value.

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 LLM tool with one required parameter, the description is quite complete. It covers the input body, output budget, pricing, and usage triggers. It doesn't explicitly state the return format (e.g., a string), but that's implied for an LLM completion. Given the absence of an output schema, this is 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?

The schema only lists 'prompt' with no description, so coverage is 0%. The description compensates fully by specifying the body structure: {prompt, system?, max_tokens?} and explaining that max_tokens can go up to 8000. This adds critical meaning beyond the schema and tells the agent exactly what parameters are accepted.

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

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

The description clearly states the tool provides long completions with a large output budget, explicitly contrasting with the standard /v1/llm engine. It names the resource (LLM inference) and the differentiator (four times larger output budget, up to 8000 tokens), making it easy to distinguish from the sibling 'llm' tool.

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

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

The description gives explicit trigger phrases ('long completion with a large output', 'write a long answer to this prompt', 'generate up to 8000 tokens') and clarifies when this tool is appropriate (when the cheap route truncates). It also mentions the payment method (x402/USDC) which is a practical consideration. This is excellent guidance for an 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?

No annotations are provided, so the description must carry the full burden. It discloses cost per call and payment method (x402 USDC), which is valuable. However, it does not explicitly state read-only behavior, rate limits, or error handling, leaving some 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 informative but not excessively long. It front-loads the main purpose, then provides output fields, pricing, and usage examples. Each sentence adds value, though the example URL could be trimmed.

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

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

For a 2-param tool with no output schema, it covers the purpose, parameters, pricing, and suggested triggers. However, the q/sources inconsistency creates ambiguity, and the response format is only partially described (fields listed but no types or examples), leaving room for confusion.

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 explains q as a keyword filter and limit as a count, and gives an example URL. However, it calls q 'optional' even though it is required, and introduces a 'sources' parameter not present in the schema, which can mislead 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 clearly states the tool opens prediction markets from Polymarket and Kalshi, lists the returned fields (question, probabilities, volume, liquidity, closing time, link), and is distinct from all sibling tools, which cover unrelated domains.

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 provides explicit trigger phrases and a query example, making it clear when to use the tool. It does not mention exclusions or alternatives, but there are no close sibling tools that compete with this functionality.

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 correctly carries the behavioral burden: it discloses real Chromium rendering, a French residential IP exit, JavaScript execution before printing, and the archival nature of the output. It does not discuss limitations like login-protected pages or blocked sites, but the disclosed behavior is substantial and 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?

The main action is front-loaded and the rest proceeds logically: rendering behavior, use case, pricing, and trigger phrases. There is minor redundancy in repeating 'PDF document' and some stylistic expansion, but every sentence contributes useful information and the length feels appropriate.

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 and no annotations, the description covers the core action, key behavior, representative use cases, cost, and invocation phrases. It could mention limitations or required URL characteristics, but the tool is simple enough that the description 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?

The schema has a single 'url' string parameter with zero description coverage, and the description only says 'Send a URL' without adding constraints such as HTTPS, public reachability, or URL encoding expectations. This is acceptable for one obvious parameter, but it does not fully compensate for the missing schema metadata, especially since 'required parameters' is reported as 0.

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

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

The description opens with a specific verb and resource: 'Turn a web page into a PDF document.' It makes clear that the input is a URL and the output is a PDF rendered in a real Chromium browser. However, it never explicitly differentiates itself from similar sibling tools like render or screenshot, though the PDF focus implicitly narrows the scope.

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 offers explicit trigger phrases and use cases: 'Use when asked: convert this page to pdf', and frames the tool as useful for archivable, shareable records like quotations or legal notices. It does not mention when not to use it or name alternatives, so it falls short of the full 5.

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

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

With no annotations to help, the description carries the full burden and does so thoroughly: it discloses delivery key format, 30-day validity, metering, pricing, the real FTTH exit, geolocation database disagreement, pre-sale probing, and the no-charge guarantee if no live exit is verified.

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 and front-loaded, but the first two sentences repeat the 1 GB/30-day facts, and the final marketing sentence is slightly expendable. Overall, the length is justified by the detail.

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

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

Even without an output schema, the description explains the returned artifact's format, payment method, validity, usage, and geographic properties. An agent has enough context to know when to call and what to 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 input schema has zero parameters, so the baseline is 4. No parameter explanation is needed; the description appropriately focuses on what the user receives rather than 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?

Opens with a specific verb and resource: 'Get a working HTTP/HTTPS proxy... with 1 GB of traffic, valid 30 days.' It clearly defines what is being sold and implicitly distinguishes from proxy_5gb/proxy_20gb by specifying the 1 GB tier and Caribbean residential exit.

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?

Ends with explicit trigger phrases: 'Use when asked: "residential proxy, pay per gb", "get a residential ip for my agent", "http proxy with a french home ip"'. This is strong, but it does not explicitly rule out or route to sibling proxy sizes.

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 so richly. It discloses geolocation ambiguity across databases rather than picking a flattering result, explains pre-sale live probing of reachability/blacklist status, states the buyer is not charged if no verified exit exists, and details the no-account, metered payment model. This goes well beyond the bare product claim.

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 thorough but redundant: the first two sentences both state 20 GB, 2.60 USD per GB, one key, and 30-day validity. It is organized and densely informative, but could be tightened without losing value. A few sentences also drift into marketing language ('the best rate in the range').

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 no parameters, the description is unusually complete: it covers the product specs, price, validity, network and reverse-DNS details, geolocation caveat, verification guarantee, refund/charge condition, intended use case, and payment mechanism. An agent has enough context to decide whether this tool matches the requested proxy package.

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

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

The tool has zero parameters and the schema already makes that explicit, so the baseline is 4. The description adds product-level context—pricing, validity, delivery as a key—but there are no parameter semantics to clarify, so it neither gains nor loses much 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?

The description states a specific verb and resource: 'Buy 20 GB of French West Indies residential proxy bandwidth' delivered as a proxy key. It also distinguishes this tool from siblings like proxy_1gb and proxy_5gb by specifying the 20 GB size, 'the best rate in the range', and the use case of 'large proxy package for crawling'.

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

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

The description gives explicit usage context: 'Designed for agents running long crawling campaigns or continuous monitoring' and provides trigger phrases like 'residential proxy 20 gb' and 'bulk residential proxy bandwidth'. It does not explicitly name alternatives or say when not to use it, but the use-case framing is clear enough to route an 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 disclosure burden and exceeds it. It reveals the exit is a real FTTH home line on a specific AS (AS20776, Outremer Telecom / SFR Caraibe), names the reverse DNS pattern, admits geolocation inconsistency across databases, states reachability/blacklist probing happens before each sale, and guarantees 'If no exit is verified live you are not charged.' Pricing and payment via x402 are also explicit. No annotations exist to contradict this.

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

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

The core purpose is front-loaded in the first sentence, and the rest expands with useful details. However, the first two sentences repeat essentially the same information twice ('Same residential exit... with 5 GB...' followed by 'Buy 5 GB... and receive a proxy key...'), which is redundant. All other sentences earn their place (exit details, geolocation caveat, pricing comparison, use case, trigger phrases), so this is only slightly redundant, not bloated.

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 purchase tool with no output schema and no annotations, the description must explain inputs, outputs, and failure modes. It explains the input implicitly (none needed), the output as 'a proxy key valid for 30 days', the cost, and a failure guarantee ('If no exit is verified live you are not charged'). It doesn't specify the exact format of the returned key or how the key is communicated, but the mention of x402 and 'paid per request' gives enough operational context. This is nearly complete; the only gap is precise response shape.

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

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

The input schema is empty (0 parameters), so the baseline is 4. The description does not describe parameters because there are none; instead it explains what the purchase yields (5 GB, one key, 30-day validity, price) and the process ('paid per request via x402'). It adds all meaning beyond the empty schema, fully compensating for the absence of structured fields.

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 immediately states the verb and resource: 'Buy 5 GB of French West Indies residential proxy bandwidth... and receive a proxy key valid for 30 days.' It also explicitly references sibling proxy_1gb ('Same residential exit as /v1/proxy/1gb'), distinguishing by size (5 GB vs 1 GB) while confirming the same exit. The purpose is unmistakable even without the title.

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

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

The description provides clear usage context: 'Suited to agents running sustained crawling or data-collection jobs where a datacenter IP would be blocked on the first request.' It also gives explicit trigger phrases ('Use when asked: ...'). However, it never directly compares with proxy_1gb or proxy_20gb in terms of when to choose this over them, though the 'Same residential exit as /v1/proxy/1gb' line implies a size-based choice. The absence of an explicit 'use this instead of X for Y' instruction prevents a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so well: 30-day lifetime, unguessable URL, blocked scripts/forms/external requests, 200 KB size cap, no search-engine indexing, and per-call pricing via x402 (USDC). 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?

The core facts are front-loaded, but the opening sentence is a compressed version of the second sentence and is then repeated almost verbatim, wasting budget without adding information. Substance is good; editing is loose.

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

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

For a no-output-schema tool the agent still learns the return shape (a URL), the lifetime, the size limit, the safety profile, and the billing model, so nothing needed to call it correctly is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does with a concrete body example naming all three keys and grounds semantics for html (200 KB static markup) and ttl_days (up to 30 days). 'title' is shown but never explained, which keeps this below 5.

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 (host/publish a generated HTML page) plus the concrete output (a shareable URL anyone can open). It is clearly distinguishable from siblings like render or screenshot, which produce artifacts rather than hosted share links.

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

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

Gives explicit trigger phrases ('host html page', 'publish html to a url', 'share link for a generated report'), which is strong positive guidance. It does not, however, state when not to use it or name an alternative sibling, so it falls short of a full 5.

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

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

With no annotations present, the description carries the behavioral burden. It discloses that a real Chromium instance on a French residential IP executes JavaScript, resolves SPAs, and bypasses datacenter-range blocks. It also reveals per-call cost and payment method, which is important operational context. It does not mention failure modes or limits, but the coverage is strong.

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

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

The purpose is front-loaded and the content is generally compact, but the first two sentences are redundant: both say the tool returns full HTML after JavaScript execution. The pricing and trigger phrases add value, but the repetition could be trimmed without losing 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 single-parameter tool with no output schema, the description is mostly complete: it explains what is returned, how the request is executed, when to use it, and what it costs. It stops short of describing the exact return format or possible failure conditions, but the core invocation context is well 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?

Schema description coverage is 0%, so the description must compensate. It does say "Send a URL" and implies the url parameter is the page to render, but it adds little beyond the schema property name. It does not clarify URL format, required protocols, or encoding requirements.

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: "Get the full HTML of a page after its JavaScript has run." It clearly distinguishes this from sibling tools like screenshot (returns an image) and extract (returns structured data) by promising raw post-JS HTML. The trigger phrases at the end reinforce exactly what the tool is for.

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

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

The description gives clear usage context with explicit caller phrasings: "render this page", "get the html after javascript", "fetch the DOM of this page". It explains when rendering is valuable (SPAs, datacenter-blocking defenses) but does not name alternatives or state when not to use it.

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

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

With no annotations provided, the description carries the full burden. It reveals that the tool uses OpenStreetMap data worldwide, returns total and per-leg stats, and supports GeoJSON or polyline geometry. It also discloses the pricing ($0.005/call via x402 USDC), which is useful. However, it doesn't specify potential failure modes, such as what happens if stops are invalid or unreachable, or whether it returns raw JSON vs. processed output. A 3 is fair because it adds key context but misses edge-case behavior.

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

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

The first sentence is dense and informative, but the description repeats itself almost verbatim in the second line, which is redundant. The redundant repetition wastes space. However, the query example and usage phrases are helpful and justify the length. It could be tightened by removing the duplicate 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?

Given the tool has only two parameters and no output schema, the description covers essential usage: input format, mode options, output types, data source, and a query example. It also includes pricing and usage cues. Missing is a note on return format (e.g., JSON structure) but likely the agent can infer from the example. Overall, it's almost complete for a simple routing API.

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 explain both parameters. It clearly explains the 'stops' parameter with a concrete example format ('16.2411,-61.5331|15.9985,-61.7261') and states the 'mode' parameter options ('car, bike or on foot'). This compensates well for the lack of schema documentation, though it doesn't explicitly enumerate all allowed mode values or default behavior.

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

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

The description clearly states the tool computes point-to-point directions for 2-10 stops by car, bike, or foot, with specific output details (distance, time, snapped stops, geometry formats). It distinguishes itself from siblings like geo_forward and geo_reverse, which are geocoding tools, by specifying the routing use case.

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

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

The description explicitly provides example queries and usage trigger phrases ('driving directions from a to b', 'walking route between two points'), which gives clear guidance on when to use this tool. However, it does not explicitly state when not to use it or alternatives, but the usage phrases are sufficient for most agents.

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 full responsibility for behavioral disclosure. It reveals use of a real Chromium browser, a French residential egress IP, JavaScript execution, lazy-loaded content resolution, and per-call pricing via x402. It doesn't cover error scenarios or blocked pages, but the disclosure is substantial and non-misleading.

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 opens with the core action and adds behavioral details, use cases, pricing, and trigger phrases. Some redundancy exists (e.g., 'fully rendered page' appears twice), but overall the text is tightly packed and every sentence contributes practical value.

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

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

The description covers behavior, output format, and business context well, but it is incomplete because it omits any explanation of the 'fullPage' parameter. With no output schema or annotations, the description is the sole source for parameter semantics, and this omission prevents an agent from fully understanding how to control the capture.

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

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

The schema has 0% description coverage, so the description must compensate. It explains the URL input only implicitly ('Send a URL') and completely ignores the 'fullPage' boolean parameter, leaving its meaning and effect undocumented. This is a significant gap given the schema itself provides no parameter descriptions.

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

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

The description states a specific action and resource ('Capture a PNG of a page as it renders') and clearly explains the output. It does not explicitly distinguish itself from sibling tools like 'render', so it lacks the full sibling-differentiation evidence for 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 provides concrete use cases (verify a page visually, archive evidence, hand to a vision model) and trigger phrases ('screenshot this page', etc.). It gives clear context for when to use the tool but does not mention when not to use it or name alternatives, stopping short of a 5.

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

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

With no annotations provided, the description carries full behavioral burden. It discloses that this is 'Real Google web search' and enumerates output components (top 10 organic results, answer box, knowledge graph). It also notes the pricing model and payment method. However, it does not mention rate limits, auth requirements, or behavior around edge cases (e.g., empty results), leaving room for improvement.

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

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

The description is compact and front-loads the core action. It mixes useful details (result contents, trigger phrases) with moderately relevant metadata (tier, cost, payment). The structure is clear, though the pricing/payment line could be considered secondary information for a tool selector.

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?

This is a simple single-parameter tool with no output schema, so the description does well to explain both input semantics ('For a query') and expected output ('top 10 organic results, answer box and knowledge graph'). It also provides pricing context and usage triggers. Missing details like return field structure or optional gl/hl handling are minor for such a straightforward tool.

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

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

The input schema has 0% description coverage, so the description must compensate. It indicates that 'q' is the query text via the phrase 'Query: ?q=&gl=&hl=—', which adds some meaning. Yet it also introduces gl and hl as possible parameters without explaining them, and these are absent from the schema. The description clarifies the primary parameter but leaves ambiguity about the others.

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

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

The description opens with a specific verb and resource: 'Get ranked web results for a query.' It further clarifies scope with 'top 10 organic results, answer box and knowledge graph, in one call,' which distinguishes it from sibling tools like search_news, search_sources, and social_search.

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

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

The description provides explicit trigger phrases: 'Use when asked: "search the web for x", "look up pages about a topic", "google this for me".' It does not explicitly name alternatives or when-not-to-use cases, but the usage context is clear and specific for 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?

Since no annotations are provided, the description carries the full burden. It discloses that this is a paid call (via x402, USDC) and mentions the cost per request, which is critical behavioral context. It also indicates real-time news retrieval, but doesn't detail potential rate limits, error behavior, or data freshness guarantees beyond 'fresh'.

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

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

The description is compact and efficient, packing purpose, usage examples, pricing, and routing hints into a few sentences. It is front-loaded with the core benefit, making it easy to scan.

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

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

For a single-parameter tool with no output schema, the description provides sufficient context: what it does, when to use it, and cost. It lacks details on output format or limitations, but given the simplicity, it covers the essentials well. The paid nature is disclosed, which is often missed.

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 only one parameter 'q' with no description, and schema coverage is 0%. The description hints at query parameters like ?q=&gl=&hl=, implying 'q' is the search query, but doesn't explicitly define 'q' or the optional gl/hl parameters. It adds some value by showing the query format, but not enough to fully compensate for the schema 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 clearly states the tool's purpose: fetching fresh headlines with source and age, specifically news about a topic. It names the underlying source (Google News via Serper) and distinguishes itself from the generic 'search' sibling by emphasizing freshness and news-specific 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?

The description provides explicit usage examples ("news about this company", "find recent news about x") and mentions it's for crypto/market/current-events agents. It doesn't explicitly state when NOT to use it versus siblings like 'search' or 'search_sources', but the context is clear enough.

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

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

With no annotations, the description carries the burden and does substantial work: failure representation (ok:false, never hidden), technique (residential IP, real browser), no synthesis/no model, and cost/payment via x402 USDC. It lacks latency or pagination details, but provides strong expectation-setting.

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 purpose with clear separation of behavior, failure mode, body shape, pricing, and usage triggers. Some redundancy ('in one call' twice) and promotional phrasing slightly reduce density.

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 tool with no annotations and no output schema, it covers the request body, pricing, failure behavior, and typical user intents. The undefined top/max_chars semantics and the schema/body mismatch prevent a 5.

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 document parameters, but it only restates body keys {q, top?, max_chars?} and leaves top and max_chars undefined. It also introduces max_chars in the body while the schema omits it, creating ambiguity about valid 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 compound action: search a topic and get full content of best pages in one call. It clearly distinguishes from siblings like search, extract, and understand by noting real web search, residential IP, real browser reading, and no synthesis/model.

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

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

Gives explicit invocation triggers ('Use when asked: ...') and signals exclusion of synthesis/model, which steers agents away from analytic tools. Does not explicitly name alternative tools or state when not to use it, so not a 5.

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

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

With no annotations, the description carries the full burden and does well: it states read-only checks, a synchronous single call, and the $1.000000/call x402 (USDC) payment model. What it does not disclose is failure behavior, timeouts, or whether the paid call is refunded on error.

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 report contents are stated twice — first as a summary ('21 read-only checks ... a prioritized fix list and a markdown report') and again as a full enumeration — and the 21 checks are effectively listed twice by pillar and by name. The redundancy costs a tight tool definition.

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 only one parameter, the description adequately covers what the tool checks and returns. It is missing only error/failure semantics, which is a minor gap given the rest of the 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% and the single required 'url' parameter has no description in the schema. The description partially compensates with the 'Query: ?url=https://example.com' example, but never states format constraints, normalization, or whether a scheme is required.

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 (agent readiness report for a website) and enumerates exactly what the 21 checks cover and what is returned. It is clearly distinguishable from siblings like x402_inspect or domain_health.

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

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

Provides explicit trigger phrases ('is this website ready for ai agents', 'can ai agents buy on my website'), which is strong when-to-use guidance. It does not name alternative tools or state when not to use it, so it falls short of a 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure and does reasonably well: it states the read-only nature, the structured return format, the physical SIM behavior, and the per-call cost paid via x402. It does not mention rate limits, error conditions, or authentication details, but it covers the most decision-relevant traits.

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

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

The definition is front-loaded with the core action and return fields, then gives relevant context about the physical SIM and pricing, ending with explicit use-case phrases. It is slightly dense but every major clause earns its place; 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 simple two-parameter read tool with no output schema, the description provides enough orientation: what it does, what data it returns, why it works (physical SIM), how it is paid for, and when to invoke it. The main omission is the 'since' parameter, which prevents it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter definitions. It clarifies that 'phone' refers to the number rented through /v1/sms/number, but it never explains the optional 'since' parameter (format, semantics, or filtering behavior). An agent can guess at 'phone' but has no guidance for 'since'.

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

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

The description opens with a specific action and resource: reading messages received by a phone number rented through /v1/sms/number, and lists the returned fields (sender, body, reception time). This clearly separates sms_inbox from the sibling sms_number tool, which is about renting the number rather than reading its messages.

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 supplies concrete trigger phrases ('read the sms received on my rented number', 'get the otp that was sent to this number', 'inbox of a rented phone number'), making it clear when an agent should select this tool. It does not explicitly state when not to use it or point to an alternative, so it misses the full exclusion 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 provided, the description carries the full burden of behavioral disclosure. It transparently explains that the number is a physical SIM passing carrier checks, returns a number and session identifier, and directs to sms_inbox for reading messages. It also discloses pricing and payment method. However, it does not mention rental duration, number availability limitations, or potential failure modes, which would add further transparency.

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

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

The description is a single paragraph that front-loads the core purpose and then adds practical details (physical SIM, return values, pricing, usage examples). Every sentence contributes value—no filler. It is slightly longer than strictly necessary, but the density of useful information justifies the length.

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

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

For a tool with no parameters and no output schema, the description is quite complete: it explains what the tool does, what it returns, how to read messages, and gives usage examples. It does not cover edge cases like number unavailability or rental duration, but these are minor for a simple rent-and-receive operation. The description provides enough for an agent to call it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics because there are none, but it does explain what the tool returns (number and session identifier) and how to use it, which is sufficient for a parameterless tool. The schema coverage is trivially 100%, and the description adds context beyond the empty schema.

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

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

The description states a specific verb and resource: 'Rent a real mobile phone number to receive an SMS or a one-time password.' It clearly distinguishes the tool from virtual/VoIP lines by emphasizing the physical SIM, which differentiates it from similar verification tools. The purpose is unambiguous and immediately actionable.

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

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

The description provides explicit usage triggers ('Use when asked: ...') and states the intended context ('For agents that must complete a phone verification step autonomously'). It also references the companion tool sms_inbox for reading messages, but does not explicitly contrast with alternatives like email_verify or other verification methods. The guidance is clear but lacks explicit 'when not to use' exclusions.

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

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

With no annotations provided, the description carries the full burden of disclosure. It covers no-key access, per-call pricing ($0.02), x402 payment method, merged source behavior, and the returned fields. It could add error/rate-limit details, but it is not misleading and is reasonably transparent.

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

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

The description is informative but repetitive: the first two sentences restate nearly the same information about what is searched and returned. The query-string example and pricing are useful but could be more tightly organized. It is not egregiously long, but it does not front-load everything efficiently.

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 4-parameter tool with no annotations and no output schema, the description covers the purpose, params, return fields, excluded sources, cost, and downstream thread use. It does not describe response structure precisely, but it gives enough context for an agent to invoke and interpret the result correctly.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains q as query, sort as relevance/new/top, t as time window, and limit as a numeric cap on results, and even includes the query string format. Exact allowed values for t are not spelled out, but enough meaning is added beyond the bare 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 clearly states a specific action ('Search Hacker News and Lemmy posts') and the output scope ('score, comments, permalink and excerpt'). It distinguishes itself from siblings like social_thread by noting the ids are ready for /v1/social/thread, and explicitly names excluded sources (Reddit, Twitter, Bluesky).

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

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

Provides explicit trigger phrases like 'what do people say about x' and 'search hacker news for x', plus clear exclusions ('Reddit, Twitter and Bluesky are not served'). It does not name alternative sibling tools, but the guidance is strong enough for an agent to route appropriately.

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 discloses the output contents (post text, flattened comments with depth, score, author), the query format, and the pay-per-call x402/USDC pricing. It does not address error cases, rate limits, or the precise meaning of limit, leaving part of the behavioral burden unmet.

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 first two sentences restate nearly the same content, with only 'author' and the id formats added later. Useful context (example query, pricing, trigger phrases) is front-loaded to a degree, but the redundancy makes it less crisp than it could be.

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

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

In the absence of an output schema, the description does clarify the return shape at a high level (post text and flattened comments with depth/score/author). It does not explain flattening, limit behavior, or bad-id behavior, which are notable gaps for a tool with no structured schema help.

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 needs to carry parameter meaning. It usefully shows id as hn:<id> or lemmy:<id> and gives the concrete ?id=hn:49806046&limit=50 example, but it never defines what limit controls, its default, or bounds.

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

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

The opening line names an exact resource and action: get one Hacker News or Lemmy thread, with post text and flattened comments. The id scheme (hn:<id> or lemmy:<id>) and the canonical user phrasings clearly distinguish it from search-oriented siblings like social_search.

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

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

It gives explicit trigger phrases ('read this hacker news thread', 'comments of this discussion', 'get the thread by id') and states that IDs come from /v1/social/search. It does not explicitly exclude search tasks or name social_search as the alternative, so it stops short of a 5.

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

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

With no annotations, the description carries the transparency burden and largely meets it: it discloses provider ranking by 'expected net margin and observed success rate,' fallback 'to the next provider on failure,' and the return of 'the result with the routing it used.' It also surfaces pricing and payment ('$0.050000/call, paid per request via x402 (USDC)') and a preview path for seeing the plan and price before paying. It does not spell out what happens if all providers fail, but the execution profile is unusually clear.

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

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

The description is front-loaded with purpose and then walks through routing behavior, companion endpoints, pricing, and use triggers in a logical order. There is some redundancy ('Send a task in plain words' appears twice, and 'One endpoint for any capability' restates the first sentence), but the overall length is justified for a generic router with no annotations. Every block adds useful context.

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 router with no output schema and no annotations, this is quite complete: input mode, provider ranking, fallback, returned routing info, cost, preview endpoint, capability discovery, and usage triggers are all present. The main gaps are the lack of an all-providers-failed behavior and the mismatch between the optional 'task' in the schema and the description's assumption that a task is sent. These are minor relative to the wealth of operational 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?

The single 'task' parameter has zero schema description, so the text must supply the meaning, and it does: 'a task in plain words' or 'name a capability and its input.' It explains that the gateway resolves the capability, normalizes input via preview, and accepts plain-language requests. It stops short of giving an exact syntax or example for naming a capability with input, and it does not address the schema's optionality, but the semantics are usable.

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

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

The description clearly states the core action: 'Send a task in plain words and let the router pick and run the right capability,' making both the verb and the resource explicit. It also differentiates itself from the long sibling list by positioning itself as a gateway: 'One endpoint for any capability' and 'the gateway resolves which capability is needed.' The 'Use when' phrases sharpen the purpose for an agent.

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

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

The description gives explicit invocation triggers: 'Use when asked: "which capability should handle this", "solve this task", "route this request".' It also points to useful alternatives: POST /v1/solve/preview for planning, pricing, and direct-route comparisons, and GET /v1/capabilities for discovering what can be solved. It does not explicitly say when to favor a known direct sibling tool over solve, so it falls just short of complete when/when-not guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose useful traits: per-request pricing ($0.005000/call), the x402 USDC payment mechanism, and that depegged coins are flagged. It omits error behavior (e.g., unknown symbol) and any return-shape or pagination expectations, so meaningful gaps remain.

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 opening clause 'Stablecoin market in one route: ...' and the three data modes are stated twice, with the first pass adding essentially nothing before the richer second pass. Use cases and pricing are front-loaded toward the end rather than leading. Roughly a third of the text is redundant.

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

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

No annotations and no output schema, so the description must carry everything; it covers modes, parameters, cost, payment, and trigger phrases. An agent has enough to invoke it correctly, though the always-required symbol for non-peg views remains unaddressed.

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

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

Schema coverage is 0% and neither parameter has an enum, so the description is the only source of meaning. It supplies the valid view values (overview, peg, chains) and demonstrates symbol usage via symbol=USDC, which compensates well. It does not explain why symbol is required even for the overview and chains views, which is a residual ambiguity.

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 (stablecoin market data) and enumerates three distinct modes: top coins by supply, peg health for one coin, and supply per blockchain. An agent can distinguish it from siblings like crypto_market or token_price-history. It stops short of an explicit sibling comparison, but the verb/resource pairing 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?

Offers concrete trigger phrases ('is usdc still pegged', 'top stablecoins by market cap', 'stablecoin supply per chain') that map directly to the view modes. It states when each view applies (overview / peg+symbol / chains) but never names an alternative tool or a when-not condition.

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 critical non-obvious trait: paid per request at $0.005000/call via x402 (USDC). It also sketches the return shape. It omits auth/failure behavior beyond payment and says nothing about rate limits or data freshness/update cadence.

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 opening two sentences are near-verbatim duplicates ('Token price history in USD ... CoinGecko id or chain:address ... time series with change %, high and low, or the price at an exact past date'), so a large fraction of the text is pure redundancy. The useful front-load (resource + identifier forms) is buried under the 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?

Given no annotations, no output schema, and 0% schema coverage, the description does supply cost, identifier formats, day range, examples, and return shape. But the mismatch between the advertised 'at'/'period' query params and the two-parameter schema (coin, days only, both required strings) leaves an agent unsure how the 'exact past date' mode is actually invoked.

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 both params, so the description must compensate: it does add real meaning (coin accepts CoinGecko id or chain:address; days spans 1-365). But the worked examples reference 'period' and 'at' parameters that do not exist in the schema, which muddies rather than clarifies parameter usage instead of a clean, schema-consistent mapping.

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 (token price history in USD) and its two identifier forms (CoinGecko id or chain:address), plus the scope of the series (1-365 days) and the two output shapes (time series with change %/high/low, or price at an exact date). This distinguishes it from siblings like crypto_market, chain_token, and stablecoins without needing to open a schema.

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

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

Provides concrete trigger phrases ('ethereum price over the last 30 days', 'bitcoin price on january 1 2025', 'token price change this week') and worked query strings, which is clear positive routing guidance. However it names no alternative sibling or when-not condition (e.g., vs crypto_market for current spot price), so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and discloses substantial behavioral context: the exact data sources (DexScreener, Blockscout, GoPlus, honeypot.is), the computed outputs, and crucially the cost model ($0.010000/call, paid via x402/USDC). It does not explicitly state read-only or side-effect-free behavior, but the nature of the tool implies a read operation.

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 repetitive and poorly structured: the opening phrase is a sentence fragment that is immediately restated in a fuller sentence, and there is a missing period between the two. The result is a run-on that buries key details like usage examples and 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?

Given the absence of an output schema and annotations, the description does a thorough job of listing the outputs (grade, risk score, flags, market data, holder info) and the cost/payment mechanism. It is nearly complete, missing only explicit error or rate-limit 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 0%, so the description must compensate. It explains that 'tokenAddress' is the contract address and gives a format example ('0x...'), which is helpful. However, it also mentions a 'requestKey' parameter in the example body that does not exist in the input schema, creating a mismatch that could confuse an agent about required 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: 'Risk verdict on a Base token' and enumerates exactly what it returns (grade, 0-100 risk score, flags, etc.). This clearly distinguishes it from sibling tools like chain_token or token_price-history, which do not offer composite risk verdicts.

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

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

Provides explicit example user questions ('is this token a scam', 'rug check this contract address', 'honeypot check on base') that map directly to the tool. No when-not-to-use guidance or named alternatives are given, but the context is clear enough for an agent to select it.

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

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

There are no annotations, so the description carries the full burden, and it delivers: it discloses that audio is download-and-run through speech recognition, works without subtitles, works on platforms with no caption tracks, runs from a residential IP to bypass source restrictions, returns full text plus sentence-level timestamps, and includes pricing and payment method. This is unusually transparent.

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

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

Every sentence adds distinct value: model and mechanism, contrast with alternatives, network behavior, return payload, cost/payment, and trigger examples. The description is front-loaded with the core purpose and remains appropriately sized for the amount of unique behavioral information it conveys.

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 annotations and no output schema, the description is mostly complete: it covers input, method, supported sources, output, and commercial terms. Minor gaps remain, such as failure behavior for private/protected videos or video length limits, but nothing an agent needs to make an initial correct call 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 0% schema description coverage)Skip, the description must compensate for the single url parameter. It explains that the URL must be for a YouTube, TikTok, or Instagram video and implies a direct video URL rather than a channel or playlist. It could specify public/accessibility requirements, but it gives enough context for correct invocation.

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

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

The description opens with a specific verb and resource: 'Transcribe the actual audio of a YouTube, TikTok or Instagram video with Whisper large-v3.' It clearly distinguishes itself from caption scraping and names the video platforms it supports, so an agent can tell it apart from siblings like extract or understand immediately.

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

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

It gives explicit trigger phrases: 'Use when asked: "transcribe this youtube video", "get the transcript of this tiktok", "speech to text from a video URL".' It also explicitly states what it is not for by contrasting with caption scraping, leaving no ambiguity about when to select it.

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

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

With no annotations provided, the description carries the full burden and succeeds. It discloses fetching from a residential IP, anti-bot/error-page checks, the context-window strategy, response contents (source extracts and list of checks), and the failure behavior ('a failed verification returns no answer rather than a confident wrong one'). Pricing and payment method are also stated.

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

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

The core function is front-loaded in the first sentence, followed by technical process, failure behavior, cost, and trigger phrases. There is minor redundancy between the first two sentences ('Ask a question...' and 'Give a web page and a question...'), but the remaining content generally 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 no annotations, yet the description tells an agent what inputs to provide, how the tool behaves internally, what response to expect (verified answer plus extracts and checks), what happens on verification failure, and how payment works. Nothing essential is missing for correct invocation.

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

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

The schema contains only bare string properties with 0% description coverage, so the description must compensate. It does so by mapping 'source' to 'a web page' and 'objective' to 'a question', reinforced by the phrase 'ask this URL a question'. It could be more explicit about URL formats or content constraints, but for two simple parameters it provides enough semantic grounding.

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

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

The description states a specific action ('ask a question') on a specific resource ('a web page') and explicitly contrasts the output ('verified answer with the extracts that back it') with 'raw text', distinguishing it from extraction or LLM siblings. Despite the vague tool name 'understand', the description supplies a crisp functional identity.

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 provides explicit trigger phrases ('Use when asked: "answer a question about this page"...') and makes clear this is for question-answering with verification rather than raw extraction. It does not explicitly name alternative sibling tools or give when-not-to-use conditions, but the 'instead of raw text' contrast implies a reasonable exclusion boundary.

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 behavioral disclosure. It states that the tool does not download page bodies, that every hop is reported with status/time/Location, that loop detection is performed, and that it is a paid per-request call via x402. This gives the agent a clear and honest model of the tool's behavior.

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

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

Three dense sentences with no filler: purpose and output first, then use cases, then query format and cost. Each sentence earns its place and the most important information is front-loaded.

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

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

For a one-parameter tool with no output schema and no annotations, this description is remarkably complete: it explains purpose, behavior, output fields, query syntax, pricing, payment method, and canonical user intents. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

The only parameter is url, and the schema provides no description beyond the name and type string. The description compensates with an explicit query example (?url=https://bit.ly/…), showing the parameter is a URL and that short links are expected. It does not add validation details, but the single required parameter is well illuminated.

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

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

The description opens with a specific verb and resource: 'Trace the redirect chain of a URL to its final destination.' It clearly lists the outputs (status codes, times, Location headers, final URL, domain-change indicator, loop detection) and explicitly contrasts itself with body-downloading tools, so an agent can distinguish it from siblings like domain_health or render.

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

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

The description gives explicit trigger phrases: 'where does this short link go', 'unshorten this url', 'follow redirects.' It also frames the practical context ('useful before trusting a short link or an ad link'). It does not explicitly name alternatives or when not to use it, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the payment model (pay-per-call via x402, USDC, no account), the output structure (summary with citations, key points, unresolved questions, and underlying data), and the scope (US public companies). It does not mention rate limits or edge cases, but the core behavior is transparent.

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

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

The description is dense but well-structured. It front-loads the value proposition, then details the output, cost, and usage triggers. Every sentence adds information, though it could be slightly more concise. The structure is logical and easy to scan.

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

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

Given the tool's complexity (returns a cited summary with financials and filings) and the absence of an output schema, the description explains the return content well. It also covers payment and usage. It does not mention error handling or invalid ticker behavior, but for an agent deciding whether to call this tool, it is sufficiently 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 schema has a single 'ticker' parameter with zero description coverage (0%). The description implies ticker is the company identifier via usage examples like 'due diligence on a ticker', but it does not explicitly define the expected format (e.g., uppercase symbol). For a single simple parameter, this is adequate but not fully explicit.

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

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

The description clearly states the tool's purpose: to provide a cited summary about any US public company, including key points, unresolved questions, identity, three years of annual figures, and recent filings. It distinguishes itself from siblings like us_company, us_filings, and us_financials by emphasizing the synthesis and citation aspect.

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

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

Explicit usage triggers are given: 'cited brief on this US company', 'company brief from sec filings', 'due diligence on a ticker'. It also explains that it replaces three separate purchases, implying when it is the efficient choice. This is direct and actionable for an 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?

No annotations are present, so the description must carry the behavioral disclosure burden. It does disclose the data source (SEC EDGAR), the per-call pricing via x402, and the output fields, which is useful context. However, it does not clarify failure behavior, input validation edge cases, or whether passing a CIK into the 'ticker' parameter is actually supported.

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

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

The purpose and output fields are front-loaded, and the pricing/use-case sentence adds useful context. Some redundancy exists: 'Profile of a US public company from SEC EDGAR' and 'authoritative regulatory record rather than an aggregator's copy' repeat the sourcing idea, and the use-when examples partly duplicate earlier guidance.

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 and no annotations, the description is fairly complete: it lists returned fields, identifies the data source, gives example query phrasings, and states the cost. The main residual gap is the ambiguity around ticker versus CIK versus company-name input, which could cause an agent to send an unsupported value.

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 only parameter is an undescribed string 'ticker'. The description adds that the value can be a ticker or CIK, which is meaningful beyond the schema. Yet it lacks format details or examples, and the 'resolving a company name' phrasing suggests an accepted input mode not reflected in the schema.

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

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

The first sentence names a concrete action and object: resolve a ticker or CIK to a US company's registered identity, and the description enumerates the profile fields returned. It clearly positions the tool as the SEC EDGAR identity record and references pulling financials or filings, but it does not explicitly name or contrast a sibling tool, so it stops short of full 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?

The description provides explicit use-case guidance with 'For agents resolving a company name to its regulatory identity before pulling financials or filings' and concrete query examples like 'who is this company' or 'company identity from sec'. However, there is no explicit when-not-to-use guidance or mention of alternative sibling tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses the cost ($0.005/call via x402 USDC) and the reliance on the NHTSA database, which is useful. However, it does not mention potential errors (e.g., invalid VIN), rate limits, or response format. For a read-only lookup, this is a moderate gap but not a serious one.

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

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

The description is concise, starting with the primary purpose, then giving an example query, cost, and usage triggers. It is front-loaded with the most important information and contains no redundant sentences. It could be slightly more structured, but it is effective.

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 tool with one parameter and no output schema, the description covers the core elements: what it does, when to use it, cost, and an example. It omits error handling and return details, but these are not critical for a basic decode operation. The tool is well-scoped and the description is sufficiently 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 only parameter 'vin' is self-explanatory given the description's purpose, so the meaning is conveyed even though schema description coverage is 0%. However, it doesn't explicitly validate format (e.g., 17-character VIN) or provide examples beyond the query line. The description compensates adequately but could be more explicit about the parameter's expected 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 clearly states a specific verb 'Decode' and resource 'vehicle identification number', and enumerates the output fields (make, model, model year, trim, body class, engine, etc.) and the source (NHTSA vPIC database). It also provides an example query and usage phrases, making it unmistakable and distinct from any sibling tools, which are unrelated.

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

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

It explicitly lists trigger phrases like 'decode this vin' and 'what car is this vin', which tells the agent exactly when to invoke this tool. Since no sibling tool handles VIN decoding, no alternatives are mentioned, but the guidance is clear and sufficient for the use case.

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

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

With no annotations, the description carries the full burden, and it does disclose useful traits: pay-per-call, no account and no API key, $0.020000/call, payment via x402 (USDC), and the Llama 4 Scout model. However, it introduces an 'image_base64' field and body shape that do not match the provided input schema, which can mislead the agent about accepted 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?

The main purpose is front-loaded and the trigger phrases are useful, but the description repeats pricing information ('pay-per-call', '$0.020000/call', 'paid per request via x402 (USDC)') and includes a body-syntax line that duplicates the schema while adding a conflicting field. It is informative but not tight.

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 tool with no output schema, it covers cost, authentication, model, input formats, and sample queries, and it states the plain-language answer output. However, the base64/schema mismatch and lack of error or edge-case behavior leave gaps that could lead an agent to construct an invalid request.

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

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

Schema description coverage is 0%, so the description must explain the parameters, and it does state that the image comes from a URL or base64 and that the question is optional. Yet the described base64 field is absent from the schema, and no format or constraint details are provided, leaving ambiguity about how to pass base64 input.

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

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

The description opens with a specific action and resource: 'Answer a question about an image, or describe it, from a URL or base64.' It also lists concrete use cases like reading visible text, identifying a product, and checking what a screenshot shows, which clearly differentiates it from sibling tools such as screenshot, image, or render.

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

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

The description gives explicit trigger phrases: "Use when asked: 'describe this image', 'what is in this picture', 'analyze this image'." It also notes the cost advantage over 'other vision routes on x402', but it does not name an alternative tool or state when not to use it, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden and handles it well: it reveals the stateful comparison (prior checksum vs current), the baseline behavior when no checksum is supplied, that only main content is compared, and pricing/payment via x402. This goes well beyond the tool name.

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

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

The description is compact and front-loaded, but the opening rhetorical restatement ('Has a page changed since you last read it?') adds little beyond the first sentence. Still, every operational detail is 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?

There is no output schema, yet the description lists the response fields and the no-checksum case. It is slightly ambiguous what 'returns the starting point' means in exact output shape, and error cases are absent, but it is otherwise complete for a simple two-parameter 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 compensate, and it does: url is a page to send, since_sha256 is the previously returned content hash, and the optional marker is shown in body {url, since_sha256?}. This is nearly complete parameter 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?

The description states a specific verb and resource: 'Tell whether a page changed since the last time you read it.' It also names the exact comparison result, which separates it from fetch/render/screenshot siblings that simply retrieve pages.

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

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

It gives explicit trigger phrasing ('Use when asked: ...') with three concrete example intents. It does not name alternative tools to avoid, but the when-to-use guidance is clear enough to route an 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 behavioral disclosure burden. It adds valuable traits: reads from the rendered DOM, uses mailto:/tel: links, and explicitly states nothing is inferred, enriched, or cross-referenced. It also discloses cost and payment. It does not mention side effects, rate limits, or failure behavior, but as a read-only collector the key constraints are covered.

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

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

The description is front-loaded with the core purpose, but the first two sentences are partially redundant ('Collect the emails...' and 'Emails, phone numbers and social profile links visibly published...'). The pricing and usage examples add value, but the redundancy prevents a higher score.

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

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

The tool is simple (one URL parameter, no nested objects, no output schema). The description clearly states what data is collected and the constraint of visible-only data, but it does not describe the output structure, pagination, error behavior, or what happens when no contacts are found. Given the absence of output schema and annotations, the description is adequate but not complete for an agent to fully anticipate results.

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

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

The schema has 0% description coverage, so the description must compensate. It provides 'Body: {url}', indicating the URL is passed in the request body, and usage examples clarify it is a website URL. However, it does not explain URL format requirements or how the URL is used beyond that, offering only partial compensation for the missing schema description.

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

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

The description states a specific verb ('collect'), a clear resource (page), and the exact extraction scope (emails, phone numbers, social profiles). It also differentiates from siblings by explicitly limiting to visibly published data and not inferring, which distinguishes it from generic extract or social_search tools.

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

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

The description provides concrete example queries ('get contact email from the site', etc.), giving clear context for when to use the tool. However, it does not explicitly mention when not to use it or point to alternative tools, so it falls short of a 5.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states 'Read only: nothing is submitted,' which is a valuable safety guarantee, but it does not discuss rendering behavior, rate limits, or failure modes. The read-only framing is helpful but leaves other behavioral aspects 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?

The description is compact and front-loaded: it states what is returned, confirms it is read-only, shows the request body, and gives concrete usage phrases. Every sentence earns its place and there is no filler.

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

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

For a simple one-parameter read-only tool, the description is nearly complete: it describes the response shape, safety behavior, cost/payment, and typical user requests. The absence of an output schema is mitigated by the explicit list of returned attributes. It lacks only edge-case or error-handling detail, which is acceptable for 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?

The only parameter, url, is self-explanatory and the description adds that it goes in the request body via '{url}'. Schema description coverage is 0%, but for a single well-named parameter the missing detail is minor. It does not specify URL formatting requirements, which would have improved the 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 clearly states the tool returns every form on a page with action, method, and field details, making its scope specific and understandable. It is distinguishable from generic scraping tools because it focuses on forms, though it does not explicitly name and contrast a sibling tool.

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

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

The description provides explicit usage triggers: 'list the forms on this page', 'what does this page ask for', and 'form fields of this URL'. It does not offer when-not-to-use guidance or alternatives, so it stops short of full routing clarity.

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 discloses cost and payment method ($0.005000/call via x402 USDC), which is useful, and describes the output (headings with level and anchor). However, it omits other behavioral aspects like error handling, redirects, or whether the URL must be publicly accessible. The cost disclosure adds value but the overall transparency is moderate.

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

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

The description is concise and front-loaded with the core purpose, followed by cost and usage examples. Every sentence adds value, and it avoids unnecessary fluff. The structure is efficient.

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

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

The description explains the output format (headings with level and anchor) but lacks details on error handling, pagination, or limitations. Given the absence of an output schema, it partially covers the output but leaves gaps. It also does not differentiate from many sibling tools, which could confuse an agent. Overall, it is adequate but not complete.

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

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

Schema description coverage is 0% and the description does not explain the 'url' parameter beyond a vague 'Body: {url}' note. It does not specify URL format, required scheme, or any constraints. Since coverage is low, the description should compensate, but it fails to add meaningful parameter 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 clearly states the tool's purpose: extracting the document outline with heading levels and anchors in order. It is specific about the resource (page) and the output. However, it does not explicitly differentiate from sibling tools like extract or render, though the example queries help distinguish it.

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

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

The description provides explicit example queries ('extract headings from this article', 'outline of this page', 'get the h1 and h2 of this URL') that signal when to use the tool. It does not mention when not to use it or name alternatives, but the examples give clear usage context.

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 behavioral burden. It usefully discloses that URLs are 'resolved' and that a social preview image is included, plus the paid x402/USDC requirement. However, it does not mention rendering limitations, failure modes, or how non-HTML or blocked URLs are handled.

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

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

The description is compact and front-loaded with the core output, then adds invocation body, pricing, and usage examples without redundancy. Every component earns its place and no unnecessary wording is present.

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

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

For a single-parameter tool with no output schema, the description is near complete: it states what is returned, the required URL, payment model, and typical queries. It only lacks brief notes on edge cases such as pages with no images or invalid URLs.

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. The prose makes clear that url is the page URL and 'Body: {url}' indicates how it is sent. Still, there is no explicit validation guidance, URL format requirement, or edge-case handling beyond the obvious.

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

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

The description clearly identifies the resource ('every image on a page') and specifies the output fields: resolved URL, alt text, dimensions, and social preview image. It lacks an explicit verb like 'List' or 'Retrieve', but the meaning is unambiguous and distinct from sibling tools like links or web_headings.

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

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

It gives explicit trigger examples: 'list the images on this page', 'image urls and alt text from this URL', and 'get the social preview image'. This provides clear context for when to invoke the tool, though it does not explicitly state when not to use it or name an alternative.

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

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

With no annotations, the description carries the full behavior burdenaisl. It discloses that the fetch happens 'through a residential IP with a real browser,' that there is 'no model in the path,' and that billing is 'paid per request via x402 (USDC).' This is useful transparency, though it does not cover error behavior or exact 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.