aiworker-data

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: it names the data sources (Honeypot.is simulation, pool liquidity, holder counts, batch sender), discloses a behavioral cap (25 tokens), asserts determinism with no LLM, and states the cost model ($0.05 per call, USDC via x402). This is behaviorally rich for an unannotated read 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 capability is front-loaded and the parenthetical evidence list is compact, though the sentence is dense and stacks clause after clause. Nearly every phrase carries information, with no filler.

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

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

With no output schema, the description still communicates the return shape (per-token label plus reasons), the cost, and the determinism guarantee. Only lower-level details such as failure modes on invalid addresses or latency are absent.

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

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

Schema description coverage is 100% for the single 'address' parameter, so the schema already defines the pattern and chain. The description's 'one Base address' restates rather than adds semantics, making the baseline 3 correct.

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

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

The description states a specific verb and resource — per-token hygiene labels for one Base wallet — and enumerates the exact classifications returned (honeypot, dust, batch-airdropped, name-spoofed, ok, unknown), so the agent knows precisely what it produces. It stops short of distinguishing itself from sibling tools like wallet_check or token_check.

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

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

Usage is only implied via the purpose clause 'which balances to ignore and never approve,' which suggests a pre-approval hygiene check. No sibling alternative is named and no when-not-to-use condition is given.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that the tool is informational only, mentions the price and payment method, and describes what evidence sources are used and what output is produced.

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 compact sentence that conveys purpose, output, constraints, and pricing without excessive verbosity. Slight density from including pricing and payment details inline is acceptable and does not harm 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?

Since there is no output schema, the description adequately explains what the tool will return: verdicts, quoted evidence, and links. It also clarifies the evidence scope (Wikipedia plus up to 5 buyer-supplied URLs), making the tool's behavior sufficiently understandable in 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 schema covers all four parameters with 100% coverage. The description adds meaningful semantic context beyond the schema, such as requiring exactly one of text or url, the default max_claims of 5, and the role of sources as additional evidence alongside Wikipedia.

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: extract checkable factual claims from text or URL and verdict each claim against Wikipedia and buyer-supplied sources. It also specifies the output includes verdicts, quoted evidence, and 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?

The description implies use for fact-checking claims, but does not explicitly distinguish when to use this tool versus sibling tools like scrape_markdown or scrape_summary. It gives no direct when-to-use/when-not-to-use guidance beyond the core purpose.

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 discloses the data source (DefiLlama protocol summary), a 5-minute refresh interval, and the $0.01 cost paid via USDC/x402, but it does not state whether the call is read-only, what auth is required, or what happens on invalid slugs. 'Snapshot' implies non-mutating but is not explicit.

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

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

Two compact sentences front-load the purpose and data fields, then add operational details (refresh, cost, payment). No filler or redundant repetition of schema 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 covers the main data returned, the source and freshness, and the pricing/payment model. It does not specify return format or error handling, but these are less critical given the simplicity and the enumeration of output fields.

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

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

Schema description coverage is 100% and the slug property already includes its pattern and an example (aave-v3). The tool description only reuses the notion of 'by slug' without adding new meaning about the parameter's possible values or behavior, so baseline 3 applies.

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

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

The description states a specific action (Snapshot) and resource (one DeFi protocol by DefiLlama slug), and enumerates the returned data (TVL by chain, category, 1d/7d change, audits). However, it does not explicitly name or contrast sibling tools such as defi_yields, so differentiation is implicit rather than explicit.

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

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

The description conveys usage context by describing the exact data the tool returns and its freshness, implying it is for obtaining a protocol snapshot from DefiLlama. It lacks explicit guidance on when to choose this tool over defi_yields or the scrape_* siblings, and gives no 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 must carry the behavioral burden. It adds useful context such as data source, normalization, 5-minute refresh, and per-call cost, but it does not disclose output ordering, default limits, pagination, or rate limits. It is helpful but not 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 description is compact and information-dense, with no filler. The first sentence delivers the core purpose and filters, while the second adds important operational details about freshness and cost. Every clause earns its place.

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

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

