Abstraxn Agent Layer

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds crucial context: the per-call payment via x402 from the caller's wallet, the fact that the first call returns paymentRequired and must be retried with paymentPayload, and that prices are indicative with the exact charge from the live payment challenge. This goes well beyond the annotations and illuminates the actual call flow.

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 lengthy but exceptionally well-structured with bulleted actions, pricing, required parameters, and defaults. Every sentence earns its place, and the front-loaded payment model gives immediate context. The structure is scannable and directly maps to the complex multi-action tool, making the length justified.

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 actions and 16 parameters, the description covers each action's purpose, pricing, required and optional parameters, defaults, and the non-trivial payment challenge flow. Since an output schema exists, there is no need to describe return values. Minor omissions like supported chains for token_prices are not essential for tool 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 has 100% description coverage, the description enriches parameter understanding by grouping parameters per action, marking required parameters (e.g., 'Requires q', 'Requires ids', 'Requires tokens'), and clarifying critical semantics like using coin IDs rather than tickers. It also explains the paymentPayload lifecycle, which the schema only labels as a generic object.

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 'Crypto market-data lookups' with CoinGecko-sourced pricing and market data, establishing a specific verb+resource. It further enumerates six distinct actions (search, price_feed, market_data, historical_data, trending, token_prices), each with a clear functional role, making it easily distinguishable from sibling network/web3/travel tools.

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

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

The description provides excellent within-tool usage guidance, such as 'Call this first to resolve a coin id before using price_feed or historical_data' and explains market_data is for 'top N coins' / market overview questions. However, it does not explicitly contrast alternatives across sibling tools (e.g., when to use network.token_price instead), so it stops short of fully 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context beyond these: it clarifies that the operation is free, requires no wallet, and that omitting chain (or passing 'all') queries every resolvable chain in one call. This extra detail about multi-chain behavior and cost is valuable beyond the structured 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 well-structured: the first sentence states the core purpose, the second paragraph gives concrete use cases, and the third covers parameter details. It is compact and front-loaded, with no filler. The chain list repetition is slightly redundant with the schema but serves as helpful inline reference.

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, the description correctly focuses on usage context rather than return format. It covers the key aspects: purpose, supported networks, use cases, default behavior, and non-functional properties (free, read-only, no wallet). This makes the tool fully understandable for an agent to select and invoke correctly.

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

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

The input schema already documents the 'chain' parameter with a full enum and description, including the default behavior for 'all'. Schema description coverage is 100%, so the bar for added value is lower. The description reiterates the chain list and default behavior but adds little new semantic meaning beyond what the schema provides.

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 reads the current chain head (EVM block number or Solana slot) for a supported network. It uses a specific verb ('Read') and resource, and distinguishes it from siblings like network.transaction_status and market.crypto by focusing on block height.

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 use cases: confirming network progression before a transaction, correlating off-chain events with on-chain height, and choosing a safe starting point for log scanning. It does not explicitly name alternative tools, but the context implies when this tool is appropriate versus transaction status or token pricing tools, and notes it is free and read-only.

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, destructiveHint. The description adds useful context: 'Free, read-only, no wallet needed' and the requirement that 'chain' is required. This adds value beyond the annotations without contradicting 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 two sentences, front-loaded with the core purpose, and includes only necessary details. 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?

This is a simple single-parameter tool with an output schema available. The description sufficiently covers what the tool does, when to use it, and the required chain input. No missing critical 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 description repeats the supported chains and requirement, but adds no new meaning beyond the schema. The baseline of 3 applies because the schema already documents the only parameter fully.

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

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

The description clearly states the verb and resource: 'Get the current gas price and EIP-1559 fee hints for an EVM chain.' This is specific and differentiates from sibling tools like network.blocknumber or market.crypto.

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

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

Provides clear usage context: 'Use this to estimate transaction cost or explain fees to a user before they send a transaction.' However, it does not explicitly mention when not to use or name alternative tools, so it stops short of fully distinguishing from siblings.

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

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

