Professor Sausages — On-chain

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 key behavioral guarantee ('never a silent all-clear'), the payment flow (call without x_payment to get terms, then with x_payment to get data), and the live nature of the SDN list. It does not cover error cases or rate limits, but the essential behaviors are 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 front-loaded with the core purpose and is appropriately sized at three sentences. The payment flow is described in a dense, run-on sentence but every clause carries essential information. Slightly more structure would improve readability, but it is not verbose.

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 core function, return behavior, and the paid payment workflow, which are the major contextual elements. There is no output schema, so the explicit mention of the verdict and evidence is valuable. It lacks details on invalid addresses or network failures, but the description is sufficiently complete for a screening tool with 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?

Schema description coverage is 100%, so the baseline is 3. The description's mention of 'segmented by chain' and the payment flow adds some context, but the schema already fully documents each parameter's meaning. The description does not add significant semantic 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 opens with a specific verb and resource: 'Screen a crypto address against the full live OFAC SDN list.' It also mentions the return of a verdict with matching SDN entries as evidence, clearly distinguishing it from sibling tools like gas_price or token_safety.

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 the two-step payment process and explicitly names the 'pricing' tool as a free alternative for price discovery. However, it does not explicitly contrast with sibling screening tools (e.g., token_safety, nft_scam_check) or state when not to use 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?

No annotations exist, so the description carries the full burden. It discloses the paid nature with the exact two-step payment flow (call without x_payment for terms, sign, then call again with x_payment). It also documents behavioral details like liveness-scored RPCs and eth_chainId probing.

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 but dense; every sentence adds a distinct piece of information. It is front-loaded with the core purpose and then systematically covers views and payment. Slightly long but 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?

Given no output schema, the description explains what each view returns (ranked RPC list, EIP-3085 object, etc.) and the payment workflow. This 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?

The schema covers 100% of parameters with good descriptions, but the description adds meaning by explaining the x_payment two-step protocol and the semantic differences between view values, which the schema only names with enum strings.

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 a 'Canonical record for an EVM chain' and enumerates the exact data types (name, native currency, explorers, RPCs). It differentiates from siblings like gas_price and spot_price by focusing on chain metadata, and further disambiguates internal views.

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 clear per-view usage guidance ('view='rpcs' returns...', 'view='search' finds...') and explicitly points to an alternative tool ('The free `pricing` tool lists every price at once'), telling the agent when not to pay per-call. It does not exhaustively contrast with all siblings, but the key alternative is covered.

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 covers key behaviors: bidirectional resolution, direction detection, view-specific outputs (profile returns full identity card, avatar dereferences to image URL), and the payment requirement. It also reveals that the tool is paid and explains the two-call settlement mechanism. The only gaps are details like response format or error behavior, which are not critical for selection.

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. The first sentence states the core purpose, the second covers view options, and the third explains the payment flow. Every sentence earns its place with no redundant or filler content. It is easy to scan and extract the key information quickly.

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 (multiple views, paid flow, bidirectional resolution), the description is remarkably complete. It explains the main behaviors, the payment process, and the view alternatives. It omits explicit mention of the 'text' view (only implying it via the keys parameter), but the schema fills that gap. The absence of an output schema is mitigated by the description's clarity about what each view returns.

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 describes all four parameters with examples and clear descriptions, achieving 100% coverage. The description does not add new parameter-level meaning beyond what's already in the schema; it repeats the x_payment flow and view options but does not introduce new semantics. Since the schema already does the heavy lifting, a baseline of 3 is appropriate.

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

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

The description opens with a precise statement of what the tool does: resolving an ENS name to an address or an address to its forward-verified primary name. It clearly identifies the resource (ENS names/addresses) and the verb (resolve), and further distinguishes sub-modes via the view parameter. This goes beyond a simple restatement and leaves no ambiguity about the tool's 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?

