OrbitWan.io

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: case-insensitive matching, a per-call cap of 50 with total_matches for the full count, and a prompt-injection warning to treat labels as data. It omits details like ordering of results, but the additions are substantive.

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 action and return, then the example, the filter, the result cap, and finally the injection caution. It is dense with little waste, though the final safety sentence is somewhat boilerplate for a read-only registry tool.

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

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

With no output schema, the description gives a reasonable picture of the return (addresses with matching label/project/kind, plus a total_matches count) and the per-call cap. The main gap is the unexplained `limit` parameter, which an agent would need to set the page size.

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 0%, so the description carries the burden. It explains query (substring match across label/project/kind, case-insensitive) and type (exchange, validator, token, contract), but never mentions the `limit` parameter, whose default of 25 is not reconciled with the stated 'up to 50 matches per call'. Two of three params are covered, one is left ambiguous.

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 ('Search OrbitWan's curated tag registry by name') and immediately clarifies the return ('returns the Wanchain addresses whose label, project or kind contains the query'). The 'Binance' example makes the operation concrete and distinguishes it from sibling tools like get_address_tags (which fetches tags for a known address rather than searching by name).

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 clear context for when to use the tool (name-based lookup in the tag registry) and mentions the optional type filter for narrowing results. However, it does not explicitly name alternatives or state when NOT to use it (e.g. when you already have an address and want its tags).

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 establish readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond that by specifying cursor pagination and the range of activity types covered, which helps the agent understand the shape of the call. It does not mention rate limits or result ordering, but the existing annotations lower the burden.

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 worded sentence with no filler. It front-loads the core purpose and appends the pagination detail efficiently.

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

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

With no output schema and 0% parameter coverage, the one-sentence description leaves too much unstated: the meaning of the 'category' enum, the relationship between 'view' and 'category', and how to use cursor/limit correctly. An agent would likely need to guess or probe to invoke this tool reliably beyond the happy path.

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

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

Schema description coverage is 0%, so the description must compensate. It does partially explain the 'view' parameter through 'transactions, token transfers, or internal calls' and hints at 'cursor', but it leaves the 'category' parameter completely unexplained and says nothing about 'limit' semantics or how parameters interact. This is insufficient for a 5-parameter tool with two enums.

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 resource (a Wanchain address) and the specific activity types returned (transactions, token transfers, internal calls), which distinguishes it from address-focused siblings like get_address_summary or get_address_flows. It lacks an explicit verb like 'retrieves' or 'lists', but the meaning 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 implies that this tool is for recent address activity, and the mention of transaction types makes the use case evident. However, it gives no explicit guidance on when to prefer this over get_address_flows, get_address_summary, or get_address_tags, and does not state any exclusions.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses rich behavioral details: it is decoded from the task board's own events, includes only successful transactions, covers both directions (sent and paid), and specifies ordering (newest first), pagination (cursor), and unit format (base-unit integer strings). This greatly exceeds 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 a single dense sentence that front-loads the core purpose and then packs in essential behavioral details without any fluff. Every phrase adds value, and the structure is easy to parse 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?

Given the absence of an output schema and the moderate parameter count, the description fully covers what an agent needs: what data is returned, what inputs matter, ordering, pagination, and value formats. No critical information appears missing for selecting and invoking 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 description coverage is 0%, so the description must compensate for parameter meaning. It clarifies that 'address' refers to a Wanchain address and that 'cursor' is used for pagination, but it does not explain the 'limit' parameter or its default value. This is partial compensation, not full, so a mid-range score 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 states a specific verb and resource: retrieving Bridge to Earn activity for a Wanchain address. It precisely enumerates what is included (successful outgoing transactions and incoming payments, with route, source token, amount, and asset movements), which clearly distinguishes it from siblings like get_address_activity or get_bridge_activity.

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 the tool: whenever Bridge to Earn activity for a specific address is needed. It does not explicitly name alternatives or state when not to use it, but the specificity of 'Bridge to Earn activity' strongly implies it is the right tool for that niche, while other tools handle general address or bridge activity.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral detail beyond them: result ordering (newest first), pagination semantics ('rows is one page'), and the meaning of the count_30d aggregate.

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

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

Two dense sentences with the scope and ordering front-loaded, then return-shape semantics. No filler and nothing repeated from the title or schema.

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

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

With no output schema, the description usefully characterizes the response (rows are one page, count_30d is a 30-day total) and the sort order. It is nearly complete for invocation, though the required address format and limit/cursor usage remain unaddressed.

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

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

Schema description coverage is 0%, so the description carries the burden for three parameters. It gives only indirect hints ('rows is one page' implies cursor-based paging) and never explains the required address format, the meaning of limit, or its default of 25.

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 resource (cross-chain bridge transfers) and an exact scope predicate (address is sender or recipient on any chain), plus ordering (newest first). This clearly separates it from siblings like get_address_activity or get_bridge_activity.

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 phrase 'the rows the site's Cross Chain tab shows' implies the UI context in which this is the right tool, but there is no explicit when-to-use, when-not, or named alternative among the many get_address_* siblings. Usage is inferable 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context by stating that all amounts are base-unit integer strings and that the window is 1 to 90 days. This helps an agent parse results correctly without contradicting 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 two short sentences with no filler. The core result is stated first, followed by the window constraint and amount format, making it efficient and easy 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 endpoint with two parameters and no output schema, the description conveys the result granularity, the address scope, the allowable window, and the amount representation. It is sufficient for correct invocation, though return-structure details are not elaborated.

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

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

Schema coverage is 0%, so the description must compensate. It gives meaning for both parameters indirectly: address is a Wanchain address and days corresponds to a window of 1 to 90 days. However, it does not explicitly mention the default of 30 days or parameter names, leaving some inference required.

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 what the tool returns: per-token in/out sums and native WAN flows for a Wanchain address over a time window. It is specific about the resource and scope, though it does not explicitly contrast itself with sibling tools like get_address_activity or get_address_summary.

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?

No guidance is given about when to choose this tool over alternatives. It states the supported window length but does not describe use cases, exclusions, or how it differs from related address tools.

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 annotations already declare readOnlyHint=true and destructiveHint=false, signaling a safe read operation. The description adds valuable behavioral context beyond that: data provenance ('decoded from the Wanchain governor's own events'), inclusion criteria ('every successful transaction... and every governor transaction that paid it'), and the format trait that amounts are base-unit integer strings. No contradiction with annotations exists; the read-only claim aligns with the decode/list framing.

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 phrase 'Governance activity for a Wanchain address' is front-loaded, immediately establishing the tool's core purpose. Every clause in the single sentence adds meaningful specification (source, inclusion criteria, content fields, asset types, and amount format), so nothing is wasted. The sentence is somewhat long and run-on, with a trailing enumeration that could be broken up, which prevents a 5.

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 one-parameter, read-only tool with no output schema, the description carries the return-value burden and does so well: it enumerates what is returned (proposal, vote, pledge mechanism, voting power, assets WAN and XP in/out, base-unit strings). Missing details are minor — the overall response structure (array vs object) and address format are not specified. Given the tool's low complexity, the description is nearly 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 description coverage is 0%, so the description carries the burden of explaining the 'address' parameter. It does add meaning by clarifying the address is a Wanchain address in a governance context, which goes beyond the bare schema string type. However, it omits practical detail such as the expected address format (e.g., hex prefix or checksum), so compensation for the coverage gap is only partial.

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 resource (a Wanchain address) and a specific scope of activity (governance activity decoded from the governor's own events, including proposal, vote, pledge mechanism, voting power, and asset flows). This sharply distinguishes it from the sibling tools like get_address_activity and get_address_flows, which cover general activity and flow data, and get_address_positions, which covers holdings. The detail about 'every successful transaction it sent to the governor' makes the exact semantics unmistakable.

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

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

The usage context is implied through the description's specificity: an agent seeking governance-related activity (votes, pledges, proposals) for a Wanchain address would infer this is the right tool. However, the description never explicitly names alternatives or states when not to use it, such as pointing to get_address_activity for non-governance activity. No exclusion or routing guidance is provided.

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 establish a safe read (readOnlyHint=true, destructiveHint=false), and the description adds real behavioral context beyond that: a single pinned block read, live pricing from OrbitWan's price table, base-unit string amounts, and the partial-failure contract where the total is null with a failed count. That is strong disclosure of edge-case behavior for a read tool.

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

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

Two dense sentences, front-loaded with the core resource and an input, followed by the failure contract. No filler and no restatement of the title.

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

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

With no output schema, the description carries the return-value burden and does so adequately: it explains amount encoding (base-unit strings) and the null-total/failed-count behavior. Only the address input format and the relationship to sibling tools remain unaddressed.

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

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

Schema description coverage is 0% for the single parameter, and the description only says "of an address" without clarifying format (raw hex, tagged handle, or identifier needing resolve_identifier). With unresolved format ambiguity that matters given siblings like find_tagged_addresses, the description fails to compensate for the coverage gap.

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

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

"Token balances of an address" states a clear resource (token balances) tied to an input (an address), and the pricing/base-unit detail sharpens what kind of balances these are. It does not explicitly distinguish itself from close siblings like get_address_summary or get_address_positions, so an agent still has to infer which holdings-style read it wants.

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?

There is no when-to-use guidance and no named alternative, despite a crowded get_address_* sibling set (summary, positions, flows, tags). Usage is only implied by the resource name; the description never says when this tool is preferred over get_address_summary or get_address_positions.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds non-obvious behavior beyond that: node-paid lines carry a null tx_hash and point at cause_tx/cause_method, amounts are wei strings with exact decimal WAN alongside, and reconcile performs a genesis-to-now sum against the node balance.

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 definition is dense and front-loads the resource and line structure before moving to edge cases and pagination. Every sentence carries information, though the middle sentence is long and slightly overloaded with the null-tx_hash exception details.

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

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

With no output schema, the description does the heavy lifting and adequately describes the returned line shape, the null-tx_hash exception, pagination via next_cursor, and the reconcile mode. Missing only the address input format and any indication of error or empty-ledger 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 description coverage is 0%, so the description must carry the parameter burden, and it largely does: limit is bounded 1 to 100, cursor is next_cursor from the previous answer, reconcile triggers a genesis sum compared to node balance. The address parameter is only implied ('of a Wanchain address') with no format guidance such as hex/checksum requirements.

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 names a specific resource (the WAN ledger of a Wanchain address) and spells out exactly what a ledger line contains: signed amount, counterparty, transaction, and post-transaction balance. That content profile is distinctive enough to separate it from siblings like get_address_activity or get_address_flows without opening any schema.

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 usable mechanics (paginate with limit/cursor taken from next_cursor; set reconcile true to sum from genesis and compare against the node balance), which implies when to use those options. However, it never states when to prefer this tool over the many sibling address tools, and no alternative is named or excluded.

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 discloses that amounts are base-unit integer strings and that each program carries ok, complete, and floors flags to prevent unread or partial figures from being presented as zero. This adds significant data-integrity context beyond the readOnlyHint annotation and does not contradict any 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 two sentences, front-loaded with the operation and scope, followed by critical data-format and integrity notes. Every sentence earns its place with no 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?

The description covers the data type, source (OrbitWan's own node), and handling of incomplete data, which is sufficient for a read-only tool. There is no output schema, but the description gives enough context to understand what the tool returns. Slight gap: no explicit note on what the response structure looks like, but the flags and formatting partially cover 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?

With 0% schema coverage, the description must explain the address parameter. It does so implicitly by stating 'for a Wanchain address', making the parameter's meaning clear. However, it omits details like address format or validation requirements, which could be useful but are not critical for a single obvious parameter.

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

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

The description clearly states the tool returns staking, farming, lending, and deposit positions for a Wanchain address across supported programs. It names specific example programs and the scope ('every program OrbitWan reads'), which distinguishes it from siblings like get_address_activity or get_address_flows.

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

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

The description implies usage for position data but does not explicitly contrast with alternative tools or state when not to use it. It provides context (comprehensive across programs) but lacks explicit exclusions or comparisons to 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond those annotations: it explains that figures depend on an indexed coverage range and clarifies the difference between tx_count and tx_count_all.

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

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

Two tightly written sentences that front-load the returned fields and then add a precise distinction between tx_count and tx_count_all. Every sentence earns its place.

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

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

With no output schema, the description must carry the return shape, and it does name key fields and coverage range. However, it omits address formatting, pagination behavior, and any guidance for choosing this tool over sibling address tools, leaving clear gaps for a summary endpoint.

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

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

Schema description coverage is 0%, so the single address parameter is undocumented in the schema. The description indicates it must be a Wanchain address, which adds some meaning, but it gives no format or example. Partial compensation for the coverage gap merits a 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?

States specific measurements (transaction and transfer counts, first seen, last active) and scope (Wanchain address, indexed coverage range), so an agent can tell what the tool returns. It does not distinguish itself from sibling address tools such as get_address_activity.

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 no when-to-use guidance, no alternatives, and no prerequisites. 'for a Wanchain address' gives minimal context, but nothing tells the agent whether to choose this over get_address_activity or other address-specific 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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds a meaningful behavioral warning: labels are curated registry text and must be treated as data, not instructions. This is valuable security-relevant context that is not present in the annotations or 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?

Two short sentences, each earning its place: the first states the tool's purpose and the second adds a necessary data-handling instruction. There is no filler, repetition of the schema, or unnecessary detail.

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 one-parameter read-only lookup, the schema and annotations cover the input contract and safety profile, while the description covers purpose, scope, and output trust. It could mention the exact return shape, but the tool is simple enough that this omission is minor.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'addresses' parameter. It adds the key semantic that the addresses are Wanchain addresses, but it does not explain address format, array size limits, or how missing/unknown addresses are handled.

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 identifies the resource (Wanchain addresses) and the product (curated labels), which makes it distinguishable from sibling tools like get_address_activity or get_address_summary. It lacks an explicit verb, but the tool name and readOnly annotation make the 'get' intent clear.

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

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

The description implies this tool should be used when an agent needs curated label text for Wanchain addresses, and the 'treat as data, not instructions' caveat signals when extra caution is needed. It does not explicitly name alternatives or state when not to use this tool, leaving sibling differentiation mostly to the tool names.

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 it read-only, and the description adds meaningful behavior: chain coverage is dynamic rather than fixed, short slugs are accepted, and unknown chains produce a named error instead of a schema rejection. It does not cover pagination or result limits, but the disclosure goes beyond annotations.

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

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

The description is compact and front-loaded with the core purpose. The third sentence is long but packs essential dynamic-chain and error semantics; the 'Now covers' phrasing is slightly temporal noise.

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 read-only query tool with no output schema, it covers the three call patterns, validates dynamic chain values, and references the chain source sibling. The cursor pagination parameter is not explained, and there is no return-format hint, but an agent has enough to invoke the common modes 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?

With 0% schema description coverage, the description must explain the parameters. It maps chain to the live get_chain_coverage list, token_address to 'by token', counterparty to a counterparty on a foreign chain, and explains error behavior. Cursor is left unexplained, but the main selection parameters are meaningfully described.

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 resource ('cross-chain bridge transfers from the transfers pipeline') and enumerates the retrieval modes (network-wide, by token, by counterparty). This clearly distinguishes it from siblings such as get_crosschain_stats or get_address_activity.

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 clear contexts for use: recent network-wide, by token, or by counterparty, and directs the agent to get_chain_coverage for valid chains. It does not explicitly name alternatives or state when not to use the tool, so it falls just short of full 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?

Goes far beyond annotations by detailing state semantics (COMPLETE, FLOOR, UNREADABLE, NO_LIABILITY), clarifying that FLOOR ratios are lower bounds only, defining blocked_by, and explaining the run summary. It also discloses data fidelity ('returned exactly as the recorder route sent them'). No contradiction with readOnlyHint=true.

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 dense but well-structured: it front-loads the main purpose, then explains states, ratio rules, and summary in a logical order. Every sentence adds necessary information without redundancy, though length is justified by complexity.

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

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

Given the absence of an output schema and the complexity of state-dependent fields, the description thoroughly covers return semantics: states, ratio presence, blocked_by, run summary, and fidelity. An agent has sufficient information to interpret responses 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?

With 0% schema description coverage, the description compensates by explaining the 'state' parameter thoroughly with enum meanings and behavior. 'symbol' is implied via 'token component' but not explicitly linked. 'limit' is not addressed. Partial but not complete compensation for all 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?

The description precisely identifies the tool as returning WanBridge custody-vs-liability observations per token component, with detailed state explanations. It clearly distinguishes from sibling tools like get_bridge_activity (activity vs solvency) and sets expectations about data origin and structure.

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

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

The description implies usage for custody/liability analysis but does not explicitly state when to use this tool over alternatives or provide exclusions. It references 'Observations only' and data from recorder runs, but lacks direct comparison with sibling tools or conditions indicating alternatives.

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

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

Annotations already declare readOnlyHint, so the description adds context about the returned data (counts and timestamp) without contradicting. No side effects mentioned, but the read-only nature is adequately covered.

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

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

The description is a single dense sentence that conveys all necessary information without fluff, using concise and specific language.

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

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

With no parameters and no output schema, the description sufficiently explains what data will be returned, making it complete for a user to understand the tool's purpose and output.

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 tool has no parameters, so the description does not need to explain them. The schema is trivially covered, and no additional parameter details are relevant.

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

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

The description clearly states the tool returns per-chain cross-chain transfer coverage, including counts as source and destination and the latest timestamp, which distinguishes it from other get_* tools that focus on addresses or transactions.

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 does not explicitly mention when to use this over alternatives, but the focus on chain coverage implies it is for network-level metrics. No explicit exclusions are given.

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 destructiveHint=false, so the safety profile is covered. The description adds useful context about the data source and notes that row counts are approximate, but it does not disclose freshness, update cadence, or empty/failure behavior. This is adequate but not rich.

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?

A single dense sentence that places the key output terms first and contains no filler. The source qualifier 'OrbitWan Wanchain archive indexer' is relevant and is appended without bloating the sentence.

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 zero-parameter read-only tool, this is nearly complete: it names the resource, the source, and the three categories of returned information. The absence of an output schema is partly mitigated by these specifics, though exact units or the format of 'head' and 'progress' are left unspecified.

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 has zero parameters with 100% coverage, so the baseline is 4; no parameter-level guidance is needed. The metrics mentioned in the description are return values, not arguments, so there is no semantic gap to compensate for.

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 identifies a specific status resource for the Wanchain archive indexer and enumerates the metrics returned: indexed head, genesis backfill progress, and approximate row counts. It lacks an explicit verb and does not contrast with the sibling get_chain_coverage, so it is clear but not fully differentiating.

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?

No guidance is provided about when to use this tool versus alternatives such as get_chain_coverage, nor are there any exclusions or prerequisites. The only usage signal is the read-only annotation and the status-oriented wording.

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 and non-destructive behavior, and the description adds a meaningful non-obvious behavior: a null creation result is not proof that no creator exists while the genesis backfill floor is above zero. This is useful data-integrity context beyond 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 two tight sentences with no filler. The primary output fields are front-loaded, and the caveat is placed second, making the most important information immediately visible.

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-address lookup with annotations covering safety, the description covers the returned fields and an important edge case. It does not explicitly describe return formatting, but the listed fields and the caveat about null results provide enough context for an agent to interpret the tool's 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?

With 0% schema description coverage, the description partially compensates by implying the input address is a Wanchain contract and indicating what lookup results will be returned. However, it does not clarify address format, whether checksums are expected, or how to interpret the required address parameter beyond 'for a Wanchain contract.'

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 lists the data returned — creator address, creation transaction, block, and timestamp — for a Wanchain contract, so an agent can tell what the tool provides. It lacks an explicit verb like 'Retrieves' and does not explicitly contrast itself with siblings such as get_verified_contract, but the resource and output are specific enough.

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 no direct guidance on when to use this tool versus alternatives like get_verified_contract or get_address_activity. The caveat about null creation and genesis backfill is interpretation guidance, not usage-selection 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 mark the tool as readOnly and non-destructive, so no safety caveats are needed. The description adds useful context: data source ('transfers pipeline'), 'raw' nature, and the specific aggregation dimensions returned. This is sufficient behavioral transparency for a zero-parameter read-only 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?

A single, tightly worded sentence front-loads the key concept ('Raw cross-chain transfer tallies') and then lists concrete output categories. Every part of the sentence adds value; there is no fluff or repetition of the title.

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 zero-input read-only tool without an output schema, the description fully conveys what an agent will receive: counts by status, source chain, destination chain, and the latest transfer timestamp. No additional input or behavior details are needed 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 tool has zero parameters, so the empty input schema already conveys all parameter information. The description correctly implies no input is required by presenting pre-aggregated statistics. Baseline 4 is appropriate because there is nothing for the description to add beyond the schema.

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

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

The description uses a specific verb and resource ('Raw cross-chain transfer tallies') and lists exact data dimensions: counts by status, source chain, destination chain, and latest network timestamp. This clearly separates the aggregate stats tool from event-level siblings like get_bridge_activity.

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 phrase 'Raw cross-chain transfer tallies' implies this is for aggregate transfer counts rather than address-level flows or bridge activity, but no explicit when-to-use or alternative tool names are given. An agent must infer when this is preferable to get_bridge_activity or orbitpay_crosschain_history.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful sourcing context ('DefiLlama-sourced', 'via WanBridge'), but does not disclose return format, pagination, or whether the data is live vs cached; this is acceptable given the simple read-only role.

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?

One sentence delivers the core scope and data provenance without redundancy. The most important qualifier (Wanchain-native vs cross-chain) comes first, and the parenthetical is compact and informative.

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 one optional parameter, no required arguments, and a read-only annotation, the description is nearly sufficient for an agent to select and invoke it. It lacks explicit return-value details, but given the absence of an output schema and the simplicity of the tool, the description covers the essential selection and invocation 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 description coverage is 0%, but the single optional section parameter has self-documenting enum values wanchain/crosschain/all. The description indirectly maps to these values through 'Wanchain-native' and 'cross-chain', yet it never explains the default behavior or the meaning of 'all', leaving the description to provide only partial compensation.

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 resource: Wanchain-native earn positions and cross-chain yield opportunities sourced from DefiLlama via WanBridge, which separates it from the address/transaction/bridge sibling tools. It lacks an explicit verb like 'lists' or 'returns', but the tool name supplies the get action and the scope 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 implies use for yield-related queries by naming the resource, but it never explicitly tells the agent when to prefer this tool over siblings or how the section parameter should be set for particular intents. No exclusions or alternative routing are provided, so guidance is only implicit.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by mentioning 'cursor pagination,' which tells the agent that results are paginated with a cursor, and it lists the specific data fields returned. It does not contradict annotations. This adds value by clarifying the output structure beyond the safety flags.

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

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

The description is a single, dense sentence that efficiently lists the returned fields and pagination. It is concise and front-loads the key content (fields) before mentioning the contract type and pagination. It could be slightly improved with a separate mention of parameters, but it is not 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 tool with 3 parameters and no output schema, the description provides a list of returned fields and mentions pagination, which is useful. However, it does not describe the response structure (e.g., JSON object shape) or the 'limit' parameter's behavior and default. Without an output schema, the agent may be uncertain about the exact format of the response, and the missing limit explanation is a notable gap.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It implicitly covers 'address' (as the token contract) and 'cursor' (through 'cursor pagination'), but it completely omits the 'limit' parameter, its default value, and how it controls the number of transfers returned. The description does not explicitly map parameters to their purposes, leaving the agent unsure about limit's role.

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

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

The description clearly states it returns specific fields (token symbol, decimals, transfer_count, last transfer time, recent transfers) for a Wanchain token contract, and mentions cursor pagination. This distinguishes it from siblings like list_tokens, which would list multiple tokens, and get_address_activity, which focuses on address actions. The verb is implicit but the resource and scope 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 implies this is for querying a specific token contract by address, and it mentions pagination. However, it does not explicitly state when to use this tool versus alternatives such as list_tokens (for enumerating tokens) or get_address_activity (for address-centric queries). There is no 'when not to use' or comparisons to sibling tools, leaving the agent to infer usage context.

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 cover the safety profile (readOnly, not open-world, non-destructive), so the description's added value is the semantic contract: null means genuinely unpriced and never zero. That is a meaningful disclosure beyond the structured fields, though it says nothing about freshness, caching, or rate limits.

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

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

Three tight sentences, no filler, with the resource and source front-loaded and the edge-case conventions (zero address, null price) trailing where they belong.

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

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

With no output schema, the description usefully defines the return shape (USD price keyed by address) and the null semantics. It stops short of stating ordering/coverage guarantees or how missing/null entries relate to the input list, but it is close to complete for a two-parameter read 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 0%, so the description must carry parameter meaning, and it does: it defines the zero-address convention for 'addresses' and clarifies that 'block' requests a historical price. It adds real semantic content the schema lacks, only missing format details (block units, address format).

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 ('USD price per Wanchain token'), names the data source (OrbitWan's price table), and gives the keying dimension (token address), which cleanly separates it from siblings like get_token and list_tokens.

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 how to use the inputs (zero address = native WAN, pass block for historical pricing) but never states when to reach for this tool versus get_token/list_tokens or what conditions would make it the wrong choice. Usage is implied rather than routed.

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 destructiveHint=false, so the safety profile is covered. The description adds value by specifying the exact behavioral scope: it returns core transaction fields, token transfers, cross-chain leg details, and internal calls, context 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 a single, tightly written sentence with zero filler. It front-loads the primary purpose ('Full detail for a Wanchain transaction') and then lists the specific content included, making every word informative.

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 one-parameter, read-only tool, the description adequately covers what the agent can expect the tool to return by enumerating the detail categories. It does not describe error behavior or response format, but without an output schema and given the tool's simplicity, this is a minor gap rather than a completeness failure.

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

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

Schema description coverage is 0%, and the description does not elaborate on the hash parameter at all. The parameter name 'hash' plus the title makes its purpose inferable, but the description does not compensate for the missing schema documentation, nor does it clarify format or domain (transaction hash, not block hash or other identifier).

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: 'Full detail for a Wanchain transaction' and enumerates the concrete data categories it returns (core fields, token transfers, cross-chain leg, internal calls). This clearly distinguishes it from sibling tools like get_address_activity or get_bridge_activity, which target different resources or scopes.

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 intended use is implied by the name and description: call this when you need transaction-level detail. However, it provides no explicit guidance on when to prefer this over potentially related siblings such as get_bridge_activity or get_crosschain_stats, especially given the cross-chain leg mention.

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 establish readOnlyHint=true and openWorldHint=false, but the description adds substantial context beyond them: pagination bounds (limit 1-25), cursor semantics (next_cursor), the presence of stake-return entries labeled 'Stake returned', and the exited-validator edge case (status exit, live stake 0, history in flows). This is unusually rich behavioral disclosure for a read 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 description is information-dense and front-loads the resource, but it reads as telegraphic notes strung together with semicolons ('Default profile. flows pages with limit...'), which hurts parseability. It is compact but not well structured.

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

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

With no output schema, the description must explain returns, and it covers the key shape (found, type, name, next_cursor) plus notable edge cases. For a four-view query tool this is close to complete, though the payload of each individual view (e.g. rewards/profile fields) remains unsummarized.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it largely does: it maps view values to node types (profile/rewards/flows for PoS; profile/flows/members for Storeman), states the default view, and gives the limit range (1 to 25) and the cursor's role (next_cursor). The required address parameter is never described, leaving a small gap.

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

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

The description names a specific resource (a Wanchain PoS validator or Storeman node) and the dimensions returned (profile, rewards, flows, members), so an agent knows this is a per-address node lookup rather than an enumeration. It does not explicitly contrast itself with the sibling list_validators, which slightly weakens differentiation, but the resource 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?

Usage is implied through the view-by-node-type mapping and the 'Default profile' note, but there is no explicit statement of when to use this tool versus list_validators or the get_address_* siblings. The agent must infer that this is the address-scoped validator lookup.

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 destructiveHint=false, covering the safety profile. The description adds that an ABI summary is always returned and that include_sources toggles the full ABI and source files, which is useful context. However, it does not disclose what happens for unverified addresses or error conditions, leaving a gap.

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?

A single clear sentence that front-loads the core purpose and appends the optional behavior. No wasted words; information density is appropriate and the structure is easy 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 read-only tool with two parameters and no output schema, the description provides a high-level overview but omits details such as expected output fields, error handling for unverified contracts, and differentiation from sibling tools. These omissions leave an agent with uncertainty about edge cases and exact return shape.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that include_sources controls whether full ABI and source files are returned, which adds semantics beyond the schema. The address parameter is only implied as the contract address from the resource, but not explicitly described.

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 specifies the resource (a Wanchain contract) and the data returned: source-verification status, provenance, an ABI summary, and optionally the full ABI and source files. This distinguishes it from sibling tools like list_verified_contracts by focusing on a single contract's detailed verification data.

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

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

The description implies usage for retrieving detailed verification details of a specific contract, but it does not explicitly state when to choose this over alternatives such as list_verified_contracts or get_contract_creation. No exclusions or alternative guidance is provided, leaving the agent to infer the intended scenario.

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/destructive/openWorld, so safety is covered. Beyond that, the description discloses meaningful behavior: values are 'read at one Wanchain block' (snapshot semantics), it returns the desk's quote/rate/balance and 'whether it can pay,' and it surfaces exact approve and sell calls without recommending a route. It does not mention pagination or refresh behavior, keeping it below 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 core action, and the trailing skill reference is a useful routing cue. However, the opening sentence is a long run-on stuffing route names, rates, and return fields into one clause, making it harder to scan than 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?

There is no output schema, so the description must convey returns, which it does (quote, rate, WAN balance, solvency flag, approve/sell calls). Annotations cover the safety profile, and the skill pointer covers the follow-on execution path. Only the amount's expected format is left unaddressed for a comparison-oriented read 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?

One parameter ('amount') with 0% schema description coverage, so the schema carries no semantics. The description implies the amount is denominated in xWAN and references per-xWAN rates, adding units meaning, but gives no guidance on format, precision, or string-vs-number. Baseline 3 for a single lightly-documented parameter.

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+resource: it reads the WAN that an xWAN amount converts into across routes (xWAN Express, XFlows vesting tiers). The exact output contents (quote, rate, WAN balance, solvency, approve/sell calls) are named, so an agent knows what it gets. Somewhat jargon-dense, but 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?

Implies usage through 'No route is recommended; the owner chooses' and by pointing to the wanchain-xwan-express skill 'covers selling,' which suggests this tool is for pre-sale option comparison rather than execution. It never explicitly states when to call this versus other tools, so usage is inferred rather than spelled out.

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/openWorld=false/destructive=false, and the description adds substantial context beyond them: 'Task names are never served', amount values are exact decimal strings beside raw base-unit integers with null meaning 'not proven, not zero', ends_in reflects the node's own clock with an hours-minutes text, and urls enumerate claim page, creating transaction and per-token pages. This is rich disclosure of data quirks and return semantics.

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 purpose and packed with high-value detail, but the single long paragraph compresses several distinct topics (ordering, polling, amount encoding, urls, sibling workflow) into dense prose. Every sentence earns its place, yet the density slightly hurts scannability.

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

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

With no output schema, the description must cover return shape and it does: ordering, amount encodings, ends_in format, url fields, and next_after_id for polling. Combined with annotations covering the safety profile, an agent has everything needed to call and interpret this 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 0%, so the description carries the burden, and it does: after_id is described as 1-to-12 digits returning only higher ids with a poll-again pattern via next_after_id, and sort is tied to the ending_soonest deadline behavior. It does not enumerate valid sort values or the default value explicitly, so it falls just short of full compensation.

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 ('Open Bridge to Earn tasks on the Wanchain task board'), plus the data source ('read from OrbitWan's own node') and default ordering. It also names the sibling prepare_bridge_to_earn and explains its distinct step-by-step role, so an agent can separate the list tool from the driver tool without opening schemas.

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 operational context: default is newest-first, 'sort ending_soonest' switches to deadline order, and after_id enables incremental polling by feeding back next_after_id. It also routes the agent to prepare_bridge_to_earn for executing tasks. It stops short of an explicit 'do not use this for address-scoped tasks, use get_address_bridge_to_earn' exclusion, so 4 rather than 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 mark read-only, and the description adds that the payload includes an untagged count, revealing an extra behavioral detail. No contradictions; it doesn't disclose performance or pagination but is sufficiently transparent for a read-only list.

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 sentence that front-loads the key phrase 'full token registry' and then enumerates the returned fields compactly. No unnecessary words.

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

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

For a parameterless list tool with no output schema, the description fully communicates what data is returned and even includes the untagged count. It is complete enough for an agent 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?

The tool has no parameters, and schema coverage is complete (empty schema). Per rubric, baseline is 3 since no parameter info is needed in the description.

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

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

The description clearly states the tool returns the full token registry, listing address, symbol, decimals, and curated tag for every indexed Wanchain token. It distinguishes from get_token (single token lookup) and list_verified_contracts (contracts, not tokens).

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

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

The description implies usage for retrieving all tokens but does not explicitly compare with alternatives like get_token or mention when to prefer this over other listing tools. It lacks explicit guidance on when to use this vs. 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?

Annotations already establish readOnly/non-destructive/non-open-world safety, so the bar is lower, yet the description adds real behavioral detail: sort direction rules (fee ascending, others descending), that fee/room are PoS-only, and that exited validators trail the live rows newest-first. It stops short of explaining volume/pagination or auth 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?

Front-loaded with the entity and its fields, then filter/sort rules, then the exit-row ordering caveat. Dense but every clause carries information; a slightly long sentence about epoch selection slows it marginally but nothing is wasted.

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 list tool with no output schema and three simple params, the description covers what each row contains, how filtering/sorting behave, and the exit edge case. It is complete enough to call correctly, with only minor gaps around result size/paging.

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?

With 0% schema description coverage the description must carry the load, and it does: it defines sort semantic direction per field, the PoS-only constraint on fee/room, and explains the free-text 'status' parameter as epoch selection (selected / not selected / exit) plus the special exit-only behavior. This is meaning well beyond the raw enum lists.

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 (list) and resource (PoS validators and Storeman nodes) and enumerates the profile fields returned, so the scope is unambiguous. It implicitly contrasts with the singular get_validator sibling via 'Every ... node', but never names it explicitly, leaving sibling differentiation to inference.

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 how to narrow results ('Filter by type and status', sort options) which implies usage, but never states when this tool should be chosen over get_validator or when it should not be used. Context is implied rather than declared.

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 the operation read-only and non-destructive. The description adds the scope ('source-verified Wanchain contracts') and the fact that it returns a roster rather than a single contract, but it does not disclose pagination, ordering, result shape, or any rate-limit concerns. This is modest value beyond 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 one short, direct sentence with no filler or repetition. It is front-loaded with the key resource information, although it sacrifices helpful detail for 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 and annotated as read-only, but there is no output schema and the description does not explain what fields each verified contract entry contains, how limit affects the response, or whether pagination exists. This is enough to make a default call, but not enough to confidently handle different result sizes or interpret the output.

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 sole parameter, limit, is not explained in the description and the schema provides only its type and default value. With 0% schema description coverage, the description was responsible for explaining limit semantics, but it never mentions pagination, maximum values, or how the limit affects results. The name and default give a weak hint, but the gap remains.

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 identifies a specific resource—source-verified Wanchain contracts—and the word 'roster' implies a listing operation. It is distinguishable from the sibling get_verified_contract, which is singular, but the description does not explicitly state 'list' as the action or name that alternative.

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?

There is no guidance about when to use this tool versus get_verified_contract, list_tokens, or other siblings. No alternatives, exclusions, or conditions are mentioned, so an agent must infer usage solely from the tool name.

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 the tool read-only and non-destructive, and the description adds useful behavioral context: the return includes a name, a signature, and a tier indicating whether the match came from a verified ABI or a heuristic table. It stops short of explaining failure behavior when no match is found, but this is a strong addition given no output 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?

A single sentence that is front-loaded with the core purpose and immediately follows with the tier detail. Every clause earns its place, with no redundant or filler content.

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 low-complexity, one-parameter resolver, the description is largely complete: it identifies the input, the output components, and the provenance tier. The only notable omission is handling of unknown selectors or exact input formatting, but the overall picture is clear enough for an agent to invoke the tool confidently.

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 provides only 'selector' as a generic string with 0% description coverage, the description compensates by clarifying it must be a 4-byte function selector. It does not explicitly state the expected hex format or 0x prefix, but for a single simple parameter this is a meaningful semantic improvement over the bare 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 ('Resolves'), a precise resource ('4-byte function selector'), and the result ('name and signature'). It also distinguishes itself from siblings like resolve_identifier by focusing on selector-to-signature resolution and mentioning the verified-ABI versus heuristic-table tier.

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 no explicit guidance on when to use this tool instead of siblings such as resolve_identifier, nor does it state when not to use it. Usage must be inferred entirely from the function of resolving a selector; there are no prerequisites, exclusions, or alternative routing signals.

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 mark it read-only and non-destructive, and the description adds genuinely useful behavioral context beyond them: the prepaid-credit model, the exact cost (0.0005 USDT per 100 rows), and a fallback per-request payment path with its own price. Return format, row limits relative to `limit`, and cursor expiry are left unstated.

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?

Compact and front-loaded: what it is, then pricing, then payment paths. The embedded URL and price figures are dense but each earns its place for an agent that must decide whether it can afford to call the tool.

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 an empty schema description, a nested `filters` object, and no output schema, the description spends its budget on monetization and says nothing about what rows come back, how cursor paging terminates, or what filter keys exist. The gaps fall exactly where the structured fields provide no help.

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 0% for five parameters (from, to, limit, cursor, filters), and the description supplies no per-parameter meaning. 'Filtered and paginated' only faintly gestures at `filters`/`cursor`; the direction semantics of from/to and the accepted filter keys are entirely undocumented.

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+resource: 'Premium bulk cross-chain transfer history, filtered and paginated.' This is clearly distinguishable from free siblings like get_address_crosschain or get_crosschain_stats through the 'premium bulk export' framing.

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 explicit routing: use orbitpay_info for payment/signing steps, or pay per request via x402 on the HTTP route for wallet-holding agents. It does not, however, tell the agent when to prefer this over the free cross-chain 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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond that: exact cost (0.0005 USDT per 100 rows prepaid, 0.01 USDC per request via x402), the required payment prerequisite (orbitpay_info), and an out-of-band HTTP route. This is well above the bar for a paid 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?

Front-loaded with purpose, followed by the payment model and a concrete route; every sentence serves invocation. The pricing detail is denser than strictly necessary but earns its place as a cost prerequisite.

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?

Payment and access mechanics are fully covered and no output schema exists to explain, so the return side is fine. But for a 5-parameter tool with 0% schema description coverage and a nested filters object, the complete absence of parameter semantics leaves a real gap.

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

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

Schema description coverage is 0% for all 5 parameters (to, from, limit, cursor, and a nested filters object), and the description adds no parameter meaning at all — no date format for from/to, no cursor semantics, no filter key documentation. With 0% coverage the description must compensate, and it does not.

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 names a specific resource and scope: 'Premium Wanchain economics time series (supply, fees, and related metrics over time)'. This is distinguishable from siblings like orbitpay_token_supplies (single-metric) and orbitpay_crosschain_history (different domain), so an agent can tell why to pick this tool.

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

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

It explains the two payment pathways clearly (prepaid credit vs x402 per-request) and points to orbitpay_info for signing steps, which is genuinely actionable invocation guidance. However, it never states when to use this tool versus sibling economics/history tools, so tool-selection guidance is only 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 only declare a safe read, but the description adds substantial behavior: it is free, it idempotently returns a manual, it details the exact signing scheme (EIP-191 personal_sign over 'orbitwan-api <unix_seconds>'), the required X-Payer/X-Timestamp/X-Signature headers, and a per-request x402 fallback. This is far beyond what annotations provide.

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-loads the key point ('Free.') and stays on topic, but the x402 parenthetical with wire-version details is dense and could be trimmed. Every sentence is relevant to a payment manual, so little is wasted.

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

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

With no params, no output schema, and safe-read annotations, the description fully covers what the tool returns and why. It explains both the OrbitPay prepaid-credit flow and the x402 alternative, so an agent knows how to proceed after calling.

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 tool takes zero parameters, so there is no parameter semantics to miss; baseline 4 applies. The description correctly signals a no-argument, informational 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?

States a specific verb and resource ('Returns the live payment manual') and enumerates exactly which four sibling tools it documents. An agent can distinguish this from the premium data tools without opening any schema.

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?

Explains the trigger (called unauthenticated or with no wallet credit, the four tools return this manual) and offers an alternative path (x402 clients pay without OrbitPay onboarding). It does not explicitly order the agent to call this first, but the context for use 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 readOnly/non-destructive/not-open-world, so the description correctly focuses on what they don't cover: this is a metered, paid operation with explicit pricing (0.0005 USDT/100 rows), a required signing step via orbitpay_info, and an alternative x402 route. That is meaningful behavioral disclosure beyond the annotations. It omits return format and pagination behavior despite the cursor param.

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?

Purpose is front-loaded in the first sentence, followed by pricing and payment mechanics. Three dense sentences with little waste, though the embedded URL and dual-pricing detail make it slightly busy.

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

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

For a paid tool with a nested filters object and no output schema, the description covers the critical payment/signing prerequisites but leaves parameter semantics and result shape unaddressed. Adequate on the billing dimension, incomplete on the invocation dimension.

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

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

Schema description coverage is 0% and the description says nothing about any of the 5 parameters (to, from, limit, cursor, filters). The nested filters object and the cursor/pagination semantics are entirely unexplained. Only the raw JSON types and numeric bounds in the schema carry any meaning, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('bulk address-tags export') and qualifies it with 'Premium' and 'bulk', which distinguishes it from the read-style siblings like get_address_tags and find_tagged_addresses. It does not name a sibling explicitly, so it falls short of a 5, but an agent can still tell this is the paid bulk-export variant.

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

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

It explains the payment paths (prepaid credit via orbitpay_info vs per-request x402) which is useful routing, but never says when to choose this tool over the free-looking sibling tag tools. Usage is implied by 'premium bulk export' 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?

Annotations only declare readOnlyHint/destructiveHint/openWorldHint; the description adds genuinely useful uncovered context: a prepaid credit model at 0.0005 USDT per 100 rows, a required signing/payment bootstrap via orbitpay_info, and an alternative per-request x402 payment route at 0.01 USDC on Base. That is real behavioral disclosure beyond structured fields, though it omits any note about pagination behavior despite the cursor/limit parameters.

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

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

Three sentences, no obvious padding, and every sentence carries information. However, the lead sentence is a bare four-word fragment while the pricing/payment logistics occupy the bulk of the text, so the front-loading favors billing over the actual capability.

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?

There is no output schema and no description of the returned supply data, and five undocumented parameters are left entirely unexplained. For a paid data-query tool with nested filters and cursor paging, the definition covers commerce but not the query and result contract an agent needs to call it correctly.

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

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

Schema description coverage is 0% across five parameters (to, from, limit, cursor, and a nested free-form filters object with additionalProperties string), meaning the schema explains nothing. The description mentions none of them, so an agent has no guidance on the semantics of the range fields, the 200-row cap, cursor paging, or what filter keys are legal. With zero compensation for a 0% coverage gap, this is a 1.

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 says it is 'premium token supply data,' which identifies the resource (token supplies) but never states what the tool actually returns or the shape of that data, and the sibling set contains close candidates like get_token, list_tokens and get_token_prices that are not distinguished. Roughly half the text is spent on payment mechanics rather than purpose, so the agent learns the pricing before it learns what the tool does.

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 operational routing ('call orbitpay_info', or pay per request via x402 on the HTTP route), which tells an agent how to get access but not when this tool is the right choice versus get_token/list_tokens. There is no statement of when-not to use it, no prerequisite for the non-wallet case, and no condition that selects it over its 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?

Beyond the readOnly/non-destructive annotations, it discloses that the tool is free, that the address is deterministic, the 12-confirmation crediting delay, 'no WAN needed, no second transaction', and that credit checks require a signed premium call. Rich behavioral context not available from 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?

Front-loads 'Free.' and the core purpose before the mechanics, and every sentence carries information. It is slightly dense with banner-style fragments ('no WAN needed, no second transaction'), but overall efficient.

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 read-only lookup with no output schema, it covers the return (deterministic vault address), funding mechanics, and where to find auth details. The only real gap is the undocumented 'beneficiary' input.

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

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

Schema description coverage is 0% and the single required parameter 'beneficiary' is never mentioned in the description. The description instead references 'toAddress' (an XFlows parameter, not this tool's input), leaving the actual argument unexplained.

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: 'Get your dedicated OrbitPay deposit vault address'. The nature of the output (a deterministic per-wallet vault address) is clear. It doesn't explicitly contrast with a sibling, but the tool is distinct enough that an agent can identify it.

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 concrete usage context: bridge wanUSDT/wanUSDC via XFlows with toAddress set to the vault, credit lands after 12 confirmations, and points to orbitpay_info for the auth scheme. It lacks an explicit 'use this instead of X' exclusion, but the workflow is well framed.

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?

On top of readOnlyHint/destructiveHint=false, it discloses that nothing is sent on the agent's behalf, every step including the final Wanchain collect is a transaction the agent signs, the claim must precede any transfer or the transfer does not count, the tool fetches the reward signature itself, and it never offers an invalid step. That is substantial behavioral context the annotations alone do not 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?

Front-loaded with purpose before the loop mechanics, and nearly every clause carries actionable instruction. It is dense as a single prose block and would be easier to follow with explicit structure, but little of the content is 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?

There is no output schema, so the description must describe the response — and it does: the status enum values, the have/need/short requirements shape with the 'null is unknown, never zero' rule, and the next.action semantics. Combined with the loop protocol and the signing constraint, an agent has everything needed to call this iteratively.

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?

With 0% schema description coverage the description must carry parameter meaning, and it does for most: address, task_id, the conditional source_address/dest_address (including the rule about non-EVM chains and the 0x prohibition), and source_tx (add once the bridge tx is sent). The signature parameter is only obliquely referenced ('it fetches the reward signature itself'), leaving its role ambiguous.

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: it drives one Bridge to Earn task for an address, returning status, requirements with have/need/short, and a ready-built next action. This clearly distinguishes it from read-only siblings like get_address_bridge_to_earn and list_bridge_to_earn_tasks by positioning it as the step driver.

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 an explicit loop contract: call with task_id and address, add source/dest_address when the chain is non-EVM (Tron, Solana, Bitcoin, Cardano, XRP Ledger, Sui, never derived from the 0x address), then add source_tx after the bridge transaction is sent. It enumerates every next.action branch (fund, send, wait, done, stop) and exactly what to do in each.

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 destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that it classifies and checks existence, but does not disclose what happens for invalid, malformed, or non-existent identifiers, nor what the output shape is.

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 front-loaded sentence with no filler. It states the action, the accepted inputs, and the secondary behavior, so every word earns its place.

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

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

Given the tool's low complexity (one required string parameter), the description is reasonably complete: it defines the input space and the tool's core purpose. The lack of an output schema means return-value behavior is not documented, and the description could go further on error/not-found semantics, but for a simple resolver the essential calling information is 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?

With 0% schema description coverage, the schema only provides type and length constraints. The description adds needed semantic meaning by enumerating accepted identifier forms: address, transaction hash, block number, and 4-byte selector. It does not specify exact formats such as 0x-prefix requirements, but it substantially compensates for the schema gap.

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

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

The description uses a specific verb ('classifies') plus a concrete set of resource types ('address, transaction hash, block number, or 4-byte selector') and adds the existence-check behavior. It is clear and informative, though it does not explicitly distinguish itself from siblings like lookup_selector or get_transaction; it relies on the reader to infer the difference.

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: when a caller has a Wanchain identifier of an ambiguous type and wants it classified or checked for existence. However, it does not state exclusions or point to alternatives, such as using lookup_selector specifically for selectors or get_transaction when transaction details are needed.

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