Abstraxn

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

The description discloses key behavioral traits beyond annotations: the two-step payment protocol ('first call returns paymentRequired; retry with the same arguments plus paymentPayload'), the need for coin IDs rather than tickers, and the indicative pricing model. It also clarifies data source (CoinGecko) and that no account is needed, adding significant context beyond the readOnlyHint annotation.

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

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

The description is well-structured with a clear front-loaded overview, bulleted action list with prices and parameters, and a separate payment flow explanation. Every sentence adds value, and the length is justified by the tool's complexity (six actions, 16 params, payment protocol). No fluff or repetition.

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

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

Given the tool's complexity and the presence of an output schema, the description is complete: it covers all six actions, their parameters, defaults, required vs optional, pricing, the payment challenge flow, and important usage notes (e.g., search-first workflow, ID not ticker). It also acknowledges that exact charges come from the live challenge, which is essential for correct invocation.

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

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

The schema already has 100% parameter descriptions, but the description adds action-level parameter semantics: it groups parameters by action, states which are required (q, ids, id, tokens), gives examples ('bitcoin'), and clarifies defaults and constraints (e.g., 'limit 1-250, default 100'). This goes beyond the schema, though some information is redundant with schema descriptions.

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

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

The description clearly states 'Crypto market-data lookups (CoinGecko-sourced pricing and market data)' and enumerates six specific operations (search, price_feed, market_data, historical_data, trending, token_prices). This specific verb+resource combination distinguishes it from sibling tools like network.token_price by highlighting its multi-action, CoinGecko-sourced, pay-per-call nature.

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 detailed guidance for when to use each action, such as 'Call this first to resolve a coin id before using price_feed or historical_data' and 'use for "top N coins" / market overview questions'. It explains selection criteria, required parameters, and the payment flow. However, it does not explicitly mention alternative sibling tools or when not to use this tool, so it falls short of full cross-tool differentiation.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds value beyond annotations by stating 'Free, read-only, no wallet needed' and explaining the default behavior when chain is omitted (query all chains), which enriches the agent's understanding of the tool's runtime behavior.

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

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

The description is well structured with a purpose statement, use cases, and parameter guidance. It is a bit longer than the get_calls example but every sentence contributes useful information; no fluff or repetition of schema data beyond what is necessary.

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

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

For a simple tool with one optional parameter and an output schema, the description covers the core behavior, supported chains, default behavior, and practical use cases. There is no major gap; the output schema can handle return value details, so the description is 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% with a description and enum in the schema, so the parameter is well-documented. The description still adds meaning by explaining that omitting `chain` (or passing 'all') queries every resolvable chain, and by repeating the chain list for immediate reference without requiring schema lookup.

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 reading the current chain head (EVM block number or Solana slot) for a supported network, with a specific verb 'Read' and a concrete resource. It also distinguishes itself from sibling tools like network.gas_info and network.transaction_status by emphasizing read-only, free, and no wallet needed.

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: confirming network progress, correlating off-chain events, and choosing a safe starting point for log scanning. It does not explicitly name alternative tools or state when not to use this tool, but the use cases are well-defined and the parameter behavior (omit chain for all) 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond annotations: 'Free, read-only, no wallet needed' clarifies auth and cost requirements. No contradictions with annotations.

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

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

The description is concise, front-loaded with the core purpose, and every sentence adds value: purpose, usage, and required parameter. No fluff 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 single-parameter tool with a complete output schema and strong annotations, the description covers all necessary aspects: purpose, usage guidance, and parameter requirement. No gaps in essential information.

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

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

Schema coverage is 100% and the single parameter 'chain' already has a comprehensive description with an enum. The description repeats the chain list but adds no semantic meaning beyond what the schema provides, so baseline 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 'Get the current gas price and EIP-1559 fee hints for an EVM chain,' using a specific verb and resource. It distinguishes itself from sibling tools like network.blocknumber and network.token_price by focusing on gas/fee information.

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: 'Use this to estimate transaction cost or explain fees to a user before they send a transaction.' It implies when to use it but does not explicitly name alternatives or exclusions, which 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?

The description goes far beyond the annotations, detailing that the tool reads live nonce/gas/fees, never sponsors gas, never holds keys, and never enforces allowlists or spend limits. It also explains the fallback behavior for token_decimals and the privacy encryption feature. Annotations already indicated readOnly, idempotent, and non-destructive, and the description aligns perfectly while adding significant operational context.

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

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