The description provides clear usage context: direction is auto-detected, view options are described, and the paid two-step flow is explicitly explained (call without x_payment to get terms, then call with x_payment). It also names an alternative (the free `pricing` tool) for listing all prices. While it doesn't explicitly state when NOT to use this tool, the context is sufficiently clear for an agent to decide.

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 transparency burden. It discloses the search order (server datasets first, then catalog) and what the response contains (method, URL, price, call instructions) plus the fact that it is free. It does not mention error handling, rate limits, or authentication, but for a search/discovery tool, this is reasonably transparent and gives the agent a good sense of what to expect.

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: three sentences that front-load examples, state the search behavior, and summarize output. Every sentence earns its place with no filler, and the structure guides the agent from usage examples to process to result format 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?

Given a single parameter and no output schema, the description covers the essential context: what to provide, how the search works, and what the response will include. It could mention potential limitations or error cases, but for a tool of this complexity, the description is complete enough for an agent to select and use it correctly. A 5 would require more explicit details on edge cases or failure modes.

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 fully describes the single 'task' parameter with an example. The description adds value by offering multiple plain-language examples ('Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page') and clarifies that the task can be phrased in any way, expanding the parameter's semantics beyond the schema's minimal 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 clearly states the tool's function: it searches for data endpoints based on a plain-language description and returns matching endpoints with method, URL, price, and call instructions. The verb 'searches' and 'returns' plus resource scope (server datasets + catalog) distinguishes it from sibling tools that each target a specific data type, so an agent can easily tell when to use it for discovery versus direct retrieval.

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

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

The description explains the tool's purpose and search process, implying it should be used when you need to locate an endpoint or data source. However, it does not explicitly state when not to use it or mention alternatives like the specific sibling tools. The guidance is clear enough for an agent to infer usage, but it lacks explicit exclusions or contrast with alternatives, so it misses 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?

No annotations are provided, so the description carries the disclosure burden. It transparently reveals the paid nature and the two-step payment protocol, and notes the inclusion of the OP-stack L1 data fee. However, it does not describe the output format or error behavior, which would be useful for full 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 two sentences, front-loaded with the core purpose and metric, followed by the essential payment flow details. It is concise, well-structured, and every sentence 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?

Given the tool's moderate complexity (paid flow, ranking, fee inclusion) and lack of output schema, the description covers the purpose, payment protocol, and alternative tool. It does not specify the ranking output format, but the context is sufficient for most agents to understand how to invoke and reason about the tool.

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

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

Schema description coverage is 100% and each parameter already has a detailed description. The tool description adds context for the payment flow but does not provide significant new meaning beyond what the schema already explains for gas, speed, tx_type, and x_payment. Thus the baseline of 3 is appropriate.

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

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

The description uses a specific verb 'Rank' with a clear resource ('every supported chain') and a precise metric (all-in USD transaction cost). It also distinguishes itself from siblings by positioning it as a routing decision and explicitly naming the 'pricing' tool as a free alternative, making its 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?

The description explicitly states when to use the tool (routing decisions) and contrasts it with the free 'pricing' tool that lists all prices at once. It also provides clear usage instructions for the paid flow: call without x_payment to receive terms, sign them, then call again with x_payment.

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 responsibility. It discloses that data is read live from public RPCs, that the tool is paid via a two-step x402 flow, and that `tx_type` includes OP-stack L1 data fees. The payment mechanism is fully explained, ensuring the agent understands the cost and workflow 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?

Four sentences, each with a distinct purpose: core function, optional mode, payment workflow, and free alternative. No fluff or repetition. The most critical information is front-loaded in the first sentence, and 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?