There is no output schema and no annotations, so the description must explain what the agent gets back and how calling behavior works. It does not mention result fields, ordering, default limits, pagination, or what a zero-filter call returns. For a six-parameter data tool, this is a notable 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 description coverage is only 33%, so the description must compensate. It does explain five of the six filters conceptually (chain, project, symbol, stablecoin, min TVL) but omits 'limit' and leaves the stablecoin boolean semantics ambiguous. It adds meaning beyond the schema for some params but not all.

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 (DeFi yield pools from DefiLlama) and the key capabilities: normalization and filtering by chain, project, symbol, stablecoin, and min TVL. However, there is no explicit verb like 'get' or 'list', and it does not distinguish itself from the sibling tool defi_protocol.

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

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

The description implies usage through filterable fields but gives no explicit guidance on when to use this tool versus defi_protocol or the scrape tools. There are no stated alternatives, exclusions, or conditions that would help an agent route between siblings.

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

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

With no annotations, the description carries the full burden and does it well: deterministic, no LLM, seconds per call, a non-existent keyed market is refused before payment, a free-text miss returns not_found with nearest candidates, informational-only disclaimer, and explicit pricing ($0.01/call via USDC over x402). These are exactly the behavioral traits an agent needs and none of them are restated from structured fields.

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

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

Front-loaded with the purpose and the output payload before commercial and error details, and nearly every clause earns its place. It is, however, one long run-on sentence with heavy comma chains, which slightly hurts scanability.

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

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

No output schema exists, and the description compensates by enumerating the returned fields and the error modes (not_found with nearest candidates, pre-payment refusal). Combined with the data source (Gamma API) and cost model, an agent has everything needed to call it correctly.

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

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

The single 'market' parameter is already documented at 100% coverage in the schema, including the slug / 0x condition id / free-text forms. The description restates those forms but adds no new syntax, precedence rules, or formatting detail beyond it, so the schema does the heavy lifting and baseline 3 applies.

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

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

States a specific verb and resource — the current odds of ONE Polymarket market and how they moved — and enumerates the returned fields (YES/NO prices, last trade, implied probability, liquidity, volume, 24h/7d change). The scoping word 'one' implicitly separates it from the multi-market sibling market_screener, so an agent can route without opening a schema.

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

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

It tells the agent how to address a market (slug, 0x condition id, or free-text question) and what happens on a miss (not_found with nearest candidates), which is useful context. But it never names when to prefer this over siblings such as odds_history, market_screener, or resolution_check, so selection guidance is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: deterministic filters, no LLM/free text, a 500-candidate ranking cap, cost per call paid via USDC/x402, and the output fields. It also adds a 'not advice' disclaimer Offerring more transparency than a mere 'returns a list' statement.

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, dense sentence that front-loads the core purpose and uses semicolons to separate filter groups, output columns, and constraints. It is information-dense without being verbose, but the long run-on structure could be slightly more scannable for an agent.

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

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

For a tool with 7 parameters and no output schema, the description covers all parameter semantics, lists the returned fields, sets expectations about candidate limits, and mentions pricing and payment method. It lacks example inputs or error handling details, but is otherwise complete enough for correct invocation in most cases.

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

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

Schema coverage is 100% so the baseline is 3, but the description goes beyond the schema by explaining the 'category' requirement (event tag with at least 200 resolved markets), the 'movers' behavior (sort by 7-day change), and the overall set of output columns. This adds meaningful context for parameter selection.

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 a ranked list of Polymarket markets under deterministic filtershol with specific sort and filter options. It names the resource (Polymarket markets) and the action (screener ranking), but does not explicitly distinguish itself from sibling tools like claim_check or resolution_check, which are different in function.

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

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

The description implies use for deterministic market screening with filtersable and sorted output, and notes 'No LLM, no free text' to signal a non-AI interpretation tool. However, it provides no explicit 'when to use this vs. alternatives' guidance or exclusions, leaving the agent to infer when this screener is the right choice.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses deduplication, newest-first ordering, a ten-minute refresh cadence, whole-word/case-insensitive matching, 'no LLM', 'informational only', and a $0.01 x402/USDC payment requirement. It omits rate limits and failure modes, keeping it just 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?

Effectively a single dense sentence front-loaded with the core purpose, followed by short payoff clauses ('no LLM', 'Informational only', price). Nearly every clause earns its place, though the run-on structure slightly reduces scannability.

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

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

