ANON Base USDC Lending Decision

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds further behavioral context: it returns a free live analysis, uses current Base contracts and Pyth price data, includes a referral URL, and explicitly states it never connects a wallet or moves funds. This is valuable beyond annotations, though it does not discuss rate limits or potential errors.

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 packs all relevant information without repetition. It could be slightly improved by breaking into two sentences, but it is efficient and front-loads the key purpose ('Return a free live, read-only Avantis analysis').

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 7 parameters, no output schema, and no param descriptions, the description provides a high-level summary of outputs (list of metrics) but lacks detail on return structure or how individual parameters affect results. Annotations cover safety, but the description does not fully compensate for missing output schema or param semantics. The mention of a referral URL is helpful but not elaborated.

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

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

Schema description coverage is 0%, meaning no descriptions for individual parameters. The description does not explain any parameter's meaning or constraints beyond what the schema's name and type provide (e.g., pair, leverage, direction). While parameter names are mostly self-explanatory, the description fails to clarify format or edge cases (e.g., holding_hours maximum 720, stop_move_percent exclusiveMin). This is a significant gap.

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

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

Description clearly states it returns a free live, read-only Avantis analysis with a comprehensive list of metrics (opening/closing/holding fees, spread, etc.). It distinguishes from sibling tools like get_base_usdc_lending_rates_offer which deal with USDC lending or execution routes.

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?

Description explicitly states what the tool does NOT do: 'never connects a wallet, gives directional advice, constructs a transaction, or moves funds.' This sets clear boundaries. However, it does not explicitly compare to sibling tools or provide when-to-use vs when-not-to-use beyond these negations.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description aligns, adding detail that it does not sign, pay, settle, or return paid comparison, and lists included gates. No contradiction.

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 well-structured sentence that front-loads the key return value. It is concise but could be more scannable with bullet points for protocols and gates.

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 5 optional parameters, the description adequately explains the tool's output (a URL) and its read-only nature. It covers protocols and gates. However, it does not explicitly explain how the parameters influence the URL or comparison.

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 lack descriptions in the schema (0% coverage) and the description provides no explanation of what each parameter means or affects. The parameter names and defaults are present but their semantics are not elaborated.

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 returns a specific URL for comparing lending rates across multiple protocols. It explicitly differentiates itself as discovery-only, distinguishing it from sibling tools like get_base_usdc_paid_offer.

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 non-committal comparison ('Discovery only'), but does not explicitly contrast with sibling tools like get_base_usdc_preview or get_base_usdc_paid_offer. The title's 'Recommended' suggests it's a first step, but no direct 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?

Description aligns with annotations (read-only, idempotent, non-destructive) and adds context that the quick tier reports timeliness and expiry but not the movement itself, enhancing transparency beyond annotations.

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

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

Two sentences, front-loaded with purpose and behavioral constraints; no wasted words.

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

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

For a tool with 6 parameters and no output schema, the description covers purpose and behavior but omits parameter meanings, reducing completeness for agent decision-making.

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

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

Schema description coverage is 0%, yet the description only mentions the 'tier' parameter implicitly. It does not explain the other five parameters (capital_usdc, current_protocol, etc.), leaving the agent without guidance on their meaning or usage.

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 the exact public URL, price, parameters, and headers for specific tiers, and explicitly says it is discovery only, distinguishing it from execution 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?

Tells when to use (get offer details) and when not to (does not sign/pay/settle), but does not explicitly name sibling tools for 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: 'reads a bounded local snapshot' and 'never moves funds or initiates payment.' This aligns with annotations and provides extra safety reassurance.

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 main output listed first. Every word adds value, and there is 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?

Given zero parameters, comprehensive annotations, and no output schema, the description sufficiently explains the return items and safety. It could be slightly more specific about the output format, but for a preview tool the current level is adequate.

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

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

The input schema is empty with 100% coverage, so the description does not need to add parameter details. Baseline of 4 is appropriate as no parameters exist.

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 returns current market leaders, a risk-scored sample, and a trigger. The verb 'Return' and specific resource 'free Base native-USDC market leaders' make the purpose unambiguous. It also distinguishes from sibling tools that are more focused on specific offers or analyses.

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 a quick read-only preview by stating it reads a bounded local snapshot and never moves funds. However, it does not explicitly guide when to use this tool versus alternatives, nor does it mention any exclusions.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral detail: 'Discovery only; it does not sign, pay, settle, or return paid data', reinforcing the read-only, idempotent nature and clarifying that the URL is not the paid data itself.

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: the first lists the return contents, the second clarifies the tool's boundaries. Every word is functional, no redundancy, front-loaded.

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

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

Given no output schema, the description adequately specifies what the URL contains (rates, deltas, evidence) and what it does not do. Lacks format details of the x402 URL, but that is acceptable for a 0-parameter discover tool with clear annotations.

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, and schema coverage is 100%. Per guidelines, baseline is 4 for no parameters. The description adds no parameter information, but none is needed.

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

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

The description clearly states the tool returns a specific agent-only x402 URL with current Aave, Compound, Moonwell rates, APY deltas, and evidence. It distinguishes from siblings like get_base_usdc_lending_rates_offer and get_base_usdc_paid_offer by emphasizing it is discovery-only and does not return paid data.

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

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

The description implies use for risk alert discovery but does not explicitly state when to use this tool versus siblings like get_base_usdc_preview or quote_execution_route. No direct guidance on prerequisites or 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?

The description adds significant behavioral detail beyond the annotations: it returns an unsigned transaction, discloses the 10-bps fee, explains route providers (KyberSwap, Relay), and lists validations performed. This complements the read-only/idempotent hints and does not contradict them.

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 sentences, each adding value: core purpose, route types and fee, and safety disclaimer. No unnecessary words 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 absence of an output schema, the description adequately explains that the return is a live, validated unsigned transaction route with fee details. It could elaborate on the route structure, but the current level is sufficient for an agent 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?

The description explains the core parameters (tokens, chains, amount, slippage default) and compensates for the low schema coverage (14%). However, it does not detail the user_address pattern or chain ID enums, though those are self-explanatory from 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 that the tool returns a live, validated unsigned transaction route for non-custodial swaps or USDC bridges, specifying the fee and routing providers. It distinguishes itself from sibling tools which focus on lending rates, previews, and analysis.

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 when to use the tool (for quoting swaps/bridges) and provides context for cross-chain routes (requires at least 25 USDC). It implicitly excludes signing/submitting by stating it never signs or holds funds, but lacks explicit 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.