WavePay Payments

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 meaningful traits: money movement in two phases, card-only restriction, prepaid/virtual refusal, merchant-key auth, and test-mode preview. It omits reversibility, what happens when a scheduled charge fails, and the idempotency/failure semantics of what is clearly a mutating, charging 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?

Three dense sentences with no filler, and the core mechanic is front-loaded before the restriction and auth details. 'mk_test_ previews it' is terse to the point of ambiguity but does not waste space.

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

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

For a 9-parameter, 7-required mutation with no annotations, no output schema, and 22% schema coverage, the description leaves too much unsaid: the roles of the identity parameters, the meaning of intervalDays, idempotency expectations, and what is returned on success. Adequate only for the headline concept.

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 only 22% across 9 parameters. The description clarifies provider values and the deposit/instalments relationship, but leaves productId, planId, email, externalSubject, intervalDays, and the required idempotencyKey wholly unexplained in both schema and text.

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: take a deposit now and collect the rest on a schedule until paid, which conveys the BNPL plan mechanic in one clause. It is clearly distinct from catalog/pricing/providers siblings, though it never names checkout or subscribe to disambiguate the 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?

Prerequisites are implied (needs a merchant key; mk_test_ previews), which is useful, but there is no explicit statement of when to choose this over wavepay_checkout or wavepay_subscribe, nor any exclusion beyond card-type refusals. 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the required auth header (x-wavepay-service-key with an mk_live_…/mk_test_… key), which is real context an agent needs, but it says nothing about read-only vs mutating behavior, pagination, rate limits, or response shape.

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, scope front-loaded and the auth prerequisite second; every clause carries information and nothing is padded.

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-parameter read tool with no output schema, the description covers what the catalog contains and how to authenticate, which is enough to invoke it correctly. The absence of any statement about read-only nature or result volume is a minor 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 the baseline of 4 applies and there is no parameter-level semantics to add beyond what the schema (an empty object) shows.

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 (the merchant's catalog) and enumerates its contents — sites, plans, prices, coupons — scoped to the caller's merchant key. It is clear what the tool returns, though it never explicitly distinguishes itself from the nearby wavepay_pricing sibling.

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 by 'the sites, plans, prices and coupons your merchant key can see,' which tells an agent this is the merchant-scoped read surface. However, there is no statement of when to prefer it over wavepay_pricing or wavepay_providers, and no 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?

No annotations are provided, so the description carries the full burden. It does disclose the key flow trait – this creates a hosted session and returns a URL to hand to the buyer, i.e. completion happens off-tool – but says nothing about whether a payment/order record is created, idempotency, auth requirements, or error behavior for a mutation 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?

A single dense sentence with the verb and the return value front-loaded and no filler. It is efficient, though the semicolon clause would read better as its own sentence for scanning.

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?

It covers the essential return value (checkoutUrl), which matters since there is no output schema, but for a 6-parameter mutation tool it omits how the buyer's payment is subsequently verified (wavepay_checkout_status), handling of phone vs email, and any failure modes.

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 only 17%; only 'method' is documented in the schema. The description gestures at productId/planId/provider with 'product/plan on a rail' but does not explain the required email/phone fields, nor the coupling between provider='paynow-mobile' and the method wallet enum, nor the defaulting behavior mentioned only in the method field.

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 ('Start a checkout for a product/plan on a rail') and adds the return value ('hosted checkoutUrl'). This clearly distinguishes it from read-only siblings like wavepay_checkout_status, though it never names the alternatives it should be chosen over.

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 by the word 'checkout' – an agent can guess this is for initiating a one-off payment rather than a subscription or BNPL, but the description never says when to pick wavepay_subscribe or wavepay_bnpl instead, nor what preconditions exist.

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 three terminal/non-terminal states (pending | collected | expired), which tells the agent when to stop polling, but omits whether the call is read-only, any rate limits on polling, and auth requirements.

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 zero filler — action, input, and outcome all in one line. It is efficient, though arguably terse to the point of omitting necessary 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?

No output schema exists, and the description at least enumerates the possible status values, which partly compensates. However, for a polling tool it should mention polling cadence/termination conditions and the reference's origin, leaving it adequate 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 description coverage is 0% for the single 'reference' parameter, and the description only restates 'by reference' without specifying its format, origin (e.g., returned by wavepay_checkout), or constraints. The listed states are return values, not parameter semantics, so they add nothing here.

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 ('Poll') and resource ('a payment by reference'), and the enumerated states make the intent unmistakable. It is reasonably distinguishable from siblings like wavepay_checkout (initiation) and wavepay_register, though it never names them 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?

'Poll' implies usage after a checkout, but there is no explicit when-to-use guidance, no mention of the sibling wavepay_checkout that creates the payment, and no statement of when it is unnecessary. Usage is inferable but not directed.

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 meaningful semantics: results are deployment-scoped, gate live money, and are bypassed entirely in test mode. It does not cover permissions, caching/rate limits, or whether flags can change mid-session, so it stops short of full behavioral disclosure.

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 tight sentences with the core scope front-loaded and the test-mode caveat as a clearly subordinate second sentence. Slightly awkward phrasing ('has switched on', no leading verb) costs it a point 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?

There is no output schema and no annotations, so the description is the only contract, and it never states the return shape (names only? name/boolean map? per-environment breakdown). For a simple no-argument read it is close to adequate, but the response format gap leaves the agent guessing how to interpret the result.

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?

Zero parameters, so the baseline is 4; there is no argument to misdocument and the description introduces no parameter claims to contradict.

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 the resource precisely: the set of flagged capabilities enabled on this deployment for live money, and enumerates the flags (refunds, recurring, bnpl, card_tokens, paypal_billing, disputes). It is a discovery/entitlement read, clearly distinct from action siblings like wavepay_refund or wavepay_subscribe, though the phrasing is a noun clause rather than a verb and never literally says 'returns' or 'lists'.

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 sentence 'Test-mode keys can use every one' gives a real selection rule: in test mode there is nothing to check. But it never says when an agent should call this before attempting a sibling operation, and no alternative or prerequisite is named explicitly.

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 behavioral burden. 'Live' hints at real-time, non-cached reads, but the description says nothing about permissions, latency, whether the call is side-effect free, or which rail values are valid.

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 compact sentence with no filler, and the resource (plans and prices) is front-loaded. It is a noun fragment rather than a sentence, which slightly reduces readability but wastes nothing.

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 or annotations, the description partially compensates by describing the returned content (plans, prices, rail breakdown, active promotion). It still leaves 'rail' undefined and does not say what happens when no promotion is active, which an agent needs to interpret results.

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 productId is undocumented anywhere. The description refers to 'a product' but never explains the identifier's format or origin, so it adds no real meaning beyond the schema key 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?

The description names a clear resource and payload — plans, prices, per rail, plus the active promotion for a given product — so an agent knows this returns pricing data rather than performing a transaction. It does not, however, explicitly differentiate itself from the nearest sibling, wavepay_catalog, which likely also exposes plan information.

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 call this versus wavepay_catalog or wavepay_checkout, and no prerequisites or exclusions are stated. The agent must infer that this is the pricing lookup path and the others are not.

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. It discloses useful scope ("this deployment") and effectively enumerates the payload contents, but never states that the call is read-only, whether it is cached, or requires auth. Adequate but missing the safety profile an agent would want.

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 the verb, scope, and payload enumeration all in one pass. Every clause earns its place; nothing is padded or repeated.

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 lookup with no output schema, the description covers what the agent needs: it explains the scope and lists the rails that will be returned. It could go further by noting the read-only nature or that the list is deployment-dependent, but the essentials are present.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4 and there is nothing for the description to disambiguate. No parameter details are needed or missing.

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 ("payment rails this deployment can take") and enumerates the concrete providers, so the agent knows exactly what comes back. It implicitly distinguishes itself from wavepay_catalog and wavepay_pricing by scoping to supported rails, though it never names those siblings 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?

Usage is only implied — an agent can infer this is the discovery call for supported payment methods, but the description never says when to prefer it over wavepay_catalog or wavepay_pricing, nor states any prerequisites. No exclusions or alternatives 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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the PayNow failure mode and its error code, plus the merchant-key auth requirement. However, it says nothing about partial-refund semantics (amountMinor), what revokeAccess actually does, or whether a refund is reversible, which are exactly the mutation traits an agent needs.

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 front-loaded sentences with no filler: what it does, the refusal case, then the auth prerequisite. Every sentence carries information an agent needs.

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-moving mutation with no annotations, no output schema, and zero schema description coverage, this is thin. It never explains what a successful refund returns, how partial refunds behave, or what revokeAccess changes, so an agent could invoke it correctly only by guessing at its most consequential fields.

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 all five parameters (reason, reference, amountMinor, revokeAccess, idempotencyKey) are undocumented in the schema. The description compensates for none of them; the only hint is the merchant-key auth note, which isn't even a parameter. Partial amounts and access revocation remain entirely undefined.

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: 'Refund a settled payment through its provider.' It scopes the operation further (settled only, PayPal/test key) and explicitly names the case it refuses (PayNow -> REFUND_UNSUPPORTED). No sibling in the list performs refunds, so an agent can route here 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?

Gives a clear precondition (payment must be settled) and a clear exclusion (PayNow payments are refused, not recorded). It also notes the merchant-key requirement. It doesn't point to an alternative for the unsupported case, but no sibling offers one, so nothing essential is missing.

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 real work: it discloses that both keys are returned once and only hashes are persisted (an irreversible, unrecoverable outcome), plus a concrete quota of 25 payments per 30 days and that test mode is uncapped and never reaches a provider. It stops short of stating auth requirements, idempotency on duplicate email, or error behavior, so it is not exhaustive.

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, front-loaded with the action, then the one-time key warning, then the quota and sandbox semantics. Every sentence conveys information an agent cannot get from the schema or annotations; nothing is redundant.

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

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

For a two-parameter onboarding tool with no output schema, the description covers what is returned and the consequences of losing it, plus rate limits and test-mode behavior. Remaining gaps are secondary: idempotency on repeat registration, required auth, and what happens on validation 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 100%, so both parameters (name, ownerEmail) are already documented in the schema. The description adds no format or constraint detail for them and instead spends its words on returned keys, which are outputs rather than inputs. 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 specific verb and resource ('Register a WavePay merchant account') and none of the ten sibling tools covers account creation, so an agent can route here unambiguously. The first sentence alone settles 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?

Usage is only implied by the nature of the operation (registration is an onboarding step). There is no explicit guidance on prerequisites such as whether an existing account/key is needed first, and no statement of when-not to call it. The free-versus-test tier note hints at mode selection but is not framed as a routing rule.

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 a good job: it discloses the auth requirement (merchant key), the sandbox/preview behavior of mk_test_ keys, the downstream charging semantics of each collection mode, and what is returned ("the first checkout to hand the buyer"). It omits idempotency/retry behavior and failure modes, which matter for a mutating billing call.

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 dense sentences with the core action front-loaded and no filler; the parenthetical about mk_test_ keys and the mode clause both carry information. Slightly overloaded with parentheticals, but nothing is redundant.

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

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

For an 8-parameter, 6-required billing tool with no annotations and no output schema, the description covers the operation, auth, mode selection, and return value—enough to call it correctly in the common case. The gaps are idempotency semantics and the productId/planId relationship, which an agent must guess.

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 13% (just externalSubject), and the description adds genuine meaning for the collection enum—its two values, which is default, and the mobile-wallet constraint—while implicitly tying provider to PayPal and mobile wallets. But productId, planId, email, phone, and especially idempotencyKey receive no explanation anywhere, so the compensation is 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?

Opens with a specific verb+resource ("Open a subscription for a customer"), which is unambiguous about the operation and the owning entity. It does not explicitly contrast itself with siblings like wavepay_checkout or wavepay_bnpl, though no sibling overlaps its subscription-creation role, so disambiguation is largely 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 real guidance on the collection mode (automatic vs. invoice_and_remind, default, and the mobile-wallet restriction), plus the merchant-key/test-key requirement. However, it never states when to choose this tool over wavepay_checkout, wavepay_bnpl, or wavepay_register, leaving tool selection to inference.

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 test-mode-only operation and the key requirement, and it implies billing simulation side effects by naming renewals, instalments and dunning, but it does not state whether records are mutated, whether the operation is idempotent, or what happens on failure.

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 puts the test-mode constraint first and then explains the simulation effect and use case.

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 billing simulation tool with no annotations and no output schema, the description covers the main purpose, prerequisite, use case and parameter semantics. However, it leaves behavioral gaps around mutation, side effects, idempotency and output, which matter for a billing-engine action.

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 one parameter is explicitly named and semantically explained as the number of days to simulate having passed. It does not document the default when omitted or restate the schema bounds, but the core meaning is clear.

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

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

The description gives a specific verb and resource: run the billing engine as if `advanceDays` had passed. It also scopes the tool to test mode with an `mk_test_` key, which helps distinguish it from live billing operations, though it does not explicitly name sibling tools or 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?

It clearly states the main use case: exercising renewals, instalments and dunning without waiting. The `mk_test_` key and 'Test mode only' phrase provide a prerequisite and an implicit when-not-to-use boundary, but there is no explicit comparison to other tools.

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