The description is well-structured with clear sections (supported chains, token, gas, raw calldata, privacy) and front-loaded with the core purpose. While it is fairly long, each sentence adds necessary detail for a complex tool with 8 parameters. It could be slightly tighter, but overall it is efficient and well-organized.

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 (8 parameters, multiple chain-specific behaviors, raw calldata, privacy, token types) and the presence of an output schema, the description covers all relevant aspects. It explains edge cases, limitations, and additional context not in the schema. No gaps are apparent.

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

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

Schema coverage is 100%, and the description adds substantial meaning to every parameter. For example, it explains the token field can be a symbol or contract address, with chain-specific options. It clarifies that amount is in human units, that data is for raw EVM calls, and that private only works on skale-base-sepolia. This exceeds basic parameter documentation.

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

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

The description clearly states the tool's purpose: 'Build an unsigned native or token transfer transaction for a supported chain, from an explicit sender you provide.' It explicitly distinguishes itself from signing or broadcasting, making the action unambiguous. There are no sibling tools that perform a similar function, so no confusion.

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

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

The description provides clear context on when to use the tool: it is free, read-only, never signs or broadcasts, and requires an explicit sender. It also explains that gas is paid by the sender later. While there are no direct alternative tools to compare, the description gives sufficient guidance on the tool's limitations and prerequisites.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context: it is 'Free, read-only', the server never holds a caller wallet, and no balance is ever returned—only public token metadata. This directly informs the user about the tool's limitations and safety profile, exceeding what annotations alone convey.

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 succinct and well-structured, opening with the primary purpose and then covering parameter formats, limitations, required fields, and supported chains in a logical flow. Every sentence provides necessary information without redundancy, making it highly scannable for an AI agent.

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

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

For a simple read-only tool with two parameters and an output schema, the description is complete. It specifies supported chains, token input format, required fields, and behavioral limitations. The output schema covers return values, so no further elaboration is needed. The description fully equips an agent to decide when and how to invoke 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%, so the baseline is 3. The description adds value by explicitly explaining the token parameter accepts a contract address (0x…) or a symbol like USDC / USDC.e where configured, and clarifies that both chain and token are required. While the schema already says this, the description reinforces it in context, slightly elevating the score.

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 exactly what the tool does: 'Read ERC-20 token metadata — name, symbol, decimals, total supply — for a token contract on an EVM chain.' The verb 'Read' plus the resource and specific metadata fields clearly distinguish it from sibling tools like network.token_price, which would return price 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 provides clear context on when to use the tool and how to specify inputs, such as accepting contract address or symbol (e.g., USDC / USDC.e) where configured. It also notes that both chain and token are required and lists supported chains. However, it does not explicitly mention alternatives or exclusions beyond implying this is for metadata, not balances.

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=false, so the safety profile is clear. The description adds meaningful behavioral context beyond this: it names the external API (CoinGecko), states the default pair (ETH/USD), and confirms no payment or wallet is required. There is no contradiction with the annotations.

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

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

The description is a single, tightly written sentence that front-loads the core purpose and includes only high-value context (source, cost, defaults). Every phrase contributes meaning, making it an example of effective brevity.

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

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

The tool is simple: two optional, well-documented parameters and an output schema, so the description does not need to explain return values. It provides the essential context—external API, free usage, and default behavior—making it complete for an agent to select and invoke the tool appropriately in most cases.

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

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

The input schema covers 100% of the parameters, with both 'symbol' and 'vsCurrency' having clear descriptions and default values. The description's mention of 'Defaults to ETH/USD' reinforces but does not extend beyond what the schema already states, so it meets the baseline but adds no new semantic value.

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: 'Get a spot token price from a public market API (CoinGecko).' It specifies a concrete verb, resource, and source, and notes the default pair. However, it does not explicitly differentiate from the sibling tool 'market.crypto', so it misses the highest bar for sibling distinction.

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 when to use the tool (for a spot token price) and adds useful context such as 'Free — no payment or wallet needed.' It does not provide explicit guidance on when not to use it or mention alternatives like 'market.crypto' for broader market data, leaving usage somewhat implied.

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=true, idempotentHint=true, and destructiveHint=false. The description adds 'Free, read-only' (redundant) and mentions supported chains, but no new behavioral traits such as error handling, rate limits, or return behavior. It is consistent with annotations.

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

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