The description extensively discloses behavioral traits beyond annotations: it's read-only, never signs or broadcasts, does not hold keys, enforces no allowlists/spend limits, and requires 'from' always. This complements readOnlyHint=true, idempotentHint=true, and destructiveHint=false perfectly, adding concrete details about live reads (nonce/gas/fees) and privacy 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 sections and bullet points, front-loading the key purpose. All sentences add value, but it's somewhat lengthy; could be slightly more concise without losing clarity.

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

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

Given the tool's complexity (8 parameters, 15 chains, mixed EVM/Solana semantics, privacy options), the description is thoroughly complete. No output schema is needed for return values as the description covers the transaction building process comprehensively.

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 significant semantic value beyond the schema: explains token field semantics (Solana vs EVM, raw contract address, decimals fallback), gas responsibility, raw calldata usage for EVM, and privacy specifics. Minor improvement possible with more examples or edge cases.

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: preparing an unsigned native or token transfer transaction for supported chains. It specifies the verb 'build', the resource 'unsigned transaction', and distinguishes from broadcasting/signing tools. The scope and limitations are explicit.

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

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

The description provides explicit guidance on when to use this tool (free, read-only, never signs or broadcasts) and lists supported chains and token types. However, it does not explicitly state when NOT to use it or provide alternative tools for signing or broadcasting, though the sibling tools indicate this is a unique capability.

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 read-only, idempotent, and non-destructive hints, but the description adds meaningful behavioral context: the server never holds caller wallets, so no balance is returned, and symbol lookups only work on configured chains. This goes well beyond the structured annotations and clarifies limits.

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

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

The description is concise and front-loaded, with the core purpose in the first sentence. Each subsequent sentence adds necessary operational detail (token format, no balance, required fields, supported chains) with no filler. The organized structure makes it easy for an agent to scan.

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 present, the description is complete. It covers what the tool does, how to pass parameters, safety characteristics, supported chains, and requirements. The output schema handles return value details, so no further description is needed.

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 value by restating that both parameters are required, providing concrete examples like 'USDC' / 'USDC.e', and noting that symbol lookup is conditional on chain configuration. This extra context justifies a score 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 a specific verb and resource: 'Read ERC-20 token metadata — name, symbol, decimals, total supply — for a token contract on an EVM chain.' This clearly distinguishes the tool from siblings like network.token_price by focusing on metadata, not pricing, and explicitly notes it never returns balances.

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 for when to use this tool: it is free, read-only, and returns only public metadata. It also explains the token parameter format (address or symbol) and caveats that symbol lookup depends on chain configuration. However, it does not explicitly name alternative tools or state 'use X instead' for cases like price queries, which keeps it just below 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?

Annotations already declare readOnly, idempotent, open-world, and non-destructive. The description adds that no payment or wallet is needed, which is useful cost/auth context beyond annotations. It doesn't disclose error/rate-limit behavior, but with annotations covering safety, this is adequate.

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

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

The description is three concise sentences, front-loaded with the core function, then cost and default behavior. Every sentence adds value.

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 simplicity, the presence of a rich output schema, full parameter coverage, and annotations, the description covers the essential behavioral context (public API, free, defaults). No major gaps for an AI agent to correctly select and invoke this 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?

Input schema covers both parameters with descriptions and defaults. The description's 'Defaults to ETH/USD' adds no new information beyond schema (symbol defaults to ethereum, vsCurrency to usd). With 100% schema coverage, the description's contribution to parameter meaning is minimal, but not incomplete.

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 fetches a spot token price from CoinGecko, using a specific verb and resource. It does not explicitly compare to sibling tools like market.crypto, but the scope is well defined. Given the mention of CoinGecko and spot price, it is easy to distinguish from other network tools, though not explicitly.

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 context that the API is public and free, and mentions default ETH/USD, which guides basic usage. However, it does not state when to prefer this tool over market.crypto or other siblings, nor any exclusions (e.g., not for historical data). Usage is implied but not explicitly detailed.

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 true and destructiveHint false. The description adds useful context beyond annotations: 'Free, read-only' and the support for both transaction hash formats. No contradictions exist.

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

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

