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

With no annotations, the description carries the full disclosure burden, and it does real work: it scopes the result to unpaid invoices only, defines the bucket boundaries, specifies units as integer cents, and notes grouping per currency. It stops short of stating read-only safety or whether it aggregates across all entities with no filtering.

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 filler: the first sentence front-loads the payload and its exact dimensions, the second gives the use case. Everything 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?

Despite having no output schema and no annotations, the description defines the bucket structure, units, and grouping well enough for an agent to know what comes back. Only the aging-date behavior (how 'on' reshapes buckets) and read-only nature are left unaddressed.

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

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

Schema description coverage is 100% and the single 'on' parameter is fully documented in the schema (YYYY-MM-DD, default today). The description adds no extra meaning about the aging date or how buckets shift relative to it, 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?

The description names a specific artifact (aging summary across every unpaid invoice) and enumerates the exact buckets it produces, so the resource is unambiguous. It does not explicitly carve itself apart from close siblings like overdue_list or invoice_status, so the differentiation is left to inference 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 framing line 'the answer to "how much am I owed, and how stale is it"' implies the use case but never states when to pick this over overdue_list or invoice_status, nor any exclusions or prerequisites. Usage is implied, not guided.

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 load and does disclose meaningful behaviour: it is an advisory listing (it says which letter to send, not that it sends one) and it explicitly flags the boundary case of invoices that fall outside the server's capability. It stops short of stating read-only status, side effects, or permission 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 dense sentence that front-loads the purpose and then lists four distinct output categories, with no filler. It is a long clause chain that could be split for scanability, but every clause carries information.

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 describe what comes back, and it does so concretely across all four result categories while implicitly covering both inputs. It omits read-only/mutation status and result shape details, which is the remaining gap for a two-parameter report 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 both parameters are optional and fully documented in the schema (including the 'see what Monday will need' example and the default). The description adds only the loose mapping of "what falls due in the next few days" to within_days, 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?

The description enumerates exactly what the tool produces: today's escalation-crossing invoices, the letter recommended for each and its waiting time, upcoming due items, and fully-lettered invoices needing an out-of-server decision. That is far more specific than the title alone, though it never names a sibling (overdue_list, aging_summary) to draw the boundary.

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 day's chase list" and by the note that exhausted cases "need a decision outside this server," which quietly tells the agent when this tool is not the answer. There is no explicit statement of when to prefer it over overdue_list or aging_summary, so the guidance remains 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, the description carries the full burden and does substantial work: it discloses the cascade (record, payments and letter history all removed), the permanence of the id, and the observable side effect of a DUN series gap. It stops short of stating auth requirements, reversibility, or failure 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?

Front-loaded with the verb and identifier, and the destructive scope is stated immediately after. The trailing sentence about the DUN series gap is a bit indirect but is genuinely informative rather than filler.

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

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

For a one-parameter destructive tool with no annotations and no output schema, the key things an agent must know (what gets removed, that it is permanent) are covered. Auth/permission requirements and error handling remain unstated, 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?

Schema description coverage is 100% for the single parameter, and the schema already documents both id format (DUN-2026-0001) and reference. The description adds only the same id-or-reference duality, so it earns the baseline 3 rather than more.

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 (delete) and resource (invoice) plus the accepted identifiers (id or reference). It is clearly distinct from the sibling read tools like invoice_register and invoice_status, though it never names an alternative tool 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?

"Delete an invoice entered wrongly" implies the intended use case (correcting a mistaken entry), which is useful framing. However there is no explicit when-not guidance, no prerequisites, and no mention of any alternative remedy for a bad invoice.

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 return shape (reminder 1/2/final notice with due dates) and a quota (free tier: 3 concurrent invoices), but says nothing about permissions, idempotency, or what happens when a duplicate invoice is already on the register.

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, front-loaded with the action and outcome, then the tier constraint. Slightly wasteful in re-listing the required parameters that the schema already names, but no fluff overall.

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 10-parameter mutation tool with no annotations and no output schema, the description compensates well by explaining what is returned (the escalation ladder and its dates). Gaps remain around duplicate handling and permissions, but the core call-and-result picture is 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 90%, so the schema already documents fields like amount_minor, currency, due and gaps. The description only restates 'amount in integer cents' and the field list, adding no meaning beyond the schema; 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?

The description states a specific verb (register) and resource (an unpaid invoice) and specifies the concrete payoff: a three-step escalation schedule with dates. It is clearly distinguishable from read-only siblings like invoice_status or overdue_list, but it never names an alternative tool, so it stops short of full sibling differentiation.

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?