The description is concise and front-loaded, but the chain list duplicates the schema enum, making it slightly redundant. Overall it is efficient and well-structured without being 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?

For a simple read-only tool with complete schema, annotations, and output schema, the description adequately covers purpose, usage, and required inputs. It lacks explicit exclusions or error-handling notes, which are not necessary given the tool's simplicity and existing metadata.

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 100% of parameters with descriptions and an enum for chain. The description repeats the chain list and required-parameter info, adding no new semantic meaning beyond the schema. Baseline 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 function: 'Check the status of a transaction' with explicit support for both EVM and Solana. This distinguishes it from sibling tools like network.blocknumber or network.token_info, which serve different purposes.

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

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

The description provides explicit use cases: 'confirm a transfer landed, debug a failed transaction, or report status to a user,' and notes that both chain and transaction_hash are required. It does not mention alternatives or when-not-to-use, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the bar is lower. The description adds significant behavioral context: the x402 payment flow (first call returns paymentRequired, retry with paymentPayload), pagination loops, default excludeFields behavior, and the two modes for solar_rgb_image (Mode A with id, Mode B with lat/lng). It does not contradict any annotation. Slightly less than 5 because the description is lengthy and some details (like defaults) are also in the schema.

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

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

The description is well-structured with a bulleted list of actions, making it scannable. It front-loads the core concept (paid per call, pick one action). However, it is verbose, repeating 'same parameters' for partial variants and including many examples. Given the complexity (11 actions, 34 parameters, payment protocol), the length is justified. A score of 5 would require slightly more conciseness, such as summarizing partial variants more compactly.

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

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