The description is front-loaded with purpose, followed by usage context, requirements, and a chain list. It is slightly redundant with the schema's enum list, but overall it is compact and every section serves a purpose.

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 rich annotations, the description covers all necessary context: use cases, supported networks, parameter requirements, and safety profile. It lacks only minor behavioral details (e.g., pending timeouts) that are not essential for this 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% with detailed descriptions for both chain and transaction_hash, including enum values and format hints. The description adds little beyond repeating requirements and chain list, so it does not meaningfully enhance schema-provided semantics.

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 'Check the status of a transaction' – a clear verb+resource pair. It explicitly states support for both EVM and Solana, distinguishing it from sibling tools like network.gas_info or network.blocknumber. The purpose is unambiguous.

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

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

The description gives explicit use cases: 'confirm a transfer landed, debug a failed transaction, or report status to a user.' It also notes both parameters are required. While it does not name alternatives or exclusion criteria, the context is clear and sufficient given the sibling set.

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?

Discloses the two-step payment flow (paymentRequired → retry with paymentPayload), exact pricing per action, default excludeFields behavior, and the nuance that pixelSizeMeters is not schema-enforced. Adds significant behavioral context beyond the readOnly/idempotent hints, with no contradictions.

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?

Dense but well-organized: payment model first, then each action on its own line with all applicable params and defaults. No fluff; every sentence carries operational value. Length is justified given 34 parameters and 11 actions.

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?

Fully covers the tool's complexity: payment, per-action requirements, exclusions, pagination, mode selection, and conventions not enforced by schema. Output schema exists, so return values need no explanation. Nothing critical is missing.

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

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

Although schema coverage is 100%, the description adds meaning: per-action required/optional grouping, defaults, allowed ranges, mode conditionality (id OR lat/lng), and nested structures (locationBias/locationRestriction). This surpasses baseline by clarifying relationships between parameters.

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 names a specific combined resource (Places/solar/aerial-view lookups) and enumerates 11 distinct actions with precise verbs and parameters. Clearly distinguishes from sibling tools that cover crypto, network, social, travel, and web3 domains.

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

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

Provides explicit when-to-use guidance: partial vs full actions, text vs nearby search, rendering vs polling, page token repetition rules, and exactly-one-mode constraints. Emphasizes do-not-invent ids and correct structure of locationRestriction, giving clear exclusions and 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?

The description goes far beyond the annotations (readOnly, openWorld, idempotent, non-destructive) by detailing the x402 payment protocol, two operating modes, the requirement to retry with paymentPayload, the dynamic response shape, and the non-trivial field validation rules. 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 well-structured with clear paragraphs and front-loaded purpose. However, it is somewhat verbose (e.g., repeats payment details in the first and last paragraphs). It could be slightly tightened without losing clarity, but overall every sentence adds value.

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 (payment flow, batch processing, dynamic response), the description covers all major aspects: modes, required fields, payment retry, optional filter, and response shape. It is missing only minor details like error handling or rate limits, but is otherwise 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?

Despite 100% schema description coverage, the description adds substantial meaning: it explains the two modes (fuzzy match vs reverse lookup), the meaning of empty arrays, the match_condition_fields filter, and the paymentPayload flow. This is critical context that the schema alone does not convey.

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

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

The description clearly states the verb 'resolve' and resource 'person / social-profile identity', specifies batch processing, and distinguishes the payment mechanism. The title reinforces the purpose. No sibling tools overlap, so differentiation is implicit.

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 (identity resolution from names/emails/phones) and how to handle the two-step payment flow. It does not explicitly exclude alternatives, but given no similar sibling tools, the guidance is sufficient. It could be more explicit about prerequisites but is clear overall.

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 well beyond the annotations, disclosing that calls are paid per use via x402 from the caller's own wallet, no account needed, pricing is indicative, and the two-step payment challenge flow. This explains the tool's key behavioral trait (pay-per-call) that annotations alone don't 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 lengthy but well-structured with bullet points and action-specific blocks. Every sentence provides necessary information (pricing, parameters, payment flow). It is appropriately detailed for a tool with 18 parameters and two modes, though slightly dense.

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 complex tool with two actions, 18 params, and a payment protocol, the description covers the purpose, usage, required params, payment flow, and pricing. An output schema exists, so return values are covered. The description gives the agent everything needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters under each action, marking which are required vs optional, and explaining the paymentPayload special role. This helps the agent understand the parameter relationships beyond individual schema entries.

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 'Flight and hotel search' with a clear verb and resource, and distinguishes the two actions (flight_search and hotel_search) with their specific purposes. It is clearly differentiated from sibling tools like network.* or market.crypto, which are unrelated to travel.

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 detailed usage context: how to choose an action, required and optional parameters per action, and the exact payment flow (first call returns paymentRequired, then retry with paymentPayload). It doesn't mention alternatives or exclusions, but sibling tools are unrelated so no explicit 'when not to use' is needed.

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?

