Chase overdue invoices: reminder 1, reminder 2, final notice, escalation dates, aging.
Scored across 11 tools
Most tools have clearly distinct purposes: single-invoice operations (invoice_status), aggregate views (aging_summary), and ladder actions (letter_render, letter_sent) are separable. The three list-style views (aging_summary, overdue_list, chase_today) overlap in that they all report on unpaid invoices, though each frames it differently (buckets, overdue severity, today's actions), which could occasionally cause misselection.
All names are snake_case and follow a predictable noun_action pattern (invoice_register, letter_render, payment_record, license_status). Minor deviation where some are noun_noun descriptors (aging_summary, overdue_list, chase_today) rather than verb-driven, but the style is uniform and readable.
11 tools is well-scoped for a dunning/collections server, with each tool earning its place across registration, status, letters, payments, reporting, and licensing. No bloat and no obvious filler.
Core lifecycle is well covered: register, status, delete, record payments, render/record letters, plus aging and overdue reporting. Minor gaps exist (no invoice_update to edit details after registration, and no way to reverse a mistaken payment or letter), but agents can work around these with delete/re-register.
The aging summary across every unpaid invoice: current, 1-30, 31-60, 61-90 and 91+ day buckets, with counts and totals in integer cents, per currency. This is the answer to "how much am I owed, and how stale is it".
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | The date to age against, YYYY-MM-DD. Default today |
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.
The day's chase list: which invoices cross an escalation threshold today, which letter to send each and how long it has been waiting, what falls due in the next few days, and which invoices have had all three letters and need a decision outside this server.
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | The date to run the list for, YYYY-MM-DD, e.g. to see what Monday will need. Default today | |
| within_days | No | How far ahead to list letters coming due, default 7 days |
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.
Delete an invoice entered wrongly, by id or reference: the record, its payments and its letter history. The id is not reissued, so a gap in the DUN series is the record that a deletion happened.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice | Yes | The chased invoice: its id (DUN-2026-0001) or its invoice reference |
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.
Start chasing an unpaid invoice: register the client, the invoice reference, the amount in integer cents, the currency and the due date, and get the three-letter escalation schedule (reminder 1, reminder 2, final notice) with the date each falls due. Free tier: 3 unpaid invoices chased at once.
| Name | Required | Description | Default |
|---|---|---|---|
| due | Yes | The date payment fell due, YYYY-MM-DD. The ladder is anchored to this date | |
| gaps | No | Days after the due date at which reminder 1, reminder 2 and the final notice fall due, strictly increasing. Default [7, 14, 21] | |
| note | No | ||
| client | Yes | Who owes the money, e.g. Acme Ltd | |
| issued | No | The date the invoice was issued, YYYY-MM-DD, for the letter's reference line | |
| currency | Yes | ISO code the invoice was issued in | |
| reference | Yes | The invoice number being chased, e.g. INV-1042 | |
| amount_minor | Yes | The invoice amount in whole minor units (integer cents). 125000 is USD 1,250.00 | |
| duplicate_ok | No | Register even though an identical invoice is already on the register. Default false | |
| late_fee_percent_per_month | No | Late payment interest your terms allow, percent per month, simple and pro-rata. When set, reminder 2 and the final notice state the accrued figure |
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.
One chased invoice in full: what was billed, what has been paid and what is still owed, every letter sent with its date, the escalation schedule with each stage's state, and what happens next and when.
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | The date to judge lateness against, YYYY-MM-DD. Default today | |
| invoice | Yes | The chased invoice: its id (DUN-2026-0001) or its invoice reference |
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.
Chase an unpaid invoice: generate the letter for the current stage of the ladder -- reminder 1 (polite), reminder 2 (firm, with the late fees note) or the final notice (before-action wording) -- as Markdown or as self-contained printable HTML. Nothing is emailed or sent anywhere: this server produces the letter text, and sending it is your act. Record the sending with letter_sent so the ladder advances.
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | The letter's date, YYYY-MM-DD; late fees accrue to it and the final-notice deadline is 7 days after it. Default today | |
| stage | No | Render a specific stage instead of the one currently due, to preview or to re-issue a letter already sent | |
| format | No | markdown (default) or html: a self-contained printable page with no external anything | |
| invoice | Yes | The chased invoice: its id (DUN-2026-0001) or its invoice reference |
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.
Record that a chase letter was actually sent, with its date, so the ladder advances to the next stage. Letters go out in order: reminder 2 cannot be recorded before reminder 1. Returns what is due next and when.
| Name | Required | Description | Default |
|---|---|---|---|
| sent | No | The date it was sent, YYYY-MM-DD. Default today | |
| stage | No | Which letter went out. Default the lowest unsent stage | |
| invoice | Yes | The chased invoice: its id (DUN-2026-0001) or its invoice reference |
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.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that data under the token stays and that a wrong or expired key changes nothing, which is valuable non-destructive and failure-mode context for an activation 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 tight sentences front-load the action and key requirement, then add side-effect guarantees and a pointer to verification. No wasted words or repetition beyond the schema format.
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 activation tool with no output schema and no annotations, the description covers the action, key eligibility, non-destructive behavior, failure mode, and how to confirm success. It could add explicit return-value expectations, but license_status confirms it largely covers that 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 schema already fully documents the key parameter, so the baseline is 3. The description adds meaningful semantics by explaining the key must be issued at checkout for this server or bundle and that invalid keys are no-ops, going beyond the schema's simple format 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 uses a specific action, 'Turn Pro on for this connection,' with a clear resource (license/Pro status) and key format. It also distinguishes itself from the sibling license_status by focusing on activation rather than checking status.
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 conveys when to use the tool: when activating Pro with a checkout-issued key for this server or bundle. It also references license_status as the follow-up confirmation step, though it stops short of explicitly saying 'use license_status instead to check current status.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states 'No arguments, nothing changes,' indicating a read-only, side-effect-free operation. It does not detail error handling or authentication requirements, which are minor omissions for a simple status check, but the core behavioral trait (no mutation) is clearly communicated.
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, tightly packed with all essential information. It is front-loaded with the primary action and output, then adds the use case and side-effect note. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no input parameters and no output schema, the description fully covers what an agent needs: the return format (JSON with product, tier, reason, checkout URL), the trigger condition, and the lack of side effects. Nothing essential 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 tool has zero parameters, and the description confirms 'No arguments.' Per the scoring rules, 0 parameters earns a baseline of 4. The description adds no parameter-specific meaning because none exist, and it correctly reiterates the absence of arguments, aligning with the empty 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 states a specific verb and resource: 'Report this endpoint's licence state for your token as JSON'. It explicitly enumerates the returned fields (product, tier, reason, checkout URL), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like license_activate by focusing on status reporting rather than activation.
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 a clear trigger for use: 'Call it to explain a free-tier refusal.' This tells the agent when to invoke this tool. It does not explicitly discuss alternatives or exclusions, but the purpose is distinct enough from siblings that the guidance is adequate; it could be improved by noting it is the only read-only license info tool, though that is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every unpaid invoice past its due date: how many days late, what is still owed, which letters have gone out, and what is due next and when. Sorted by days late, worst first.
| Name | Required | Description | Default |
|---|---|---|---|
| on | No | The date to judge lateness against, YYYY-MM-DD. Default today | |
| limit | No | Maximum rows, default and ceiling 2000 |
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.
Record money received against a chased invoice, in whole MINOR units: a part payment lowers what is still chased, a payment that covers the balance closes the ladder and frees the free-tier slot. Returns the outstanding amount.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The date the money arrived, YYYY-MM-DD. Default today | |
| note | No | How it was paid, e.g. Bank transfer, or what it was against | |
| invoice | Yes | The chased invoice: its id (DUN-2026-0001) or its invoice reference | |
| amount_minor | Yes | What was received, in whole minor units |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aging_summarychase_todayinvoice_deleteinvoice_registerinvoice_statusletter_renderletter_sentlicense_activatelicense_statusoverdue_listpayment_recordStatements of account, aging buckets and dunning letters from your invoices.
AI invoice follow-up emails for freelancers. Draft-only, never sends for you.
Free demand-letter PDF generator for unpaid invoices, 80+ jurisdictions, 29 languages.
Chilean DTE/SII invoicing — issue invoices, reconcile payments and manage clients with AI agents.
