Professor Sausages — On-chain

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

With no annotations, the description carries full burden and nicely discloses key behaviors: live OFAC list, chain segmentation, return of verdict with evidence, and the 'never a silent all-clear' guarantee. The payment flow is transparently explained, though error edge cases are not mentioned.

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 deliver purpose, output behavior, payment flow, and a pointer to the pricing tool. Front-loaded with the core action, every sentence adds value without redundancy or 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 paid screening tool with no output schema and no annotations, the description covers verdict, evidence, chain segmentation, and payment mechanics. It could be more explicit about the no-match result format (e.g., whether 'no entries' means clear), but overall it is sufficiently complete for an agent to use 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that omitting x_payment returns exact terms and that calling again with x_payment settles the payment, and clarifies the address is in the chain's native format (also in schema).

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

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

The description states a specific action ('Screen a crypto address against the full live OFAC SDN list') and provides clear output details (verdict with matching SDN entries as evidence). It also notes the chain-scoped nature, distinguishing it from general address tools like ens_resolve 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 clearly explains the two-step payment flow and when to use the pricing tool as an alternative for getting all prices. It does not explicitly enumerate when not to use this tool versus siblings, but the screening purpose is unambiguous and contextual.

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?

Without annotations, the description discloses key behaviors: the paid nature ('call without x_payment to receive this call's exact terms...'), the liveness-scoring and eth_chainId probing of RPCs, and the EIP-3085 output format. It does not explicitly state 'read-only,' but the repeated 'returns' wording implies it. The payment workflow and data processing are transparently described.

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

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

The description is information-dense but organized effectively: one sentence for the core record, one for the view modes, and one for payment/pricing alternative. Every sentence earns its place, though the middle sentence is long with multiple semicolon-separated clauses. No filler words; compact yet readable.

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 adequately explains the return shape for each view (e.g., 'ranked, eth_chainId-probed RPC list', 'EIP-3085 wallet_addEthereumChain object'). It also details the payment response fields (amount, asset, network). It omits error handling or edge cases, but for a moderately complex read-only tool, the description is sufficiently complete.

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

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

All five parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds value by semantically linking the view parameter to specific output shapes (e.g., 'view='wallet_config' returns a ready-to-submit EIP-3085 object') and by explaining the x_payment two-step flow beyond the schema's generic description. This exceeds the 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 opens with 'Canonical record for an EVM chain' which clearly identifies the resource and purpose. It then enumerates specific view modes (rpcs, wallet_config, search, l2s), distinguishing it from sibling tools like gas_price or spot_price. The verb 'returns' and detailed output shapes make the tool's function unambiguous.

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

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

The description provides explicit instructions for each view (e.g., 'view='rpcs' returns only the ranked, eth_chainId-probed RPC list') and explains the two-step payment flow. It also names an alternative: 'The free `pricing` tool lists every price at once.' This covers when to use, when not to use (for pricing), and an explicit alternative.

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

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

With no annotations, the description carries the full burden. It discloses the paid nature, the two-step payment flow, and how direction is detected from input. It also describes what each view returns, which is helpful, though it doesn't mention any side effects 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?

Three sentences pack a lot of information without fluff. The main purpose leads, followed by view behavior and payment instructions, with the pricing pointer at the end. 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 tool's core functionality, the four views, and the payment workflow. It doesn't specify return value formats or edge cases, but given no output schema, it provides enough context for an agent to invoke the tool correctly. The pointer to the pricing tool rounds out the picture.

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 documents all parameters at 100% coverage, so the baseline is 3. The description adds value by explaining the view behaviors, the payment logic tied to x_payment, and the direction detection for query, enhancing understanding beyond the schema's basic descriptions.

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

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

The description clearly states the tool resolves ENS names to addresses and vice versa, with direction auto-detected. It also distinguishes between views (profile, avatar, text) and mentions the payment workflow, making its purpose distinct from sibling tools like address_screen or pricing.

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

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

It explains the core use case (resolving ENS names/addresses) and explicitly directs users to the `pricing` tool for price lists, providing an alternative. However, it doesn't elaborate on when to choose this over other sibling tools like request_data or find_data, so it stops short of full exclusion guidance.

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

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

With no annotations, the description takes on the full transparency burden. It discloses the search order (server first, then catalog), the return payload (method, URL, price, how to call), and a critical cost detail ('Free'). This goes beyond basic operation and gives the agent a clear behavioral model, though it could mention result limits or failure handling.

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 long, front-loaded with the core instruction, and wastes nothing. The second sentence efficiently adds the search scope and the free pricing note. Every phrase 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 tool with a single parameter and no output schema, the description is remarkably complete. It covers what the tool does, what input to provide, how the search is performed, and what the output will contain (method, URL, price, how to call them). The absence of an output schema is compensated by this explicit listing.

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 documents 'task' with a description and example, and with 100% schema coverage, the baseline is 3. The description adds value by providing multiple diverse examples ('Apple risk factors 2023', 'is this token a honeypot', etc.) and reinforcing that plain-language input is acceptable, enriching the meaning 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 its function: searching server datasets and the Professor Sausages catalog to return matching endpoints. It uses a specific verb ('searches') and specifies the resource (server datasets, catalog), and it distinguishes itself from sibling tools as a meta-discovery tool rather than a specific data endpoint.

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 context: it describes what the user should do ('Describe the data you need in plain language') and provides concrete examples. It implies this is the tool for finding data endpoints, but it does not explicitly state when not to use it or mention alternatives, so it misses the explicit exclusion that would warrant a 5.

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

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

With no annotations, the description carries the full burden. It discloses the paid nature, the x_payment workflow, and the inclusion of the OP-stack L1 data fee. It does not mention rate limits or return format, but the core behavioral traits are well covered. No contradiction with annotations (none provided).

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

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

Three sentences with no wasted words. The first sentence front-loads the core purpose, the second explains the payment flow, and the third offers the alternative. 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 moderate complexity (4 optional params, no output schema, no annotations), the description covers the essential context: the ranking output is implied, the paid flow is explained, and the differentiator from pricing is stated. It could mention return shape or pagination, but it is largely complete for an agent to use effectively.

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 100% coverage with descriptions for each parameter, including the x_payment two-step semantics. The tool description adds little beyond reinforcing the payment flow and noting the L1 fee inclusion, which is contextual rather than parameter-specific. 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 clearly states the tool's purpose: 'Rank every supported chain by all-in USD transaction cost' with a specific verb and resource. It also frames the use case ('where should I send this' routing decision) and distinguishes itself from the pricing tool, making it 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 explains when to use this tool versus the 'pricing' alternative ('The free pricing tool lists every price at once'), and details the paid two-step invocation flow (call without x_payment, sign terms, call again). This gives clear context and 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. It discloses that data is read live from public RPCs, and openly explains the two-step paid x_payment process (call without it for terms, then with it to settle). It stops short of stating read-only guarantees or rate limits, but the payment requirement and data source 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?

The description is four sentences, front-loaded with the core function, then conditional usage, payment protocol, and alternative. Every sentence adds necessary information with no fluff or 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?

Given the complexity (optional tx_type, paid flow, multi-chain support, no output schema), the description covers the main functional modes and the payment sequence. It hints at return values ('tx-ready wei', 'USD cost') but doesn't fully specify the response shape. The alternative pricing tool is mentioned, providing a complete usage picture.

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 baseline is 3. The description adds meaningful semantics beyond the schema by explaining that tx_type returns USD cost including the OP-stack L1 data fee, and by detailing the x_payment flow. This goes beyond the schema's simple field descriptions.

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

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

The description clearly states the tool returns bid-ready EIP-1559 fees for a selected chain, with an optional tx_type mode for USD transaction costs. It distinguishes itself from the 'pricing' sibling by noting that 'pricing' lists every price at once, while this tool focuses on one chain.

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

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

The description provides explicit guidance on when to use tx_type (for USD cost of a specific transaction), and points to an alternative: 'The free `pricing` tool lists every price at once.' It also details the paid flow with x_payment, giving clear usage instructions.

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 fully carries the disclosure burden. It states the tool is deterministic, returns a verdict with evidence categories, requires a two-step paid call flow (get terms, sign, then call again with x_payment), and notes the free pricing alternative. This is comprehensive for a paid API 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 deliver the core functionality, both usage modes, payment procedure, and an alternative tool reference. No wasted words; front-loaded with purpose, then usage, then payment. Ideal density.

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

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

Despite lacking an output schema, the description listsspecific evidence types returned. It covers all input variants, the payment workflow, and network scope (Ethereum mainnet). For a tool with 4 parameters and no output schema, this is highly complete and self-sufficient.

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

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

The schema already covers all 4 parameters with descriptions, so baseline is 3. The description adds valuable semantics beyond the schema by explaining the x_payment flow (omit for terms, include to settle) and explicitly distinguishing wallet vs contract usage, raising it 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 opens with 'Deterministic scam checklist with a verdict and evidence', which clearly states the tool's function and output. It names specific evidence types (spam flags, copymint collisions, holder concentration) and distinguishes its dual scope (collection vs wallet), setting it apart from sibling tools like 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?

It explicitly explains when to use each input mode: 'Pass a collection contract to check the collection, or a wallet to check that wallet's whole scam exposure holding by holding.' It also describes the payment flow and cross-references the alternative `pricing` tool for free price listings, providing clear context and 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 full disclosure. It reveals the data is read live from the route table, specifies the currency (x402/USDC on Base), and states it is free. Though it does not explicitly say 'read-only', the context clearly implies a non-mutating listing.

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 concise sentences deliver comprehensive information: endpoints, price, currency, summary, source, and cost. Every word is purposeful, with no redundancy or 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?

The description covers what is returned (prices, summaries), the source (route table), and cost ('Free'). It omits response format or pagination details, but for a simple list tool with no output schema, this is adequate.

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

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

There are zero parameters, so schema coverage is 100%. The description adds meaningful context about the return content (prices and summaries) without needing parameter details, meeting the baseline 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 summary. It distinguishes itself from sibling tools, which focus on specific data lookups, by explicitly covering the full route table.

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 is the definitive source for endpoint pricing and explicitly notes it is free. No explicit 'when not to use' or alternatives are mentioned, but the sibling list makes the context evident.

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

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

With no annotations, the description carries the transparency burden. It discloses that requests feed a nightly queue, turnout time, optional contact, and that it's free. It doesn't mention rate limits or authentication, but for a request submission tool, this is adequate and adds context beyond raw 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 short sentences, front-loaded with the purpose via the 'suggestion box' analogy. Every word adds value, with no filler or redundant 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 simple tool with no output schema and three parameters, the description covers when to use it, what to include, and the expected turnaround. It could mention how to track a request or what response to expect, but given the tool's simplicity and the schema's coverage, it is sufficiently complete.

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

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

Schema coverage is 100%, so the schema itself documents all parameters. The description adds a bit of context for the 'contact' parameter ('if you want to hear back') and provides real-world examples, but it doesn't introduce meaning beyond what the schema already explains.

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 is for requesting missing data, using examples like pre-2015 filings and uncovered tickers, and the 'suggestion box' metaphor makes the purpose obvious. It does not explicitly name the sibling find_data tool to differentiate, so it's clear but not fully distinct.

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 it: when data is missing, and it sets expectations with the nightly ingestion queue and ~24h availability. However, it does not explicitly state when not to use it or recommend alternatives like find_data, so it lacks 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?

No annotations, but the description discloses the paid two-step workflow, the on-chain oracle read, and that cross-conversion reports both legs. It does not mention rate limits or output structure in detail, but the payment behavior is 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?

Three dense, information-packed sentences with the main purpose front-loaded. No wasted words; the structure flows naturally from core function to advanced features to alternatives.

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 complex due to payment terms and cross-conversion, and the description addresses both adequately. Given no output schema, mentioning latestRoundData and round metadata sets expectations for return values.

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 covers all parameters, so baseline is 3. The description adds meaning beyond schema by explaining cross-conversion via USD feeds with both legs reported, and by clarifying the payment flow for x_payment and asset.

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

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

Description clearly states it returns live Chainlink spot price via latestRoundData, with round metadata. The cross-conversion behavior and explicit distinction from the free `pricing` tool make the purpose unmistakable.

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

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

Explicitly contrasts with the free `pricing` tool and explains the two-step paid flow (call without x_payment for terms, then with x_payment). This gives clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden and does well by disclosing the 'indicative' nature, live on-chain reserve sourcing, and the paid two-step workflow. It stops short of explicitly stating read-only behavior or potential error conditions, but the term 'quote' and the workflow imply no trade execution.

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

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

Three sentences, each earning its place: the first defines the tool, the second explains the paid workflow, and the third points to an alternative. Information is front-loaded, with no fluff or 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?

Although there is no output schema, the description lists the key outputs and fully explains the two-step paid process. It does not describe response structure or failure modes, but for a quote tool with a clear alternative, this is sufficient. Could be slightly more explicit about the exact response format.

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 baseline is 3. The description adds meaningful context especially for x_payment, explaining the exact sequence of omitting it to get terms and then including it to settle and get data. This workflow guidance goes beyond the schema's parameter 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 provides an 'Indicative UniswapV2 swap quote from live on-chain reserves' and explicitly lists the outputs: 'amount out, execution price, and price impact'. It also distinguishes from the sibling 'pricing' tool by noting it focuses on a single trade while 'pricing' lists every price at once.

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

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

The description gives explicit when/how to use: 'call without x_payment to receive this call's exact terms... then call again with x_payment'. It also explicitly names the alternative 'The free `pricing` tool lists every price at once', clearly guiding the agent to choose the right tool.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses that the check is heuristic, follows proxies to scan actual bytecode, returns per-rule evidence, and is paid with a specific settlement flow. This provides strong behavioral insight, though it stops short of explicitly stating whether the operation is read-only or has side effects.

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

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

The description is concise and front-loaded: it opens with the tool's purpose and method, then specifies the output, payment flow, and a pointer to a free alternative. Every sentence carries value with no filler, making it efficient and well-structured.

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 (3 parameters, no output schema), the description is remarkably complete. It explains the heuristic methodology, the return format (verdict with evidence), the two-step payment process, and the availability of a free pricing alternative. This is sufficient for an agent to understand 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 input schema already describes all three parameters with high coverage (100%). The description reinforces the x_payment flow but does not add meaningful detail beyond the schema's own explanation of the payment mechanism. It neither clarifies 'chain' nor 'address' further, so the description does not significantly exceed the schema 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: a heuristic token safety check that follows proxies, scans bytecode, checks ownership/transfer restrictions, and returns a verdict with evidence. This distinctly differentiates it from sibling tools like gas_price or swap_quote, 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 gives clear usage context by explaining the two-step payment flow (call without x_payment for terms, then with x_payment) and points to the free 'pricing' tool as an alternative for price lists. However, it does not explicitly mention when not to use this tool versus other safety-related siblings like nft_scam_check.

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