Chase overdue invoices: reminder 1, reminder 2, final notice, escalation dates, aging.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 11 tools
Most tools have a clearly distinct purpose: invoice_register, invoice_status, payment_record, letter_render, and letter_sent form an obvious workflow. The three list-oriented tools (aging_summary, overdue_list, chase_today) overlap somewhat in showing unpaid invoices, but their descriptions make the different perspectives clear enough to choose correctly.
The set consistently uses two-word snake_case names, with most following a noun_verb or noun_adjective pattern (invoice_register, letter_sent, payment_record). A few names like aging_summary, overdue_list, and chase_today deviate from that pattern but are still readable and predictable.
Eleven tools is well within the ideal range and each tool earns its place in the server's scope. Registration, status, payment, letter handling, list views, and license management are all represented without obvious redundancy or bloat.
The dunning lifecycle is fully covered: register invoices, track status, record payments, render and log letters, delete erroneous entries, and view aging/overdue/today lists. The server explicitly states that sending letters is the caller's responsibility, so the absence of an email tool is a documented boundary rather than a gap.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail: it covers only unpaid invoices, uses specific aging buckets, and returns totals in integer cents per currency.
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 carry complete, front-loaded information: the first lists the buckets and output units, the second frames the exact user question. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately conveys the return shape (counts, totals, cents, currency grouping) and scope. It could mention zero-result behavior or date semantics, but the schema already explains the date parameter and the tool is simple enough that nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional parameter 'on' is fully documented with format and default. The description does not need to repeat parameter details, so the baseline of 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 clearly defines the resource (every unpaid invoice) and the exact output (aging buckets, counts, totals in integer cents per currency). It answers a specific business question, which distinguishes it from sibling tools like overdue_list without needing to name them.
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 use case: 'This is the answer to how much am I owed, and how stale is it.' It does not explicitly state when not to use it or name alternatives, but the intended context is unambiguous.
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 readOnlyHint, idempotentHint, and destructiveHint all false, the annotations provide no safety profile, so the description carries the burden of explaining side effects. It describes output categories but never explicitly states whether calling the tool mutates anything or only reports; it does add useful context by noting that fully-lettered invoices need a decision 'outside this server.'
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 one structured sentence with a front-loaded subject and a colon-delimited list of distinct output categories. Every clause carries information about the report's scope, and there is no filler or redundant repetition of the title.
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 that there is no output schema, the description does a good job enumerating the main return categories: escalated invoices, recommended letters, wait times, due-soon items, and invoices requiring external decisions. It omits exact threshold values, letter mappings, and empty-result behavior, but for a two-parameter report tool this is reasonably 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?
The input schema already covers both parameters with 100% description coverage, giving a baseline of 3. The phrase 'what falls due in the next few days' loosely echoes within_days, but the description adds no parameter-level detail, formatting, or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'The day's chase list' is vague on its own, but the colon-delimited enumeration names concrete resources: invoices crossing an escalation threshold, the letter to send and wait time, upcoming due dates, and fully-lettered invoices needing an external decision. This clearly distinguishes it from siblings like overdue_list and aging_summary in substance, even though no sibling is named.
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 phrase 'The day's chase list' implies a daily operational use case, and the description indirectly contrasts with sibling tools by describing a combined report. However, there is no explicit 'use when' guidance, no mention of when not to use it, and no named alternative such as overdue_list for the due-soon portion.
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?
Annotations already mark destructiveHint=true, and the description adds meaningful behavioral detail: it cascades to payments and letter history, and the invoice id is never reissued, leaving a permanent gap in the DUN series. This goes well beyond the annotation.
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 core action and scope, then add the important consequence about id non-reissuance. No wasted words.
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, the description covers what is deleted, how to identify the target, and the long-term numbering consequence. No output schema is needed for a delete operation, so the definition 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?
The input schema already fully documents the single 'invoice' parameter with a format example and max length. The description restates 'by id or reference' but does not add new semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Delete'), the resource ('an invoice from the register'), and the identification methods ('by id or reference'). It also distinguishes itself from sibling read/report tools by clearly describing a destructive action with scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'entered wrongly' provides clear context for when deletion is appropriate, and the destructive scope is obvious. However, it does not explicitly name alternatives or state when not to use this tool, though the qualifier gives adequate usage direction.
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?
Annotations are all negative hints, so the description carries the disclosure burden. It does reveal the registration action, the free-tier limit of 3 unpaid invoices, and the output schedule, adding value beyond the annotations. However, it does not mention duplicate handling, what happens if the same invoice is already registered, or whether the action can be undone, which are meaningful gaps for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads the action, required inputs, and output; the second states the limitation. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers required inputs, the high-level return value, and a relevant constraint (free tier), enough for an agent to make a correct basic call. It omits optional parameters and duplicate_ok behavior, but these are already explained in the schema. The absence of an output schema means a more precise return-structure note would help, though the current description is largely adequate.
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 most parameters are already documented with detailed descriptions. The description re-iterates 'amount in integer cents' but adds no new parameter-level meaning beyond what the schema provides, so the baseline of 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 uses a specific verb ('register') and clearly identifies the resource ('an unpaid invoice') and the return value (the three-letter escalation schedule with dates). It is inherently distinguishable from sibling tools like invoice_delete and invoice_status because it initiates a chase rather than deleting or querying a 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?
The description gives a clear trigger context: 'Start chasing an unpaid invoice.' It does not explicitly name sibling alternatives or state when not to use the tool, so the guidance is useful but not exhaustive.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about what the tool returns (letters, escalation stages, next steps) but doesn't disclose details like whether the 'on' date affects the escalation state or whether the response includes computed fields. With annotations covering the key behavioral traits, a 3 is appropriate.
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, well-structured sentence that front-loads the core purpose ('One chased invoice in full') and then lists the key contents in a natural flow. No wasted words, and it earns its length by enumerating the distinct data categories.
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, idempotent lookup tool with 100% schema coverage and no output schema, the description covers the main things an agent needs: what the tool does and what data it returns. It doesn't explain the escalation schedule format or how 'on' interacts with the data, but those are minor gaps given the annotations and schema already carry the safety and parameter details.
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 ('on' and 'invoice') are already documented in the schema. The description doesn't add extra meaning beyond what the schema provides, but it does reinforce that the tool is about a single invoice's full state. Baseline 3 is correct.
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 verb ('chased invoice in full') and enumerates the exact resource contents: billed, paid, owed, letters sent, escalation schedule, and next steps. It clearly distinguishes itself from siblings like aging_summary or overdue_list by focusing on a single invoice's full state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use when you need the complete state of one chased invoice, including escalation and next actions. It doesn't explicitly name alternatives or exclusions, but the scope is clear enough that an agent can infer when to use it versus a list-level tool like overdue_list or aging_summary.
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?
Annotations are weak (all hints false), so the description carries the burden and delivers the key trait: no email/send side effects, with sending delegated to the agent and ladder advancement delegated to letter_sent. It also implies preview/re-issue behavior via the stage override. It does not cover error handling or authentication, but the core side-effect disclosure is present and does not contradict the annotations.
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 with the action front-loaded, each earning its place: purpose/stages/formats, the no-send behavioral disclaimer, and the letter_sent handoff. No filler and no repetition of what the schema already documents.
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 4-parameter render tool with no output schema, the description plus a fully described 100%-coverage schema gives the agent everything needed to call it correctly: invoice id format, stage semantics, date default with late-fee/deadline behavior, and format options. The return value is only loosely specified as 'the letter text,' and error behavior for edge cases (e.g., already-paid invoices) is unstated — minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by mapping the stage enum to polite reminder, firm reminder with late-fee note, and final notice. It also reinforces the format enum as Markdown or self-contained printable HTML.
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 ('generate'), resource (the chase letter for an unpaid invoice), and the scope of the ladder's three stages ('reminder 1... reminder 2... final notice'). It explicitly distinguishes itself from the sibling letter_sent by assigning that tool the recording role, so an agent can tell them apart without opening schemas.
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?
Defines the full workflow: render here, send yourself, then record with letter_sent so the ladder advances. It names the sibling tool and the condition under which it follows, and it explicitly warns that nothing is emailed or sent by this tool — an important when-not expectation that prevents the agent from assuming the act of sending is handled.
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?
Beyond the annotations, the description discloses that recording the letter advances the internal ladder and that the response returns what is due next and when. This describes the state-changing and sequencing behavior more concretely than the annotation flags alone. It does not elaborate on error behavior or idempotency, but the key side effect and return contract are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The core purpose is front-loaded, the ordering constraint is stated in a single conditional sentence, and the response behavior is included in a short final sentence.
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 three-parameter tool with no output schema, the description covers the state transition, the ordering rule, and the response value. It could also explain what happens if the ordering rule is violated, but the overall contract is clear enough for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents sent, stage, and invoice. The description adds the contextual meaning that 'stage' corresponds to ladder progression and that 'sent' is the date, but it does not introduce format or boundary details beyond the schema. This matches the baseline expected when the schema is fully descriptive.
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 and resource: recording that a chase letter was actually sent, including its date but ignoring screen renders. It also explicitly separates this from rendering by framing it as the ladder-progression event, so an agent can distinguish it from letter_render.
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 for when this tool should be used: when a letter physically goes out alerting the next chase stage. It also surfaces an ordering constraint—reminder 2 cannot be recorded before reminder 1—which is essential usage guidance. It does not explicitly name alternatives, but the sibling set and wording make the workflow position evident.
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?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the 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?
The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential 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 single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information 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 and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in 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 uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.
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 provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the 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?
Two dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.
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 sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.
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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.
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 explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.
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?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: returned attributes (days late, owed amount, letters sent, next due action) and the ordering by days late descending. It does not mention limit truncation, but that constraint is available in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the core scope and then enumerates the output fields and ordering. Every clause earns its place, with no filler or redundant restatement of the title.
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 two optional, well-documented parameters and no output schema, the description sufficiently explains the return content and ordering. The only minor gap is that 'Every' is technically qualified by the `limit` ceiling, but the schema supplies that constraint.
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%, with both `on` and `limit` already documented including format, defaults, and bounds. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource—unpaid invoices past their due date—and specifies the returned fields plus sort order, so the function is unambiguous. It does not explicitly distinguish itself from sibling tools like aging_summary or chase_today, but the overdue scope and 'worst first' ordering are distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the trigger for use ('unpaid invoice past its due date') and the scope ('Every'), but it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. The agent must infer how this differs from related invoice tools.
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?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds valuable context beyond that: partial payments lower the chased amount, full payments close the ladder and free the free-tier slot, and it returns the outstanding amount. This goes beyond the annotations and helps the agent understand 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?
The description is two sentences with no filler. It front-loads the action, then explains the two possible effects and the return value. Every phrase earns its place, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, the effects on the invoice ladder, and the return value. It does not need to explain parameters because the schema handles that. It could mention prerequisites or error cases, but for a straightforward payment-recording tool, this is sufficiently 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 100%, so the schema already documents all parameters clearly. The description reinforces that amount_minor is in 'whole MINOR units', which matches the schema, but it does not add new semantic meaning that isn't already present. Baseline 3 is appropriate when the schema carries the parameter documentation.
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 ('Record money received') and a specific resource ('against a chased invoice'), clearly distinguishing it from sibling tools like invoice_status (querying) and overdue_list (listing). It also explains the two possible outcomes (partial vs. full payment), making the tool's intent unambiguous.
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: it is used for payments against a chased invoice. It does not explicitly mention when not to use it or name alternative tools, but the context is sufficient for an agent to infer the appropriate scenario. No exclusions are given, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aging_summarychase_todayinvoice_deleteinvoice_registerinvoice_statusletter_renderletter_sentlicense_activatelicense_statusoverdue_listpayment_recordWrite payment chasers at three levels from the invoices that are actually overdue.
Statements 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.
Add one secure layer between your agents and this server.