'Start chasing an unpaid invoice' implies the trigger condition, and the free-tier limit (3 concurrent unpaid invoices) is a real usage constraint. However, there is no guidance on alternatives (e.g. invoice_status, chase_today) or on prerequisites such as what to do when the invoice is already registered.

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 discloses the returned content in useful detail — payment state, each letter with its date, escalation stages and their individual states, and the next action with timing — which tells an agent what to expect from a read. It stops short of stating that the call is read-only or what happens for an unknown invoice reference.

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 opens with the scope ('one chased invoice in full') and then enumerates the payload. It reads as a long run-on list, but every clause describes distinct returned content, so little is wasted.

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

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

There is no output schema, so the description must convey the return shape, and it does so thoroughly (amounts, letters, escalation schedule, next action). With parameters fully documented in the schema and only two of them, the definition is nearly complete; only read-only status and error behavior are unstated.

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 both parameters carry their own format guidance (invoice id vs. reference, the 'on' date with default today), so the schema does the heavy lifting. The description adds nothing about parameters, which is the expected baseline when coverage is complete.

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

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

The description states a specific resource ('one chased invoice in full') and enumerates exactly what state it reports — billed, paid, owed, letters, escalation schedule. The word 'one' implicitly separates it from the list-oriented siblings (overdue_list, aging_summary, invoice_register), but no sibling is named, so it stops short of a 5.

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

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

Usage is only implied: the phrase 'one chased invoice' signals a single-invoice lookup rather than an aggregate view, which is the natural alternative among the siblings. There is no explicit when-to-use, no named alternative, and no stated prerequisites or exclusion conditions.

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 the most important thing: it disproves the obvious assumption that this tool sends the letter ('Nothing is emailed or sent anywhere... sending it is your act'). It also hints at ladder state advancement. It does not cover error behavior or whether re-issuing a sent letter has 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 and every clause earns its place, with the core action front-loaded. The dense em-dash parenthetical in the first sentence slightly hurts scanability, 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?

No output schema, and the description covers what an agent needs: what is produced (letter text in Markdown or printable HTML), that nothing is transmitted, how to act on it (letter_sent), plus stage/date/format semantics. Nothing material is missing for a rendering 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 a 3 is the baseline, but the description adds real meaning: it explains what each stage value produces ('reminder 1 polite, reminder 2 firm with the late fees note, final notice before-action wording') and that html is 'self-contained printable,' which the enum labels alone do not convey.

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 ('generate the letter for the current stage of the ladder') and enumerates the three stage variants, so an agent can distinguish it from letter_sent, chase_today, and aging_summary 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?

Gives the triggering condition (chasing an unpaid invoice at the currently-due stage), an override condition for the stage param ('to preview or to re-issue a letter already sent'), and routes the follow-up action explicitly: 'Record the sending with letter_sent so the ladder advances.'

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 burden and does well: it discloses the mutation's side effect (ladder advances), a validation ordering rule that can cause rejection, and the return content ('what is due next and when') despite there being no output schema. It omits any mention of permissions or what happens on out-of-order or duplicate submissions.

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 sentences, front-loaded with the action and effect, then the ordering rule, then the return value. Nothing is redundant or 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 3-parameter mutation with no annotations and no output schema, the description supplies effect, ordering validation, and even the return payload, so an agent can invoke it correctly. Minor gaps remain around error/permission behavior on invalid submissions.

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 'sent' (YYYY-MM-DD, default today), 'stage' (enum 1-3, default lowest unsent) and 'invoice' (id or reference) are already fully documented. The description only broadly restates the date and hints at the stage ordering, adding little beyond the schema — baseline 3.

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

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

States a specific verb+resource (record a chase letter as sent) and its effect (advances the dunning ladder). It is clearly distinguished from the sibling letter_render, which produces the letter rather than recording it.

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

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

Establishes the triggering condition (the letter was 'actually sent') and gives an explicit ordering constraint: reminder 2 cannot be recorded before reminder 1. It does not name letter_render or other siblings as the alternative for the 'generate the letter' path, so routing is left partly 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 provided, the description carries the full behavioral burden. It discloses that verification happens offline against a built-in public key, that the key is persisted to the config file, and that invalid keys are refused and left unsaved. This is substantial transparency for an activation tool, though it could mention overwriting an existing key or the exact return 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?

The description is two sentences with no filler. The first sentence front-loads the main action, source, verification method, and persistence. The second sentence efficiently covers error handling and points to the related read-back tool. Every clause adds 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?

Given a single-parameter tool with no output schema and no annotations, the description covers activation behavior, verification mechanism, persistence, error outcomes, and how to read the result later. The only minor gap is an explicit statement of what the function returns upon success or failure, but the phrase 'refused, unsaved' implies a feedback mechanism. Overall, it is sufficiently complete for an agent to call it correctly.

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

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

