AbaPay

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

Annotations already declare destructive, idempotent, open-world, non-read-only. The description adds genuinely new behavior: PIN is required for multi-cancel and re-requested from the human each time, single-id cancel needs no PIN, and an empty selector is refused. It does not discuss irreversibility or return shape, keeping it short of 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-loads the operation, then the safety rules, then the failure mode. Every sentence carries actionable information (sequencing, PIN rules, refusal behavior) with no 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?

A destructive, zero-required-param tool with no output schema is fully covered: selection modes, auth requirements, and the empty-selector guard are all specified. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics beyond the schema: exactly-one cancellation for id, no-PIN rule, and PIN prompting cadence per bulk operation. It reinforces the mutual-exclusion behavior of provider vs id.

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 (cancel) and resource (schedules) scoped to the linked wallet, and explicitly separates single-id cancellation from bulk cancellation via provider/all. It is clearly distinguishable from the sibling list_schedules, which it names.

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 sequencing (call list_schedules first for a real id), names the alternatives (id vs provider vs all) with the condition selecting each, and states what happens with no selector at all (refused rather than cancelling everything). No inference required.

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 convey read-only, idempotent, non-destructive behavior. The description adds value by disclosing the OAuth authorization requirement and the fact that no arguments are needed, which are not expressed 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 sentences with no filler. The purpose is front-loaded, and each sentence earns its place: one for what the tool does and one for the key usage/auth context.

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 robust annotations, a fully self-documenting schema, and no required parameters, this description covers everything needed to call it correctly. It adds the critical OAuth prerequisite and makes the no-argument usage explicit.

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

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

Schema coverage is 100% and the schema fully describes chain and api_key, including the default behavior and OAuth exemption. The description's 'works with no arguments' restates the zero-required-parameter schema but doesn't add meaningful parameter semantics beyond it.

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 verb ('Check') and resource ('a linked wallet's stablecoin balances and remaining agent spending allowance'), making the purpose clear. It doesn't explicitly contrast itself with siblings like transaction_history, but those siblings don't handle balance queries, so the differentiation is implicit.

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

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

The description gives clear usage context: it works with no arguments and requires the connector to be authorized via OAuth. It doesn't explicitly discuss alternatives or exclusions, but no sibling tool closely overlaps in purpose, so the guidance is reasonable.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only that the listing includes currently paused services and example requests, which is mild additional context about dynamic output but nothing beyond what annotations provide regarding behavior.

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

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

Two sentences, both earning their place: the first enumerates the returned content, the second gives the routing hint. The most actionable instruction ("call this first") is placed last as a clear call to action with no filler.

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

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

For a zero-parameter discovery tool with no output schema, the description usefully previews the return content (categories, paused services, examples), which is what an agent needs to decide whether to call it. It could be slightly richer about the response shape, but it is adequate for the tool's simplicity.

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 the baseline is 4. There is nothing for the description to compensate for, and the schema correctly commits to an empty object with additionalProperties false.

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 enumerates the resources returned: payment categories (airtime, data, electricity, cable), paused services, and example requests. This is concrete and distinct from the sibling list_* tools, which return plans or options rather than a capability overview, though it doesn't explicitly name those alternatives.

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?

"Call this first if unsure what is supported" gives a clear triggering condition for invocation. It stops short of naming when NOT to use it or which sibling to prefer once capabilities are known, but the guidance is explicit enough to route an uncertain agent.

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 read-only/idempotent/non-destructive profile, so the description earns credit for adding auth context ('no PIN required') and a real behavioral boundary (wallet-scoped lookup only). It does not, however, discuss rate limits, pagination, or any failure modes beyond that.

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?

Well front-loaded: the core action and accepted identifier forms come first, then status semantics, then the usage routing sentence. It is slightly dense with parenthetical asides but no sentence is truly 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 output schema, the description carries the return-value burden and does so by describing the status vocabulary in plain terms, including refund state. Combined with the wallet-scope and no-PIN notes, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so both parameters are already documented, including the api_key OAuth omission rule. The description's restatement of the reference formats (0x… hash or request id) largely duplicates the schema and adds no new syntax or validation detail, so the baseline 3 applies.

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 concrete verb and resource ('Look up one payment by its reference') and enumerates the possible outcomes (delivered, confirming, failed, refunded), so the agent knows exactly what comes back. It is clearly separable from sibling tools like pay_bill and transaction_history.

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?

Explicitly routes the agent: 'Use this instead of paying again when a pay_bill result was lost,' naming the alternative and the triggering condition, which is precisely the ambiguity an agent faces here. It also states a scope constraint ('Only finds payments made by the linked wallet') that rules out cross-wallet lookups.

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?

Although annotations already declare readOnly, idempotent, and non-destructive behavior, the description adds valuable context: the catalogue is real and live, only currently purchasable plans are shown, and exact IDs must be reused. It also discloses the fixed-price vs flexible-amount payment constraint, which goes beyond the annotation hints.

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 longer than typical but every sentence carries substantive instructions: the browsing order, the mandatory pre-call relationship, and the payment eligibility constraint. It is front-loaded with the 'REAL, live' qualifier and the one-level-at-a-time mechanic, and there is no 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?

Given no output schema, the description compensates by naming exactly what each level returns (countries, product types, operators, plans with codes, foreign price, NGN cost). It also covers the full parameter progression and the integration constraint with pay_bill, so an agent has everything needed to use the tool correctly.

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

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

The input schema already documents all three parameters with 100% coverage. The description reinforces the hierarchical drill-down order and the need to pass back exact values, but it doesn't add new format or semantic details beyond what the schema provides, so the schema-heavy baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as a browser for the live international top-up catalogue, with a specific verb (browse) and resource, and explains the level-by-level traversal. It also distinguishes itself from pay_bill by explicitly stating it must be called before international bill payments.

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

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

Provides explicit when-to-use instructions with a mandatory call sequence ('ALWAYS call this before pay_bill with service: INTERNATIONAL'), what each parameter does when omitted, and a clear exclusion: flexible-amount plans cannot be paid via pay_bill. This is direct, actionable guidance with no ambiguity.

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, idempotent, non-destructive), so the bar is lower; the description still adds that prices are current/volatile and that an empty result must be reported rather than fabricated. It does not discuss pagination or failure modes, but for a read-only listing this is solid added 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?