Despite having no output schema, the description explains both phases of the result: payment terms on the first call and data on the second. It covers live source, optional transaction costing, and the alternative `pricing` tool. For a tool with 5 optional parameters and no annotations, this is remarkably 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 100%, so the baseline is 3. The description adds meaningful context by explaining that `tx_type` changes the output from raw fees to USD transaction cost and detailing the two-step `x_payment` flow. It does not need to repeat schema descriptions, so a 4 is appropriate for the added clarity.

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 explicitly states it reads live EIP-1559 fees for a single chain, with specific fee tiers and optional transaction-cost mode. It distinguishes itself from the `pricing` tool, which lists all prices, and from `gas_compare`, which likely compares chains. The verb 'read' and resource 'fees' are clear and specific.

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 when-to-use guidance: 'Pass tx_type to get the USD cost of that specific transaction instead' and 'The free `pricing` tool lists every price at once.' It also explains the payment flow, telling users to call without `x_payment` to receive terms, then call again with it. This fully orients an agent toward correct invocation.

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 disclosing behavioral traits. It reveals determinism, the paid two-step flow (call without x_payment → receive terms → sign → call again), and the evidence shape. It does not cover edge cases like what happens if both contract and wallet are provided, but it gives substantial behavioral context for a paid tool.

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

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

Four sentences cover the purpose, two usage modes, payment workflow, and an alternative pricing tool. Each sentence earns its place; there is no fluff or repetition. The structure is front-loaded with the core purpose and then layers operational details.

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 moderately complex (4 params, payment flow, two modes, no output schema), yet the description covers all necessary aspects: what it returns (verdict/evidence), when to use each param, the payment protocol, and an alternative for pricing. It gives agents enough to decide and invoke correctly without requiring extra research.

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 adds minimal extra semantic value: it clarifies the either/or relationship between contract and wallet ('or a wallet to check...') and adds 'holding by holding' detail, but the schema already describes each parameter well. No need to compensate for missing schema info.

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 'Deterministic scam checklist with a verdict and evidence' — a specific verb+resource statement that clearly identifies the tool's function. It further distinguishes itself from siblings by naming NFT-specific outputs (spam flags, copymint collisions, holder concentration) and by describing two operate modes (contract vs wallet). This is more than a generic 'check NFTs' statement.

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 explicit: 'Pass a collection contract to check the collection, or a wallet to check that wallet's whole scam exposure holding by holding.' It also points to an alternative: 'The free `pricing` tool lists every price at once,' which tells the agent when NOT to use this tool for pricing. This meets the bar for explicit when/when-not/alternatives.

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

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

With no annotations, the description carries the burden and states it reads live from the route table, indicating a read-only operation. It also discloses the 'Free' aspect. It does not mention auth or rate limits, which are likely irrelevant for a simple introspection 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 entire description is one sentence that packs in the core function, source, and cost. Every word adds value 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 no-parameter tool, the description conveys what is returned (endpoints, prices, summaries) and the source (live route table). It could specify the output format, but that is easily inferred.

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 schema is fully covered by default. The description adds no parameter details because none exist, warranting the baseline score of 4 for no-parameter tools.

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 lists every endpoint with its exact per-call price and a one-line summary, read live from the route table. This is a specific, unambiguous purpose and distinguishes it from sibling tools like coverage or fx_rate.

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

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

The description implies usage for discovering costs before calling other endpoints by emphasizing 'exact per-call USD price' and 'Free.' It provides clear context about what the tool does, though it does not explicitly name alternatives or when not to use it.

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

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

With no annotations, the description carries full responsibility. It discloses the nightly ingestion queue, ~24h turnaround, the need for optional contact, and that the service is free. It does not mention potential limitations or success criteria, but the behavior is reasonably transparent for a request tool.

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

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

Two sentences, front-loaded with the core purpose, followed by concrete examples and behavioral notes. Every clause earns its place; no 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 request tool with no output schema, the description covers the workflow, timing, and cost. It could mention how to track request status or what happens if a request is rejected, but it is largely complete 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?

Schema coverage is 100%, so the baseline is 3. The description adds context around the 'description' parameter (examples of what to ask for) and 'contact' (optional follow-up), but it does not substantially extend what the schema already provides. It reinforces rather than enriches.

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 a request mechanism for missing data, with specific examples (pre-2015 filing, uncovered ticker, unsupported chain) that distinguish it from sibling retrieval tools. The verb 'ask for' and resource 'data we don't have' make 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?