Given the high complexity (34 parameters, 11 actions, nested objects, payment protocol, output schema exists), the description is remarkably complete. It covers every action with required and optional parameters, defaults, special behaviors (modes, pagination, field exclusion syntax), and the two-step payment flow. It also notes that prices are indicative. The output schema is not shown, but the description does not need to explain return values. No gaps are apparent.

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 substantial value beyond the schema: it explains the payment flow for paymentPayload, the colon-separated nested syntax for excludeFields, the two operational modes for solar_rgb_image, and the constraint that locationRestriction must be a nested circle object (not bare lat/lng/radius). It also provides default values and usage patterns (e.g., 'pageToken must be the exact nextPageToken from that earlier response'). This enriches the parameter semantics significantly.

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 the tool's purpose: 'Places, solar, and aerial-view lookups, paid per call directly from the caller's own wallet via the x402 protocol'. It enumerates 11 distinct actions, each with a brief description of what it does and how it differs from others (e.g., full vs partial, search vs details). This clearly distinguishes between sibling actions and states the core resource (places, solar, aerial 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?

The description provides explicit guidance for each action: required parameters, optional parameters, defaults, and critical constraints (e.g., 'do NOT send a bare top-level latitude/longitude/radius' for nearby_search_full, 'do not invent or guess it' for placeId and videoId). It also explains the two-step payment protocol ('first call returns paymentRequired; retry with paymentPayload'), pagination mechanics, and when to use partial vs full actions (cheaper, fewer fields). No alternative tools are needed since siblings are unrelated.

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 thoroughly explains the payment flow (first call returns paymentRequired, retry with paymentPayload), the batch processing nature, and the fact that response shape is passed through from upstream provider unchanged. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as true/false, and the description adds significant behavioral context beyond these (payment requirements, two modes, response shape variability).

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

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

The description is well-structured, front-loading the core purpose and payment model, then breaking down modes and requirements. It is slightly verbose in the parameter details section (could be more terse), but every sentence serves a purpose and the structure aids readability.

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

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

Given the complexity (3 parameters, nested objects, payment protocol, output schema exists), the description is largely complete. It covers input requirements, payment flow, mode selection, result shape variability, and optional filtering. It does not explicitly state what happens on error or how to interpret the response beyond 'pass through', which is a minor gap, but the output schema helps mitigate this.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds significant value by explaining the two modes of operation (fuzzy match vs reverse lookup), the requirement for at least one non-empty field per record (with specific clarification about empty arrays), and the purpose of match_condition_fields. It also clarifies that record_id is caller-chosen for correlation.

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 person/social-profile identity for a batch of records, explicitly distinguishing between fuzzy match and reverse lookup modes. It provides specific verb+resource (resolve person/social-profile identity) and explains the two operational modes, making it easy to understand what the tool does and how it differs from siblings.

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

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

The description provides explicit guidance on when to use each mode (fuzzy match vs reverse lookup), details the required inputs per record, explains the payment protocol (x402, pay-per-call, first call returns paymentRequired), and describes the optional match_condition_fields filter. This is comprehensive and leaves no ambiguity about 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?

It discloses the two-step payment flow (paymentRequired then paymentPayload), pricing, and that the exact charge comes from the live challenge. This goes well beyond the readOnly/idempotent annotations, providing crucial behavioral context for the agent.

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

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

The description is well-structured with bullet-point action breakdowns and front-loads the most important info (paid, x402, no account). Every sentence earns its place; 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?

With an output schema present and annotations covering safety, the description fully covers action selection, required params, pricing, and the payment retry handshake. It is complete enough for an agent to invoke correctly without additional context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters by action and marking which are required vs optional (e.g., 'Requires origin, destination, departureDate'), which the schema alone doesn't explicitly convey. Enum meanings are already in the schema, so no extra credit there.

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 performs flight and hotel search via Google Flights and Google Hotels, using specific action subtypes. It distinguishes from sibling tools (all crypto/network unrelated) and provides a specific verb and resource.

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: pay-per-call, x402 protocol, no account needed, and explicit required vs optional parameters for each action. It doesn't explicitly state when not to use or name alternatives, but no comparable siblings exist.

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 mark the tool as read-only and non-destructive, and the description adds important deployment limitations: forecast capped at 3 days, history only yesterday, marine limited to 1 day with no tides. It also includes an appropriate safety disclaimer about informational use.

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

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

The description is long but efficiently organized: a lead sentence establishes scope, followed by one bullet per action with its relevant parameters and limitations. Every sentence adds non-redundant information that an agent needs for correct invocation.

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 six-action tool, the description covers all actions, location formats, per-action parameter applicability, deployment limits, and caveats. The presence of an output schema covers return-value details, so the description is complete for selection and invocation.

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

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

Although the schema covers all parameters, the description adds real operational meaning: q format examples (city, lat,lon, postal code, IATA), which parameters apply to which action, and constraints like yesterday-only dates. This goes well beyond the schema's basic 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 identifies the tool as a weather data provider covering current conditions, forecast, astronomy, history, marine, and location search. This specificity distinguishes it from unrelated sibling tools like network, crypto, and market 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?

Each action is documented with its own usage context, including explicit guidance to use 'search' first for approximate place names. Deployment-specific constraints like the 3-day forecast cap and yesterday-only history clarify exactly when requests will fail.

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=true and idempotentHint=true, but the description adds vital behavioral details: the payment protocol, the two-step paymentRequired flow, and the note that prices are indicative while exact charges come from the live challenge. This goes beyond the structured annotations and helps the agent manage the payment round-trip.

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 structured as a bullet list with one line per action, each containing price, scope, and required parameters. It is front-loaded with the main purpose and payment model, and no sentence is redundant.

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

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

For a tool with 12 parameters and a pay-per-call flow, the description covers all major aspects: payment challenge handling, per-action requirements, optional parameters, and the nature of results (e.g., tx_simulate returns gas estimate and trace). The presence of an output schema means return values don't need to be detailed, but the description still gives a preview.

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

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

The schema covers all 12 parameters with descriptions, so baseline is 3. The description adds per-action parameter requirements, examples (e.g., 'vitalik.eth' for ens_resolve, chain names like 'ethereum', 'base', 'solana'), and clarifies which parameters are required for each action. This makes it easier to construct a correct call.

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 'Multi-chain wallet, token, ENS, and transaction-simulation lookups' which clearly states the tool's function. It enumerates seven distinct actions (wallet_balances, wallet_transactions, etc.), each with a specific purpose, distinguishing it from sibling tools focused on network or market 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 provides explicit guidance on which action to use for each lookup, including required parameters for each. It notes the pay-per-call x402 flow and the need to retry with paymentPayload, but it does not explicitly contrast with sibling tools or state when this tool should not be used.

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