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

With no annotations, the description carries the full burden and does reasonably well: it discloses single-use ("one-time"), expiry, and the returned artifacts (token, hosted url, embed url), which is meaningful given there is no output schema. It omits auth/credential requirements, rate limits, and what to do with the token after issuance.

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, zero filler, front-loaded with the core verb+resource before appending return values and the framework analogy. 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?

The description compensates for the absent output schema by enumerating return values, which is genuinely useful. However, for an 8-parameter mutation tool with no annotations, it leaves the recurring/subscription parameters and auth surface entirely unexplained, so it is only minimally complete.

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

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

Schema coverage is only 63%, and the description adds no parameter-level meaning at all — not even for undocumented fields such as the bare `description`, `recurring_interval`, or `recurring_interval_days`. The subscription path (`is_recurring`, `recurring_interval*`) is never explained in prose, 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?

"Mint a one-time, expiring Ultraner checkout token" gives a specific verb and resource, and the Stripe checkout.sessions.create analogy pins down the concept precisely. It still does not explicitly distinguish this unified hosted-checkout tool from siblings like create_stripe_session, create_paypal_order or create_mobile_money_payment.

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 only implied: the description conveys that the payer selects the method on a hosted page, which hints at a hosted-flow scenario, but it never states when to choose this over the direct create_*_payment siblings or what prerequisites exist. An agent must infer the routing decision.

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

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

With no annotations, the description carries the full burden and does disclose two non-obvious traits: an environment/auth requirement (ULTRANER_SIGNATURE_KEY, and the reason — the API needs a signature naming the authoriser) and a restricted market footprint relative to collection. It still omits idempotency, failure modes, and whether funds move immediately, so it is not fully transparent.

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 short, front-loaded sentences with no filler; the core action leads and the constraints follow. The ULTRANER_SIGNATURE_KEY reference is slightly cryptic without context on where the key comes from, but the text is otherwise tight.

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 6-parameter mutation tool with no annotations, no output schema, and low schema coverage, the description covers auth and availability but says nothing about parameter usage, idempotency, or the result of a successful call. It is adequate for a cautious agent but not complete.

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

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

Schema coverage is only 33% (network and account_number are documented in the schema), yet the description adds no parameter-level meaning at all — amount, currency, remarks, and recipient_name are undocumented in both places. For a payment tool where amount/currency semantics matter, this leaves real gaps.

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: 'Pay money out to a mobile wallet', which maps cleanly onto a disbursement/payout operation and contrasts with the 'collection' direction mentioned later. It does not, however, differentiate itself from the sibling create_mobile_money_payment, which sounds like it could cover the same ground.

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 context ('live in fewer markets than collection') and gives one precondition: check get_capabilities for market availability. It never says when to prefer this tool over create_mobile_money_payment or the other create_* siblings, so the routing guidance is incomplete.

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

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

With no annotations, the description carries the full burden, but it does disclose the core behavioral model: funds are held, not forwarded, so neither party bears first-mover risk. It omits auth requirements, who the payer is (implicit in the caller), fees, and what happens to funds if never released, leaving meaningful gaps for a financial mutation.

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 with zero waste, and the core mechanic (hold vs. forward) is front-loaded. Every clause adds 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 money-movement mutation with no annotations and no output schema, the description explains the hold mechanic but omits preconditions, the release counterpart, fees, and hold expiration. It is adequate to understand intent but thin on operational detail.

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 amount, seller_phone, and condition are already documented in the schema. The description adds no format or constraint detail beyond that; the allusion to "the payer" only hints that the paying side is derived from context rather than passed as a 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 states a clear action and mechanism ("Hold funds until released", money taken from the payer and held rather than forwarded), so an agent understands this creates a held-funds transaction. It does not differentiate from the sibling release_escrow, which is the natural counterpart, and never frames the operation as "create an escrow transaction".

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 when-to-use guidance, no prerequisites, and no mention of release_escrow as the downstream step that frees the held funds. The agent must infer from the name alone when this is the right tool versus create_mobile_money_payment or create_disbursement.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the dependency chain and that amount interpretation is currency-dependent, which is real context. But it is silent on whether the charge is synchronous, idempotency, failure/refund behavior, and authentication requirements — significant gaps for a money-movement operation.

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, no filler, front-loaded with the action and scope, followed immediately by the prerequisite calls. Every clause 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?

