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

With no annotations, the description carries the full burden and does substantial work: it discloses the 14-day data window, the cursor pagination contract (nextStartingAfter -> startingAfter), per-action credit costs, and the fact that actual credits appear in response headers. It omits auth/permission requirements and failure behavior, but the cost and pagination disclosures are genuinely valuable.

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 core purpose and pagination contract are front-loaded in the first two sentences, and the bulky detail is compressed into readable bullet tables. The credit table is long and explicitly flagged as indicative and volatile, but it is decision-relevant cost data rather than filler.

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 an 8-parameter composite read tool with no annotations and no output schema, the description covers the essentials: valid combinations per action, pagination, and cost. It does not describe return shapes per action, but for read-only query actions with a response-header cost signal, an agent has enough to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value the schema cannot: the valid action-to-blockchain and blockchain-to-network combinations, which the flat enums do not express. It also restates the pagination cursor usage, reinforcing the schema description.

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

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

States a specific verb (Query) and resource (latest EVM address data) with an explicit scope of last 14 days, then enumerates the five concrete actions. The 'EVM' qualifier cleanly separates it from the sibling utxo/solana/xrp/kaspa address 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 action/blockchain/network matrices implicitly constrain valid usage, which is helpful routing information. However, there is no explicit when-to-use or when-not-to-use guidance, and no direct differentiation from the sibling *_address_latest tools beyond the blockchain family.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses cursor-pagination mechanics (pass nextStartingAfter as startingAfter), the mainnet-only restriction, and cost behavior including per-action credit estimates and the caveat that real spend is returned in response headers. It omits auth requirements and any note on which action pagination applies to, but the disclosed operational traits go well beyond 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?

Front-loaded with the core purpose and the one non-obvious usage rule (pagination), then cleanly sectioned bullets for actions, networks, and credits. The credits block is somewhat boilerplate-heavy with two identical 918 figures plus a disclaimer, which is the only place the text stops earning its space.

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 7-parameter, two-action tool with full schema coverage but no annotations and no output schema, the description supplies the essential missing context: valid actions, valid network, pagination handoff, and cost profile. The one gap is that it never says which action returns the nextStartingAfter cursor, leaving the agent to infer it applies to list-transactions rather than get-balance.

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 address, network, action, limit, sortingOrder, startingAfter, and context. The description's pagination sentence essentially restates the startingAfter schema text and the action bullets restate the action enum, so it adds little beyond the structured fields — baseline 3.

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

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

The description states a specific verb and resource ("Query latest Kaspa address data") and enumerates the two concrete actions, get-balance and list-transactions, so an agent knows exactly what it can do. The chain name in the tool name plus description distinguishes it from evm_address_latest, solana_address_latest, xrp_address_latest, and utxo_address_latest, though the text itself never explicitly contrasts with those 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?

Usage is implied rather than stated: the action list and the "mainnet (only)" note tell the agent the valid modes, and the per-chain tool name implies this is the Kaspa-specific entry point. There is no explicit when-to-use/when-not guidance or reference to an alternative (e.g., a generic address tool) that would push this above minimum viability.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the 14-day data window, the cursor-pagination contract (feed nextStartingAfter back as startingAfter), supported networks, and per-action credit costs with a caveat that actual spend is in response headers. It does not address auth/permission requirements or rate limits, but the read-only query nature is clear from 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?

Content is front-loaded (scope + pagination mechanics first, then actions, networks, credits) and the bullet structure is scannable. The credit table is slightly verbose but is clearly delineated and relevant to cost-aware 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 7-parameter, multi-action tool with no annotations and no output schema, the description covers the important ground: action semantics, networks, pagination, and cost. Minor gaps remain around limit/sort interactions and response shape, but the essentials for correct invocation are present.

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, but the description adds real meaning beyond the enum labels by explaining what each action returns (SOL balance, transactions, SPL tokens held) and by specifying the exact pagination round-trip for startingAfter. It leaves limit, sortingOrder, and context unexplained, but those are fully documented in 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 gives a specific verb+resource ('Query latest Solana address data') scoped to a 14-day window and enumerates the three actions, so an agent knows exactly what class of data it returns. It names the chain (Solana), which implicitly separates it from the evm/utxo/xrp/kaspa siblings, but it never explicitly says 'use this for Solana addresses instead of evm_address_latest'.

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 action list and the 14-day window imply when each mode applies, and the pagination note tells the agent how to iterate, but there is no explicit when-to-use/when-not guidance or routing to sibling tools. Usage is inferred rather than stated.

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

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