Beyond the read-only annotation, it discloses deployment-specific limits: forecast capped at 3 days, history restricted to yesterday, marine limited to 1 day with no tides, and rejection before a provider call. It adds a safety disclaimer that results must not be used for aviation, marine navigation, or emergency planning.

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 earns its length: a one-sentence overview, a clear `q` rule, and six bulleted actions with their constraints. It is front-loaded and has no filler; every sentence conveys an operational requirement or caveat.

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 six parameters, six actions, an output schema, and deployment plan caps, the description covers all details an agent needs to select and invoke correctly. It explains date restrictions, defaults, and safety caveats, so the output schema handles return values and the description handles behavior.

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

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

Schema coverage is 100%, yet the description adds substantial meaning: accepted `q` formats (city, lat,lon, postal code, IATA), per-action parameter applicability, defaults, and server-side constraints. It clarifies which params matter for which action, going far 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 opens by identifying the tool's domain and capabilities: 'Weather data from a global weather data provider — current conditions, short-range forecast, astronomy, historical, marine, and location search.' It enumerates six concrete actions, which is specific and clearly separates it from non-weather sibling 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?

It gives explicit per-action guidance and even directs the agent to use `search` first when only an approximate place name exists. It also states constraints like 'history ... must be yesterday' and notes when to omit `days`, making when-to-use unambiguous.

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?

Beyond the readOnlyHint=true annotation, the description discloses significant behavioral traits: the pay-per-call mechanism with indicative prices, the exact charge determined by the live payment challenge, and the two-step payment flow with `paymentPayload`. It also notes that no Abstraxn account is needed. These details are not deducible from annotations alone and add substantial transparency. There is no contradiction 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 well-structured with a clear overview sentence, a bulleted list of actions with prices and parameter requirements, and a concise note about the payment challenge flow. Every sentence provides useful information, and the format is easy to parse. Despite its length, it is not verbose or 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?

Given the tool's complexity (7 actions, 12 parameters, payment protocol), the description is remarkably complete. It covers all actions, their costs, required and optional parameters, the payment handshake, and clarifies the no-account requirement. With an output schema present and high schema coverage, it doesn't need to explain return values. There are no significant gaps.

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 descriptions for all 12 parameters (100% coverage), so baseline is 3. The description adds value by explicitly mapping which parameters are required or optional per action, and by providing examples like 'vitalik.eth' for ENS. This helps an agent select the correct parameters for a given action, which the schema alone does not do (the schema only requires `action`, not per-action prerequisites).

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 starts with a specific verb and resource: 'Multi-chain wallet, token, ENS, and transaction-simulation lookups'. It then enumerates seven distinct actions, each with a precise verb phrase (e.g., 'wallet_balances: token balances for a wallet across 20+ chains'). This clearly differentiates from sibling tools like market.crypto and network.token_price, which likely cover different lookup domains.

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 for when to use each action, including required and optional parameters for each. For example, 'Requires `chain` and `address`' for wallet_balances, and 'Optional `chain`, `limit`' for wallet_transactions. It also explains the payment flow (first call returns paymentRequired, retry with paymentPayload). However, it doesn't explicitly mention alternatives or exclusion cases like 'use network.token_price for simple price queries', so it lacks explicit when-not guidance.

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