Two compact sentences with the core listing purpose front-loaded, followed by the mandatory pre-pay_bill sequencing. Every clause carries actionable instruction and there is no 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, and the description fills that gap by saying what comes back (exact codes and current prices) and what to do when nothing usable returns. Enough for an agent to invoke and consume the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by tying the returned codes to the variation_code argument of pay_bill, which is not derivable from this schema alone. The service/provider formats are already documented in the schema, so the added semantics come mainly from that cross-tool linkage.

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 (plans) scoped to three named services, and clarifies it returns exact codes and current prices. It is clearly distinguishable from siblings like list_international_options, list_schedules, and pay_bill, which share the 'list/pay' vocabulary.

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?

Explicitly says to ALWAYS call this before pay_bill for DATA/CABLE/EDUCATION and to pass one of the returned codes as variation_code, plus notes that electricity and airtime have no plan list. This gives both the when-to-use trigger and the downstream call pattern.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description adds genuinely new context: no PIN required and parity with the AbaPay app and Telegram/WhatsApp 'show my schedules' output. That reconciles the tool with surfaces the user already knows.

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 clauses, front-loaded with what is listed, then the safety/permission profile, then the actionable id handoff. Nothing is redundant and no sentence could be cut without losing routing or behavioral value.

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

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

With no output schema, the description partially carries the return burden by disclosing that each schedule comes with an id usable by cancel_schedule. It doesn't enumerate the remaining returned fields (amount, date, frequency), so there is a minor gap for a list tool.

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

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

Schema description coverage is 100% and the single api_key parameter is fully documented in the schema, including the OAuth omission case, so the description needn't repeat it. Baseline 3 applies since the description adds no parameter-level detail beyond what structured data provides.

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

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

Specific verb + resource + scope: 'List active recurring/one-off bill schedules for the linked wallet.' It also distinguishes itself from sibling cancel_schedule by stating the id handoff relationship, so an agent can place it in the workflow without opening another 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?

Names the downstream alternative (cancel_schedule) and the condition that links them — pass the returned id to remove a schedule — which effectively tells the agent when to use this tool. It lacks an explicit when-not-to-use, but the discovery-then-cancel flow 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 mark destructive=true and openWorld=true, and the description adds critical context beyond them: money moves for real, requires human confirmation of amount/provider/account, PIN mandatory on every call even over OAuth, and no delay/schedule capability exists on this connection. It also explains the idempotency_key retry semantics (2-minute identical-call window), which the idempotentHint=false annotation does 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 the core purpose and the highest-risk constraints (list_plans prerequisites, PIN, no scheduling). It is dense and mostly earns its length, though the PIN-every-time warning is restated in the same paragraph and echoed again in the pin schema description — minor 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?

For a 16-parameter, irreversible, open-world mutation with no output schema, the definition covers routing, prerequisites, safety gating, irreversibility, and the scheduling gap. An agent has everything needed to decide whether and how to call it.

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

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

Schema coverage is 100%, so the schema carries the baseline; the description still adds cross-parameter dependency rules not spelled out per-field, notably that INTERNATIONAL uses country/product_type_id/operator_id instead of provider/amount_ngn, and that variation_code is needed for CABLE only when changing package.

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 (pay a real bill from the linked wallet) and enumerates the exact bill categories, including the Nigerian vs international split. It is clearly distinguished from sibling pay_bill_batch and schedule_bill by noting this is the single, immediate payment path.

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?