Despite having no output schema, the description enumerates the returned fields (title, link, publisher, published time, short summary) along with ordering and item cap. Combined with the source list and payment model, an agent has everything needed to call and interpret 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 100%, so query, hours (default 48, 1-168), and limit (max 50) are already documented in the schema. The description restates the defaults and the matching semantics but adds no syntax, format, or edge-case guidance beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb (search) and resource (crypto/markets headlines) plus the exact source corpus of twelve named feeds, so an agent can distinguish it from generic siblings like scrape_markdown or topic_brief. The scope (titles and summaries, fixed public feeds) 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?

The description makes the tool's niche inferable (matching words against a fixed crypto/markets feed set) but never explicitly says when to pick it over siblings such as topic_brief, claim_check, or scrape_markdown, nor states any exclusion. Usage is left to inference.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden and succeeds well. It discloses the data provenance, determinism, lack of LLM involvement, refusal behavior for unsupported markets, and the exact payment method and price. These traits go beyond anything the schema or annotations provide.

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 and front-loaded with the core purpose, and every clause contributes useful information about inputs, outputs, behavior, or cost. It is somewhat run-on as one long sentence, which hurts readability slightly, but there is no wasted or redundant content.

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 there is no output schema CPA and no annotations, the description compensates well by listing the output components: daily closes, fill counts, volume, open, high, low, last, 1-day and 1-week change, days to end date, and window volume. It also covers payment, refusal behavior, and determinism, so an agent has enough context to 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 description coverage is 100%, so the baseline is 3. The description repeats what the schema already documents: market can be a slug, 0x condition id, or numeric id, and days is 1–365 with a 90 default. It does not add meaningful new parameter semantics beyond what the schema and name already convey.

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 leads with a specific, unambiguous statement: 'The daily YES-price history of one Polymarket market.' It names the exact resource (one market's price history) and the action (getting the historical series), and reinforces scope with 'History, not a prediction,' which helps differentiate it from prediction or screening 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 gives clear practical context: it identifies the accepted market identifiers, the valid days range, default value, and the fact that unsupported markets are refused before payment. It does not explicitly name sibling tools or state when not to use them, but phrases like 'one Polymarket market' and 'History, not a prediction' imply the appropriate 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 and does well: it discloses that the tool is deterministic, uses no LLM, is fast ('seconds per call'), is informational only ('a record of what happened, not a prediction'), and has a specific not_found behavior with nearest candidates. It also discloses pricing and payment method. It does not mention rate limits or whether the underlying API could fail, but for a read-only informational tool the disclosed traits are substantial.

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 dense paragraph that front-loads the core question and then lists outputs and behaviors. Every sentence adds information: input forms, output fields, data source, determinism, fallback behavior, informational nature, and pricing. It is slightly long but each clause earns its place; the pricing sentence could arguably be trimmed, but it is relevant for an agent deciding whether to call a paid tool.

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

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

For a single-parameter read-only tool with no output schema, the description is nearly complete: it covers inputs, outputs, source, failure mode, and cost. The only gaps are minor—no explicit mention of rate limits, no example slug/condition id format, and no statement about what happens on API errors. Given the tool's simplicity and the absence of annotations, this is a strong, complete description.

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

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

Schema coverage is 100% and the single parameter 'market' is already described in the schema as accepting a slug, condition id, or free text. The description adds meaningful semantics by explaining how the free-text form is handled (not_found with nearest candidates) and by listing the output fields that the parameter will produce. This goes beyond the schema's bare type/format description, though it doesn't add syntax details like slug format 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 opens with a specific question ('Has a Polymarket market resolved, and how?') and names the exact resource (Polymarket market resolution status) and the verb (check). It enumerates the concrete outputs (status, winning outcome, payout vector, close time, mechanism, days after end, last traded price, best bid/ask, categories) and the input forms (slug, condition id, free text), which fully distinguishes it from the sibling tools like claim_check or token_check.

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

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

The description clearly states what inputs to provide and what the tool returns, and it explicitly notes the free-text fallback behavior ('a free-text question that matches no market is answered as not_found with the nearest candidates'). It does not explicitly name sibling alternatives or say when not to use this tool, but the context signals show siblings are unrelated (claim_check, token_check, defi_protocol, etc.), so the usage context is clear enough 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?

No annotations are provided, so the description carries the full burden. It explicitly discloses that the tool is deterministic, runs no LLM and no buyer code, returns history rather than prediction, and costs $0.25 paid via x402/USDC. This goes well beyond a bare 'runs a backtest' statement, though it omits details like authentication or rate limits.

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

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

The description is long but dense: the opening sentence states the core action and rule options, the second gives selection instructions and expected outputs, and the remaining sentences add determinism, informational caveat, and pricing. Every clause contributes; there is no filler or repetition of 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?

Given no output schema and no annotations, the description compensates by listing the outputs (hit rate, return stats, drawdown, Brier score, calibration table, results by year, sample markets, exact method) and key behavioral caveats. It could still mention defaults for the optional parameters and any error conditions, but the essential context for invoking the tool is present.

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

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

Schema coverage is 100%, so the schema already documents all seven parameters. The description adds value by defining each rule strategy (e.g., favorite_hold 'buy the side at or above p on its first such day'), which clarifies how threshold, days_before_end, and rule interact. It also clarifies category as an event tag and frames from/to as a date range.

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

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

States a precise action ('Replay') on a specific resource ('resolved Polymarket markets from a derived store of on-chain daily closes') and enumerates the four rule variants. This makes the tool's function unmistakable and sets it apart from the sibling tools, which are check/scrape/report utilities.

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

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

Gives clear operating context: pick a category and date range, and notes the tool is informational, deterministic, and historical. It does not explicitly name alternatives or exclusions among siblings, but the context is sufficient for an agent to recognize when a historical backtest is appropriate.

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 disclosure burden and does so well: it reveals the call is paid ($0.02/call, USDC via x402), that robots.txt is honoured (so some URLs will fail), and that only public pages are accepted. It stops short of describing failure modes or edge cases like JS-heavy pages that yield no main content.

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

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

Two sentences with zero filler: the core function and constraints are front-loaded, and pricing forms a clean second sentence. Every element earns its place.

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

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

For a simple two-parameter tool with no annotations and no output schema, the description covers function, constraints, return shape (title, word count, Markdown), and cost. The main gaps are sibling differentiation and failure behavior, but everything needed to invoke it correctly is present.

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

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

Schema description coverage is 50%: url is well described ('absolute https url of a public page') and the description reinforces it with 'buyer-supplied URL'. max_chars has only numeric bounds (500-60000) in the schema, and the description adds no explicit meaning for it beyond implying output-length control.

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 ('Fetch one public web page') and precisely describes the output ('clean Markdown with title and word count'), which differentiates it from the scrape_summary sibling. The parenthetical constraints ('buyer-supplied URL, no login walls, robots.txt honoured') further define the tool's scope without ambiguity.

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

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

The constraints clearly define when the tool is usable (public pages only, no login walls, robots.txt-compliant) but only implicitly. There is no explicit statement of when to prefer this tool over scrape_summary or the defi siblings.

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

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

Despite having no annotations, the description discloses important behavioral details: the summary is generated by an LLM, is capped at 200 words, and the call costs $0.04 paid in USDC over x402. It does not mention failure modes, rate limits, or authentication, but the cost and processing behavior are well 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?

Two sentences with no filler. It front-loads the core functional relationship, then adds the distinguishing summary output, constraints, and pricing all compactly.

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, the description plus schema is mostly sufficient. It defines the output elements, cost, and LLM behavior, though it could more explicitly describe the return structure and how max_chars influences processing. No output schema exists, so a small amount of extra output detail would make it fully complete.

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

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

The input schema documents url and leaves max_chars with only a range; the description adds no parameter-level meaning. 'Same as /v1/scrape/markdown' only indirectly implies shared parameters and does not explain how max_chars affects the summary or scraping. With only 50% schema description coverage, the description should compensate more but does not.

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

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

The description clearly states what the tool does: scrape a page like /v1/scrape/markdown and additionally produce a structured LLM-generated summary, key points, and entities. This differentiates it from sibling scrape_markdown, which presumably returns only markdown.

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

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

The phrase 'Same as /v1/scrape/markdown plus a structured summary' implies when to choose this tool over scrape_markdown: choose this when a summary and extracted entities are needed. However, it does not explicitly state 'use this when...' or exclude cases, so it stops short of full 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 does so well: it discloses deduplication, newest-first ordering, the 300-character text truncation, per-source counts and an 'ok' flag for partial failures, plus the paid-access model ($0.01 per call via USDC over x402). These are exactly the operational traits an agent needs before invoking.

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

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

Purpose and sources are front-loaded, and nearly every clause adds usable detail. However, it is packed into essentially one long run-on sentence with a trailing disclaimer and pricing clause, which hurts scannability.

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 or annotations, the description compensates by enumerating the returned fields (text, link, author handle, time, per-source counts, ok flag). Nothing an agent needs to call or interpret the tool correctly appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents query, hours, and limit, including the whole-word/case-insensitive matching. The description restates the matching rule and hours range but omits the schema's default limit of 20 (it only says 'up to 50 items'), adding little beyond the 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 names a concrete resource (public mentions from Hacker News and Polymarket) and scopes it precisely, including the upstream sources (Algolia HN Search API, Gamma API). An agent can distinguish this from news_search or topic_brief without opening the schema, since it explicitly targets forums/comments rather than news articles or synthesized briefs.

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

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

Usage context is implied by the mention-search framing and the 1-168h lookback, but there is no explicit statement of when to prefer this over news_search, topic_brief, or claim_check, and no exclusions or prerequisites beyond the payment note. Adequate but leaves routing decisions to inference.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers unusual value: it discloses determinism ('no LLM'), the exact cost and payment rail ('$0.10 per call, paid with USDC over x402'), and it clarifies which output dominates ('the verdict is the gate's; the rest is context beside it'). Read-only safety is only implied, not 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?

A single dense sentence, but it is front-loaded with the purpose and then ordered by component. Every clause (gate, wallet scan, trending, payment terms) adds distinct information, with little waste.

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

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

With no annotations and no output schema, the description must convey both behavior and return shape, and it does: it names the three returned signals, states what the verdict means, and covers cost and payment. Only read-only/non-destructive guarantees and any latency or rate-limit details are absent.

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

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds real meaning: it explains that 'wallet' is optional and conditionally triggers the wallet-scan component, which the schema alone does not convey. The token parameter's role in the verdict is also clarified.

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

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

States a concrete verb and scope ('Everything to check before one swap on Base, in one call') and enumerates the three bundled signals: the rule-based trade gate, the wallet spam/honeypot scan, and trending-pool membership. An agent can distinguish this composite precheck from siblings trade_gate, wallet_check, and token_check without opening any schema.

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

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

It gives clear contextual guidance for the optional wallet scan ('when a wallet is given') and frames this as the single-call aggregate of checks that would otherwise require several tools. It stops short of explicitly stating when to prefer this over calling trade_gate or wallet_check alone, so it earns a 4 rather than 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 fully carries the transparency burden. It explicitly states the tool is deterministic, rule-based, does not use an LLM, and is informational only. It also mentions the price and payment method, giving users a complete picture of the tool's behavior and limitations.

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

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

The description is a single, packed sentence but remains focused and structured. It efficiently lists data sources, outputs, and key characteristics. While the inclusion of pricing could be seen as extra detail, it is relevant for a paid tool and does not bloat the description. Overall, it is concise 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?

Given the tool's moderate complexity and lack of an output schema, the description sufficiently covers what the tool returns and its nature. It mentions the score, risk flags, and specific data points, which gives a user enough context to understand the tool's scope. It does not delve into error cases or edge conditions, but such details are not typically required for a well-scoped utility 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 already provides high coverage (100%) with descriptions for both parameters. The tool description adds meaning by explaining that the address is a token contract and that the chain is Base, aligning with the schema's 'const' value. It also clarifies what the address is used for in the context of the safety card, adding value beyond the schema.

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

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

The description clearly states the tool's purpose: providing a deterministic token safety card for Base tokens, with specific data sources (Blockscout, DexScreener, Honeypot.is) and outputs (contract, control, holders, trading venues, buy/sell simulation, risk flags, score). It is distinct from sibling tools like defi_protocol or yield_report, which focus on different DeFi aspects.

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 context on when to use the tool: for token safety assessment on Base. It sets expectations with 'No LLM' and 'Informational only', which helps users decide if they need a deterministic, non-analytical check. However, it does not explicitly contrast with alternative tools, so it lacks explicit when-not guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool is deterministic, uses no LLM, completes in seconds, and is 'informational only' — implying no mutations. It also discloses the pricing model (USDC via x402) and the data sources (Blockscout and DexScreener). This is comprehensive for a read-only lookup.

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

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

The description is two sentences, with the core purpose front-loaded, followed by the alternative and cost. Every phrase earns its place — the field list is packed but necessary, and the differentiation is succinct. There is zero fluff.

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

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

For a simple two-parameter tool with no output schema, the description lists all expected return fields, mentions the data sources, cost, determinism, and the alternative tool. An agent has everything needed to decide when to invoke it and what to expect, without needing to guess at behavior.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides; it mentions 'address' is a Base token contract, but that is in the schema. It adds context about cost and data sources but nothing that clarifies parameter usage further.

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 and resource — 'look up a Base token' — and enumerates the exact fields returned (name, symbol, decimals, total supply, holder count, price, liquidity, pool count, largest pool, FDV, 24h volume). It explicitly differentiates from the sibling token_check by calling itself the 'data half' and naming what token_check covers instead. This is a model of purpose clarity.

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

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

It states when to use this tool versus the alternative: 'for contract ownership, holder concentration and a honeypot simulation, buy that instead.' It also calls itself the 'cheapest way,' implying cost-based selection, and notes 'informational only,' so it is clear this is not for contract analysis. Explicit guidance on when not to use it is present.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it is 'informational only, not investment advice', costs exactly $1.00 paid via USDC over x402, returns 'none when nothing verifiable is found', and explains the verification override rule. This kind of pricing and self-verification transparency is genuinely useful and goes beyond the structured fields.

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

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

The description is dense and front-loaded with its purpose, then expands into the report components, constraints, and pricing. It is written as one long, slightly unwieldy sentence, but nearly every clause supplies a distinct useful fact — components, sourcing rules, verdict constraints, and cost. There is virtually no filler.

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

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

With no output schema and no annotations, the description must explain what the call returns, and it does — safety card fields, pools with TVL and APY, a sourced brief, a verdict, and an optional answer. It also clarifies what the call costs and what its informational limitations are. It does not cover error cases or invalid addresses, but the schema pattern and small two-parameter surface make that non-critical.

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

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

Schema coverage is 100%, and the schema already describes both parameters — address as a Base token contract address and question as optional and answered from the report's own data. The description adds little beyond that, restating the optional question behavior and the 8453 chain implicitly through 'Base'. This is an appropriate baseline-3 case where the schema does the heavy lifting.

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

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

States a specific operation — generate a comprehensive report on a Base token — and enumerates the concrete deliverables: safety card, DefiLlama pools, sourced brief, written verdict, and risk score. The 'everything … in one call' framing differentiates it from narrower siblings like token_check, token_info, and yield_report. Clear 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 explicitly scopes usage with 'before touching a Base token, in one call' and mentions the optional question and the $1.00 cost model, which helps an agent decide when to invoke it. It does not, however, name sibling tools or state when not to use it, such as when a simpler check like token_check would suffice. Clear context, but no exclusions or alternatives are given.

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

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

With no annotations, the description bears full burden. It discloses key behaviors: sources are limited to 5 public pages plus Wikipedia, facts are dropped if quotes aren't found verbatim, and the output is informational only. It also discloses pricing and payment method, which is useful. However, it doesn't mention rate limits or error handling, but the core behaviors 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 two sentences, front-loaded with the core purpose and output format, then adds constraints and pricing. Every sentence carries critical information; there is no fluff. It is appropriately sized for the complexity.

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 moderate complexity with 3 parameters and no output schema, the description covers the essential behavioral details: citation format, source limits, verbatim constraint, and cost. It lacks explicit output schema but there isn't one, and the description implies the return value is Markdown. Minor gaps like error handling are acceptable given the detail provided.

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 description coverage is 100%, so all three parameters are already well-documented. The description adds context that 'topic' is a phrase, not a URL, and that 'sources' are in addition to Wikipedia. However, it does not elaborate on the meaning of 'max_words' beyond the schema, so the value-add is moderate, warranting the baseline 3.

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

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

The description clearly states the verb 'brief' with a specific resource ('any topic') and details the output format (150-500 words of Markdown with citations). It distinguishes itself from siblings by mentioning the citation and verbatim quote mechanism, which is unique among the listed 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 implicit usage context: when you need a sourced brief with citations and verbatim quotes. It does not explicitly state when to prefer this over siblings like scrape_summary or yield_report, but the citation requirement sets it apart. There are no exclusions or alternative mentions, so guidance is minimal.

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 well: it discloses the method ('Deterministic, no LLM'), an explicit limitation ('a pass is not a guarantee'), and the commercial/auth mechanics ('Price $0.05 per call, paid with USDC over x402'). An agent can anticipate cost, latency profile, and the epistemic weight of the result before calling.

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

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

Front-loaded with the verdict contract, then the signal list, then the caveat and price in a single dense paragraph — every clause carries content. It is slightly list-heavy inside one sentence, but nothing is redundant.

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

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

With no annotations and no output schema, the description must stand alone, and it substantially does: it enumerates the returned components ('the reasons and the numbers that tripped them'), the verdict taxonomy, the underlying data sources, cost, and limitations. Only exact response structure/field names are absent, which is acceptable for a 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 100% and both parameters are fully documented there (address pattern, chain enum 'only base'), so the schema does the heavy lifting. The description only echoes the scope with 'one Base token' and adds no format, validation, or sourcing detail beyond the schema.

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

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

Names a specific resource and outcome ('one rule-based verdict before a swap on one Base token: pass, caution or block') plus the exact signals evaluated, so an agent knows precisely what it gets. It does not explicitly differentiate itself from close siblings like token_check or token_report, which also inspect tokens.

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

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

'before a swap on one Base token' establishes a clear pre-trade gating context, which is a stronger usage signal than most definitions provide. It stops short of naming alternatives (e.g. token_info/token_check) or stating when not to use it, so it is context-clear but not exclusion-complete.

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 declares determinism, names the underlying sources (Blockscout and the Base RPC), states what is deliberately absent ('No labels, no scoring, no LLM'), notes it is informational only, and discloses cost ($0.05 per call, paid in USDC over x402). It omits failure/error behavior and latency, keeping it short of a 5.

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

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

Front-loaded with the deliverable, then the exclusion list, then the commercial/payment terms, so an agent gets the essentials in the first clause. The dense em-dash enumeration is information-rich but slightly heavy for a single sentence.

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

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

No output schema exists, so the description must characterize the return value—and it does, enumerating every field group and the flag conditions (fresh <7d, dormant >180d, no ETH, single token, contract). Combined with the disclosed sources and pricing, an agent has everything needed to call and interpret it.

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

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

Only one parameter, and the schema already documents it at 100% coverage including the 0x pattern. The description's 'any address: EOA or contract' restates what the schema's parameter description already says, adding minimal new meaning, so the high-coverage baseline of 3 applies.

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

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

Opens with a concrete verb+resource ('deterministic Base wallet card for any address') and enumerates the exact payload: ETH balance, first/last activity, tx and token-transfer counts, up to 20 ERC-20 holdings, and named rule-based flags. This clearly separates it from siblings like token_check, token_report, or claim_check, which cover different resources.

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

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

Usage context is implied by 'Facts an agent can act on; informational only,' which signals a read-only, non-advisory lookup against a single address. However, it never names an alternative tool or states when another sibling (e.g. token_report) would be the better pick, and there are no explicit 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, the description carries the full burden, and it discloses the price ($0.10 paid in USDC via x402), a key behavioral and financial constraint, plus the exact output components including the fact that a best-fit pool may be absent ('if any'). It omits failure modes and empty-result behavior but covers cost, payment, and the non-mutating nature via the word 'read'.

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 dense sentence that front-loads the tool's identity and output sections before the cost. The colon-separated list and payment clause are all essential, with no filler words.

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

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

Given six optional parameters and no output schema, the description adequately sketches return structure and cost, but it leaves filter semantics (AND vs OR, optionality of chain) and no-match behavior unspecified. An agent would still need to infer how the optional filters combine to form a valid 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 coverage is 100%, so the baseline is 3. The description only says 'matching a filter' and adds no detail beyond the schema's per-parameter descriptions, so it doesn't improve semantic understanding of chain, limit, symbol, project, stablecoin, or min_tvl_usd.

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 it is an LLM-written read of DeFiLlama yield pools and enumerates the deliverable sections (verdict, key points, risks, best-fit pool, caveats, pool rows), which makes the tool's function and output clear. It doesn't name a sibling, but 'LLM-written' implicitly separates it from raw data tools like defi_yields.

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

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

The description implies this tool is for narrative analysis rather than raw scraping or protocol metadata, but it never explicitly states when to prefer it over siblings such as defi_yields or scrape_summary. No exclusions or alternative conditions are provided.

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