The schema already documents the 'key' parameter at 100% coverage, so the baseline is 3. The description adds meaningful semantics by giving the concrete key format ('MCPL1.xxx.yyy'), confirming the key comes from the checkout page, and explaining that malformed or expired keys will be rejected. This goes beyond the schema's one-line 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 action ('Activate a Pro key'), the exact key format ('MCPL1.xxx.yyy'), the source ('from checkout'), and the core mechanism ('verified offline against a built-in public key'). It also differentiates itself from the sibling license_status by noting that license_status reads the activation back, so there is no ambiguity about which tool does what.

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

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

The description gives clear context: use this when you have a Pro key from checkout that needs to be activated. It also points to license_status as the read-back tool, which implies when to use a related sibling. It does not explicitly spell out 'do not use for checking status' or list other alternatives, but the context is strong enough to avoid misuse.

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 are absent, so the description carries the full burden of behavioral disclosure. It discloses that the call is local ('no network') and argument-free, and it mentions a specific explanatory behavior. The word 'Report' implies read-only, though it does not explicitly state non-destructive or permission requirements; this is adequate for a status command.

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 first sentence lists the output fields; the second adds constraints and the sibling pointer. Every clause contributes meaningful information.

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 status tool with no output schema, the description lists the expected output fields, behavioral constraints, and the relevant alternative tool. Nothing an agent needs to call it correctly 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?

The schema has zero parameters and the description reinforces this with 'No arguments'. It adds value by listing the reported fields, helping an agent understand what the empty input will yield. The baseline for zero-parameter tools is high, and the description meets 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 states a specific verb ('Report'), a clear resource ('this server's licence state'), and enumerates the exact fields returned. It also names the sibling 'license_activate' as the tool that does something different, so an agent can distinguish them immediately.

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 explicit usage constraints: no arguments, no network, and explains a free-tier refusal. It also directs the agent to license_activate when the task is to install a key, serving as an explicit pointer to the relevant alternative.

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 meaningful work: it discloses the derived fields returned (days late, amount owed, letters sent, next due date) and the sort order (days late, worst first). Read-only nature is only implied by 'list', and permissions/limits/rate behavior are unaddressed, so not a 5.

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

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

A single dense sentence with the scope front-loaded and a trailing clause on ordering; there is no filler. The clause 'what is due next and when' is slightly loose, keeping it just short of a 5.

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

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

For a read-only list tool with no output schema and no annotations, the description compensates well by describing the shape and ordering of results. It leaves minor gaps around the as-of date semantics and the 2000-row default/ceiling, but those live in the schema.

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 (as-of date and row limit) are already documented in the schema. The description adds nothing parameter-specific — notably it never mentions that lateness is judged against a caller-supplied date — 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?

The description gives a specific verb/resource (list unpaid invoices past due date) and enumerates the returned fields, so an agent knows exactly what it produces. It does not, however, distinguish itself from close siblings like aging_summary or chase_today, so a 4 rather than a 5.

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

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

There is no explicit when-to-use guidance, no exclusions, and no naming of alternatives such as aging_summary (aggregate view) or chase_today (action on today's chases). Scope is implied by the field list, but the agent gets no routing help for a crowded sibling set.

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 well: it discloses that a partial payment reduces the outstanding chased amount, that a covering payment closes the invoice and frees the free-tier slot, and that the return value is the outstanding amount. It omits permissions, idempotency/duplicate handling, and which currency the minor units belong to.

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 leads with the action and then packs the two key consequences efficiently. The domain shorthand ('closes the ladder', 'frees the free-tier slot') is slightly jargon-heavy but still parses without prior 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 mutation tool with no annotations and no output schema, the description covers the essential state change and the return value ('outstanding amount'). It is nearly complete, missing only permission requirements, idempotency behavior, and overpayment handling.

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 all four parameters are already documented, making 3 the baseline. The description adds only the semantic effect of amount_minor (partial vs. covering payment) and repeats the 'whole MINOR units' convention already in the schema; date, note, and invoice semantics are left entirely to the schema.

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

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

The description gives a precise verb+resource ('Record money received against a chased invoice') and specifies the unit convention, so the operation is unambiguous. It stops short of contrasting itself with siblings such as invoice_register or invoice_status, so it does not reach the sibling-differentiation bar for a 5.

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

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

Usage is only implied by the phrase 'against a chased invoice' – the agent can infer this applies when money arrives for an outstanding chased invoice, but there is no explicit when-to-use, when-not, or named alternative. No guidance is given on duplicate payments or what happens if the amount exceeds the balance.

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