Explicitly routes the agent: call list_plans first for DATA/CABLE-package-change/EDUCATION, list_international_options for INTERNATIONAL, and never guess country/product_type_id/operator_id. It also states the when-not case for future-dated requests and names the alternatives (AbaPay app, Telegram/WhatsApp/X agent).

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 cover the safety profile (destructiveHint=true, readOnlyHint=false), and the description still adds substantial non-obvious behavior: all-or-nothing capacity refusal, per-recipient reporting after capacity clears, one PIN authorizing the whole batch, immediate execution with no scheduling. It does not restate the annotation that retries are non-idempotent, leaving that to the schema's idempotency_key text, which is the only notable 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?

Front-loaded with the capability and scope, then behavior, then exclusions and the DATA prerequisite. It is dense and effective, though the parenthetical rationalizations (e.g. why partial payment is worse) and the doubled 'executes immediately, same as pay_bill' clause add length that could be trimmed without losing meaning.

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 destructive, open-world payment tool with no output schema, the description covers the essentials an agent needs: batch bounds are in the schema, capacity semantics, all-or-nothing failure mode, per-recipient response shape, PIN scope, and the immediate-execution constraint. Nothing material for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond it: recipients are grouped by (chain, token) and each group's capacity is checked against its own subtotal, plus explicit DATA guidance to call list_plans and supply each recipient's own variation_code. It does not fully explain how batch-level chain/token defaults interact with per-recipient overrides beyond what the schema already says.

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?

Opens with a specific verb+resource+scope: 'Pay airtime or data to multiple recipients in ONE call'. It distinguishes itself from siblings by naming pay_bill (single recipient), schedule_bill (delayed/recurring), and list_plans (DATA prerequisite), so an agent can route correctly 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?

Explicit when-to-use (2+ recipients of AIRTIME/DATA in one authorized batch) and when-not: 'electricity, cable, education, and international are not batchable; call pay_bill for those', single recipient should use pay_bill, and delayed/recurring batches should use schedule_bill once per recipient. Alternatives are named with the conditions that select them.

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?

Adds substantial context beyond the annotations: PIN is ALWAYS required because this creates a standing spend, nothing is charged at execution time, money only moves when the schedule fires and only with a funded on-chain allowance, and the schedule becomes auto-pay vs. notify-only based on the current agent limit. It also notes the response discloses which mode applies.

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 and long, but nearly every sentence carries actionable information and the critical constraint (nothing charged at run time) is front-loaded in the middle. A few clauses (e.g. the Telegram/WhatsApp/X parity remark) are decorative rather than load-bearing.

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 16-parameter mutation tool with no output schema, the description covers prerequisites (PIN, list_plans, allowance funding), the two possible schedule modes, and what the response discloses, leaving no critical gap 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value on top: it explains the PIN requirement's rationale, the list_plans dependency for variation_code, and that the auto-pay/notify-only outcome is reported in the response. It does not add syntax detail for the remaining parameters, keeping it at 4 rather than 5.

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 ('Set up a recurring or future one-off bill payment') and enumerates exactly which services are schedulable (airtime, data, electricity, cable vs. EDUCATION/INTERNATIONAL). Clearly differentiates from the sibling pay_bill by its recurring/future scope.

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?

Explicit routing instructions: call list_plans first for DATA, or CABLE when changing package, use pay_bill directly for EDUCATION/INTERNATIONAL, and use list_schedules/cancel_schedule to inspect or remove schedules. Names both alternatives and the conditions that select them.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new context: no PIN is required, the payload matches the app's History tab, and that the UI card pages by re-invoking the same tool. It does not mention rate limits or freshness/latency of the data.

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

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

Two sentences, purpose front-loaded in the first clause with the returned-field list as parenthetical support. The second sentence is long with several nested clauses, but each carries actionable paging guidance rather than filler.

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

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

With no output schema, the description compensates by enumerating the returned fields (service, provider, amount, status, tx hash); auth is covered by the api_key parameter description and safety by annotations. Paging, scope, and auth are all addressed, leaving nothing essential an agent needs before calling it.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by clarifying the decision boundary for offset (agent should not set it when the card handles paging) rather than merely restating the offset/limit mechanics the schema already documents. It adds no detail on api_key beyond the schema's OAuth note.

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 ('List recent real transactions for the linked wallet') and pins the exact scope by equating it to the app's History tab and enumerating returned fields. 'Real transactions' implicitly separates it from the schedule-oriented siblings (list_schedules, cancel_schedule), so an agent can route without opening the 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?

Gives an explicit conditional for the one ambiguous case: let the interactive card's Next/Previous re-call the tool, and only pass offset manually when the user asks in plain text for 'the next page' or 'transactions before that'. No explicit when-not or sibling-by-name routing (e.g. schedules vs real transactions) is stated, keeping it short of a 5.

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