For a 5-parameter payment-initiation tool with no annotations and no output schema, the description covers inputs and prerequisites but omits the lifecycle after invocation — notably that get_payment_status is the way to track the result. That omission leaves the agent without a post-call 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 coverage is 60%, and the description compensates for the key gaps: it explains where 'provider' comes from (providerCode from get_supported_countries) and resolves the ambiguous amount unit (whole units vs. cents depending on currency). currency and merchant_reference remain undocumented in both places.

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 ('Charge') and resource ('African mobile-money wallet'), then names concrete providers (M-Pesa, Airtel, MTN, Mixx by Yas). This clearly separates it from sibling creation tools such as create_disbursement, create_escrow, and create_paypal_order without the agent needing to open a 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?

Explicitly prescribes a prerequisite ordering: call get_supported_countries first for the provider code, and get_supported_currencies for unit interpretation. That is actionable routing to siblings. It does not, however, state when NOT to use this tool (e.g. payouts vs. collection, or regional 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a mutation via 'Create' but says nothing about required auth, idempotency, whether a redirect/approval URL is returned, or what happens to the order afterward — critical for a payment-initiation 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 front-loaded sentence with no filler; the constraint trails the verb+resource in a sensible order. It is efficient, though its brevity borders on under-specification for a payment 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 5-parameter mutation tool with no annotations and no output schema, one sentence is far from enough. An agent cannot tell what the call returns, how to select it over sibling payment creators, or how the undocumented parameters behave.

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 only 40% schema description coverage across 5 parameters, the description needed to compensate and does not. It adds no meaning for email, currency, or promo_code, and nothing about the syntax or constraints of token/amount beyond what the schema already states.

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

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

The description names a specific verb and resource ('Create a PayPal order') and adds a scope qualifier ('for international payers'), which lets an agent tell it apart from the sibling create_stripe_session or create_mobile_money_payment by payment method. However, the 'international payers' qualifier is unexplained and no sibling is named explicitly.

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

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

There is no when-to-use guidance and no routing against the many alternatives (create_stripe_session, create_checkout_session, create_mobile_money_payment). 'For international payers' hints at a selection condition but never states what makes PayPal the right choice over a generic checkout session.

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

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

With no annotations, the description carries the full behavioral burden for a tool that creates an external payment resource. It doesn't disclose what is returned (session URL or token), whether the call is idempotent, what auth/API key is needed, or how embed vs redirect changes behavior. Only the card-payment scope is added beyond the schema.

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

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

A single front-loaded sentence with no filler, which is structurally clean. The terseness comes at the cost of the missing guidance, so it reads as under-specified rather than optimally concise.

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 payment-session creation tool with no annotations, no output schema, and 40% of parameters undocumented leaves the agent without return-value, auth, or failure context. The description should carry this load but does not.

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 60%: token, embed, and amount are documented in the schema, while email and promo_code are bare, and the description adds no parameter meaning at all. It does not explain that token is the checkout link being paid or clarify amount's open-amount restriction, so it 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 (create a Stripe checkout session) plus a scope qualifier (for card payments), which helps separate it from create_paypal_order and create_checkout_session. It never explicitly names a sibling, so the differentiation is implicit rather than stated.

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 when-to-use guidance, no prerequisites, and no alternatives, despite the sibling list containing near-neighbors like create_checkout_session, create_paypal_order, and create_mobile_money_payment. An agent must guess why it would pick Stripe/card over the other payment-creation 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?

No annotations are supplied, so the description carries the full burden. It does disclose what the response contains (each capability with status, market variance, and caveats), which is genuine behavioral value, but it says nothing about read-only nature, authentication, rate limits, or result size — acceptable for a zero-param getter, 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?

One front-loaded sentence with the resource stated first and the return contents in a compact parenthetical. The enumerated capability list is slightly dense but each element adds scope information 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 must convey return value; it does so at a summary level (status, market variance, caveats). For a simple parameterless capability listing, that is close to sufficient, though the shape of the returned structure remains 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 tool takes no parameters, so there is nothing to document and no coverage gap to compensate for; the baseline for a zero-parameter tool 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?

The description gives a clear resource — the platform's capabilities — and even enumerates the domains covered (collect, disburse, settle, escrow, subscriptions, FX). It is distinguishable from action siblings like create_escrow, though it overlaps conceptually with get_use_cases and does not explicitly say how it differs.

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 statement of when to call this versus the many sibling discovery tools (get_use_cases, get_supported_countries, get_payment_networks). The only implicit signal is the broad 'and the rest' framing, which hints at a catalog overview but names no alternative or condition.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the payload is capability-only and therefore stale/indicative rather than a binding quote, which implies a read with no side effects. However, it says nothing about authentication, rate limits, response size, or freshness, leaving notable gaps for a zero-annotation tool.

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

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

Two short sentences with no padding, and the payload contents are front-loaded ahead of the caution about quoting. The first sentence is a dense fragment rather than a full clause, which costs a little readability but not efficiency.

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 no-argument, no-output-schema listing tool the description covers the essential question: what fields come back and how much to trust them. Missing pieces are what the shape of the returned records looks like, whether the list is paginated, and whether credentials are required.

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, which is the baseline-4 case. The description adds nothing parameter-related because there is nothing to add, and the empty schema means there is no ambiguity for an agent to resolve.

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 concretely enumerates what the tool returns: which markets can pay which, whether an FX rate applies, and whether the two ends use different minor units. That makes the resource ('payment corridors' capability data) clear even though it is written as a noun-phrase fragment with no explicit verb. It does not differentiate itself from lookalike siblings such as get_supported_countries, get_supported_currencies, or get_capabilities.

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?

'Capability only: quote a specific corridor through the API before relying on it' tells the agent this is discovery/indicative data and that a separate quoting step is required before acting on it. That is real usage guidance, but it never names the alternative tool or endpoint, so the routing decision is still partly inferential.

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

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

With no annotations at all, the description carries the full burden, and it does disclose one genuinely non-obvious behavior: that unavailable brands are deliberately included so callers do not assume their existence. It says nothing about authentication, rate limits, response format, or how freshness/availability is determined, so the disclosure is partial rather than 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?

Two short sentences with no filler, and the core content (brands, markets, provider codes) is front-loaded. The second sentence is slightly awkwardly worded ('so they are not assumed') but still earns its place by flagging a non-obvious inclusion behavior.

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 usefully enumerates the payload contents — brands, markets reached, and provider-selecting codes — which is most of what an agent needs. It stops short of explaining how provider codes feed into tools like create_mobile_money_payment or what the record shape looks like.

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 of 4 applies per the rubric. The description has no parameters to explain and correctly avoids inventing any; it instead spends its words on what the call returns.

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 — mobile-money brands, their markets, and provider codes — so an agent can tell this is a network/brand catalog tool. However it never uses a verb (list/get/retrieve) and does not name or contrast itself with siblings like get_supported_countries or get_supported_currencies, leaving some 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?

There is no explicit when-to-use statement, no prerequisites, and no mention of any sibling tool. The only usage-adjacent signal is the note that unavailable brands are included, which hints at why an agent should consult this list rather than assume a brand exists, but that is indirect guidance at best.

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

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

With no annotations provided, the description carries the full behavioral burden. It does not disclose whether the call is read-only/idempotent, what happens when the reference is unknown, what status values can be returned, or any auth/rate-limit constraints.

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 short sentence with the action and lookup key front-loaded and no wasted words. It is efficiently structured, though brevity here borders on under-specification rather than true conciseness.

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 annotations, so the description should explain what a payment status response contains and what the possible statuses mean. As written, an agent cannot tell what it will receive back after a successful or failed lookup.

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 parameter has no description, so the description must compensate. It only implies the parameter is a payment reference ('Ultraner reference') and gives no format, example, or validation detail, adding little beyond the schema's 'reference' field name.

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 ('Check') and resource ('payment') and identifies the lookup key ('Ultraner reference'), which is enough for an agent to understand the operation. It does not, however, differentiate itself from sibling readers such as list_transactions or get_wallet, so a weak but real clarity gap remains.

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 statement of when to use this tool versus list_transactions or the various create_* tools, and no mention of prerequisites. Usage is only implied by the verb 'Check'.

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

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

With no annotations, the description carries full behavioral burden. It usefully discloses that this is a keyless, read-only discovery call ('Needs no API key'), which tells an agent it can call it before authenticating. Beyond that, it says nothing about rate limits, caching, or freshness of the 'live' status.

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 content list front-loaded and the auth fact appended. The first sentence is dense and slightly run-on, but no sentence 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 zero-parameter reference tool with no output schema, the description enumerates the returned fields (market, live status, currency, provider code), which largely substitutes for the missing output schema. Only edge behaviors like pagination or data freshness are 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface the description could meaningfully elaborate on.

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 the resource (markets/countries) and enumerates the exact fields returned: live status, currency, and provider code per mobile-money network. It's clear what the tool does, but it never explicitly distinguishes itself from siblings like get_supported_currencies or get_payment_networks, whose scopes overlap with the fields mentioned.

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 explicit when-to-use guidance or exclusion relative to siblings such as get_supported_currencies or get_corridors. The note 'Needs no API key' is an invocation-relevant prerequisite, which gives some usable context, but usage 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?

No annotations are provided, so the description carries the full burden. It discharges that well by disclosing the returned shape (decimals per currency, shared countries) and a concrete operational rule about African currencies having no minor unit, which directly affects how the agent builds amounts. It stops short of explicitly declaring read-only/no side-effects.

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, zero waste, and front-loaded: what you get first, then the actionable constraint that motivates calling it. Every clause 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 and no annotations, the description must cover the return contract, and it does by naming the three fields returned. Zero-param schema removes any parameter gap. The only shortfall is the absent explicit contrast with get_supported_countries.

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 clarify beyond what an empty schema already communicates.

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 and enumerates its content: every settlement currency, decimal places, and country sharing. However it never explicitly distinguishes itself from the adjacent get_supported_countries sibling, so an agent must infer the split from the word 'currency'.

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 triggering context: 'Read this before constructing an amount.' That is a usable when-to-use cue, but no exclusion or named alternative is offered, so it stops short of full routing 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?

No annotations are provided, but this is a zero-parameter lookup with no mutation surface, so the disclosure burden is low. The description conveys what it returns (jobs and the capabilities each needs) but says nothing about the result's structure or size, so it is adequate but thin.

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 with zero filler; the content description is front-loaded and the usage hint follows. Every clause 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?

For a parameterless, read-only discovery tool with no output schema, the description covers what the agent can expect to get back well enough to decide to call it. A brief hint about the return shape would close the remaining 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?

The tool takes zero parameters, so by rule the baseline is 4. There is no parameter syntax for the description to clarify, and none is needed.

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

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

The description gives a specific content type: common business jobs ('use cases') and the capabilities each requires. It is distinguishable from siblings like get_capabilities because it maps goals to capability sets rather than listing capabilities themselves. No explicit sibling reference, but the resource is 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?

It provides a concrete usage scenario ('turning "I am building a marketplace" into the right set of calls'), which implies when to reach for it. However, it names no alternatives or exclusions, and does not say when NOT to use it versus get_capabilities or get_supported_countries, so guidance remains inferred rather than directive.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description omits authentication requirements, error behavior, and any rate or scope limitations.

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 wasted words. It is appropriately sized for a zero-parameter retrieval 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 annotations, no output schema, and no parameters, the description is the only source of context. It does not explain whose wallet is being queried, what format balances are returned in, or whether authentication is required, leaving key context 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?

The tool takes zero parameters, which sets the baseline at 4. There are no parameter semantics to clarify 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 states a specific verb ('Get') and resource ('Ultraner wallet balances'), making the tool's function clear. However, it does not differentiate from siblings or clarify scope such as whether it returns one wallet or all wallets for the account.

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 on when to use this tool versus alternatives or any prerequisites. The description only states what the tool does, leaving usage context entirely 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?

No annotations are provided, so the description carries the entire behavioral burden and discloses nothing: no default limit, no ordering, no pagination behavior, no auth requirements, and no notion of what 'recent' means in time or count. For a mutation-free but parameterized list operation, this is a near-total 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?

It is a single front-loaded sentence with no filler, which is structurally clean. But at three words it is under-specified rather than concise — the brevity comes from omitting required information, not from efficient phrasing.

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 annotations, no output schema, and no documented parameters, the description is the only source of contract information and supplies none of it. An agent cannot determine result shape, ordering, or how the two filters interact.

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 two parameters, so the description must compensate and does not. Neither 'limit' (default? max?) nor the 'status' enum (the schema lists values but not their meanings) is explained, so an agent must guess at filtering and paging semantics.

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

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

The description names a clear verb ('List') and resource ('transactions'), which is enough for an agent to recognize the operation. However, 'recent' is an undefined scope qualifier and there is no differentiation from any sibling tool, leaving the purpose only vaguely bounded.

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 statement of when to call this tool, when not to, or what alternative to use. The siblings are mostly configuration getters and payment creators, so an agent could infer this is the read-side counterpart, but the description provides zero explicit 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?

With no annotations the description carries the full burden, and it does disclose two important traits: money moves and the call is irreversible ('cannot be undone by the same call'), hinting a separate reversal path may exist. It says nothing about permissions, required escrow status, or failure behavior for a money-moving mutation.

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, zero waste, with the action and its irreversibility front-loaded. Every clause 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?

Low complexity (one required param) keeps the bar modest, but for an irreversible money movement with no annotations and no output schema, the description omits preconditions, authorization, and what the caller receives on success.

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 escrowId description already disambiguates id vs code, so the schema does the work. The tool description adds no parameter guidance beyond that, which is the expected baseline for a fully documented single 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 (release) plus resource (escrow hold) and the direction of the action (to its recipient). No sibling tool overlaps with escrow release, so an agent can select it unambiguously.

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 only implied: you call this when an escrow hold is to be paid out. There is no statement of preconditions (escrow state, who may release, timing relative to create_escrow) and no explicit when-not guidance.

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