With no annotations, the description carries the full burden and explicitly notes 'no API call, no credits consumed,' which is key behavioral information. It also discloses detailed content such as retry strategy, HMAC security, and rate-limit penalty multipliers, going well beyond a generic 'returns info' statement.

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

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

The description is front-loaded with the critical 'no API call, no credits consumed' caveat and uses a compact bullet list. Each bullet covers a distinct action without wasted prose, making it highly scannable for an 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 reference-documentation tool with no output schema and no annotations, this description is complete enough: it defines all five actions and gives sufficient detail about their content. It also clarifies side effects (none) and cost implications (none), covering the main contextual risks.

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 significant meaning by explaining each allowed action enum value in detail (e.g., callbacks covers URL requirements, 5 retries, HMAC). This transforms enum names into actionable context and compensates fully beyond the schema's short parameter 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 states this is CryptoAPIs reference documentation with no API call or credits consumed, and enumerates five specific topics (blockchains, errors, credits, callbacks, limits). This clearly identifies it as an informational tool distinct from domain siblings like aml.

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 bulleted actions give clear contexts for when to use the tool, such as looking up error codes, credit structures, callback mechanics, or rate limits. It does not explicitly name alternatives or exclusion conditions, so it stops short of a full when/when-not specification.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the 14-day data window, per-action pagination mechanics (cursor via 'nextStartingAfter' vs. limit/offset), and per-action credit costs. It stops short of describing return payloads, auth, or rate-limit behavior, so not a 5.

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?

Front-loaded with the purpose and well-bulleted, but the three near-identical blockchain lists and the full per-blockchain credit table are repetitive and inflate the description substantially. Structure is good; economy is not.

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 9-parameter, no-annotation, no-output-schema tool, the description covers actions, supported chains, networks, pagination, and cost. The remaining gap is that it never characterizes what each action returns (balance value vs. transaction list fields), which a reader must infer from the action names.

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 already 100%, but the description adds conditional semantics the schema cannot: 'startingAfter' only applies to list-transactions (fed from 'nextStartingAfter'), while 'limit'/'offset' apply to list-unconfirmed-transactions. This conditional binding is genuine added meaning beyond the flat 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?

States a specific verb and resource with scope: 'Query latest UTXO address data (last 14 days)', then enumerates the three concrete actions. The UTXO framing implicitly separates it from evm/solana/xrp/kaspa siblings, but the description never names them explicitly, so it stops short of a 5.

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?

Gives clear per-action routing (which pagination scheme applies to each action, and which blockchains each action supports), which is real when-to-use guidance. It lacks any explicit when-NOT-to-use or sibling alternative selection rules, so it is clear context without exclusions.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses pagination behavior, supported networks, and per-action credit costs, including the caveat that credits are indicative and actual spend appears in response headers. It does not state auth requirements, rate limits, or explicitly confirm read-only behavior, so significant gaps remain for a no-annotation tool.

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

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

The purpose is front-loaded, followed by pagination guidance, action descriptions, networks, and credits in a readable bulleted structure. Most sentences earn their place, though the credit cost block and disclaimer add length that could be seen as supplementary rather than essential to 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?

Given a multi-action query tool with no output schema and no annotations, the description supplies the action meanings, networks, pagination cursor mechanics, and credit model. That is enough for correct invocation, though it stops short of describing authentication, error behavior, or return shapes beyond the implied action outcomes.

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 meaning beyond the schema by explaining what each action enum value does (balance, transactions, next sequence) and by giving concrete pagination guidance. Credits per action add further semantic context. It does not elaborate on limit, sortingOrder, or context beyond what the schema already states.

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

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

The description states a specific verb and resource: 'Query latest XRP (Ripple) address data.' It then enumerates the three actions, immediately telling the agent what operations are available. The XRP/Ripple naming clearly differentiates it from sibling chain-specific tools like evm_address_latest and solana_address_latest.

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 action list gives clear context for which operation to choose, with one-line explanations for get-balance, list-transactions, and get-next-sequence. Networks are also named. However, there are no explicit when-not-to-use or alternative-selection rules beyond the implied chain distinction from siblings.

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