The description conveys when to use it (when data is missing from existing coverage) and gives concrete examples, but it doesn't explicitly reference sibling tools or state 'use this if find_data/coverage fails.' The implied guidance is strong but not fully explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the paid nature, the need for signed x402 payment, the use of Chainlink's latestRoundData, and that cross-conversion reports both legs. This goes beyond mere 'get price' and explains the operational behavior and prerequisites.

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 three sentences, front-loading the core purpose first, then explaining optional conversion and the payment flow. Every sentence contributes unique, actionable information with no 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?

Given the complexity (paid, multi-step, cross-conversion) and lack of output schema or annotations, the description is remarkably complete. It covers the data source (Chainlink), the payment mechanism, the cross-conversion behavior, and directs to the alternative pricing tool. It sufficiently sets expectations for the return, mentioning 'round metadata' and 'both legs reported'.

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 adds value for `to` (cross-convert via USD feeds, both legs reported) and clarifies the x_payment flow, but the schema already explains these parameters in detail. The extra context pushes it slightly above baseline.

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: 'Live Chainlink on-chain spot price for an asset (latestRoundData, with round metadata)'. It also distinguishes from the sibling 'pricing' tool by noting that the free `pricing` tool lists every price at once, making the purpose specific and non-duplicative.

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 guidance, including the two-step payment process ('call without x_payment to receive this call's exact terms... then call again with x_payment') and directs to the free `pricing` tool for a bulk price list. It also references /prices/feeds for listing available feeds, clarifying when to use this tool versus alternatives.

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

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

With no annotations, the description carries full weight. It discloses the paid nature, indicative/live-reserve sourcing, the x402/x_payment authentication flow, and that the quote reflects actual pre-sign cost. These behavioral traits go well beyond the structured 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 two sentences, front-loaded with the tool's purpose and outputs, and efficiently weaves in the payment flow and alternative tool without redundancy. Every sentence 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?

Even without an output schema, the description lists expected return values and explains both the free and paid invocation paths. Given the tool's complexity (5 params, multi-step payment), this is complete enough for an agent to select and 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?

Schema coverage is 100% with each parameter described, so the baseline is 3. The description adds value by explaining the x_payment lifecycle (omit for terms, include to settle) and the meaning of the quote outputs, which enhances understanding beyond field names.

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

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

The description clearly specifies the tool as an indicative UniswapV2 swap quote from live on-chain reserves, listing concrete outputs (amount out, execution price, price impact). It distinguishes itself from the sibling 'pricing' tool by being paid and providing exact per-trade terms rather than a list of all prices.

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 when-to-use guidance is provided: 'call without x_payment to receive this call's exact terms, sign them, then call again with x_payment' and 'The free `pricing` tool lists every price at once.' This clearly differentiates from the free alternative and explains the two-step paid flow.

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 heuristic nature, proxy-following behavior, and that it returns a verdict with per-rule evidence. It also transparently explains the payment requirement and two-step call pattern, providing strong behavioral context beyond a simple 'checks token safety' 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 concise, with three short sentences. It front-loads the primary purpose, then explains the payment flow and pricing alternative without wasted words. Every sentence 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?

The description covers the core functionality, output format (verdict with per-rule evidence), the payment mechanism, and an alternative tool. It lacks explicit mention of error cases or edge cases, but for a heuristic check tool with good parameter docs, 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?

Schema description coverage is 100%, so the schema already fully documents all three parameters. The tool description reiterates the payment flow but does not add any new parameter-level meaning beyond what is already in the schema's x_payment 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 clearly states it is a heuristic token safety check that follows proxies and scans runtime bytecode, plus ownership and transfer restrictions. It distinguishes itself from sibling tools like nft_scam_check by focusing on rug-pull/honeypot detection and even points to the pricing tool for price-related needs.

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 instructions for the paid payment flow (call without x_payment to get terms, sign, then call again with x_payment) and mentions the free pricing tool as an alternative for pricing. It doesn't explicitly exclude other sibling tools but gives clear context for when this tool is appropriate.

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