Write payment chasers at three levels from the invoices that are actually overdue.
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 8 tools
The set cleanly separates payment chasers, statement rendering, aging views, and license management. The only mild ambiguity is between statement_aging and statements_report or between dunning_text and statement_text, but the descriptions explicitly cross-reference and distinguish these pairs.
Most tools follow a clear {domain}_{object/action} underscore pattern, like statement_build, statement_pdf, and license_status. Minor inconsistencies exist: statements_report is plural while related statement_ tools are singular, and license_activate is verb-like while license_status is noun-like.
Eight tools is well-scoped for a server covering dunning letters, statement generation, receivables reporting, and licensing. Each tool has a distinct role, and none feel redundant or filler.
Core workflows are covered: build, text, and PDF statements; age receivables; roll up reports; issue dunning letters; and manage Pro licensing. Minor gaps like sending dunning directly via email or posting payments exist, but they fall outside the server's apparent purpose.
Write a payment chaser at level 1 friendly, 2 firm or 3 final demand: every OVERDUE invoice with its age, the total and your bank details. Refused if nothing is overdue. No interest is stated. The letter is also a .txt download link valid one hour. Level 3 is Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Age the invoices as at this date, YYYY-MM-DD. Defaults to today | |
| level | Yes | 1 friendly reminder, 2 firm reminder, 3 final demand. Level 3 is Pro | |
| client | Yes | Client id from the invoice server, an exact client name, or a name containing this text | |
| currency | No | Only needed when the client has documents in more than one currency. Currencies are never added together | |
| greeting | No | Opening line, default "Hello" and the client name | |
| sign_off | No | Closing line, default your business name from the shared profile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable behavior beyond that: refusal when nothing is overdue, no interest stated, a one-hour .txt download link, and the Pro requirement for level 3. There is no contradiction with the readOnlyHint since this produces generated content rather than mutating persistent state.
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 compact and front-loaded with the core purpose every-OVERDUE-invoice and level options. Every sentence adds useful information: refusal condition, content scope, link expiry, and Pro gating. No 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 tool with six parameters, full schema coverage, and no output schema, this description covers the key runtime behaviors an agent needs: output is a downloadable .txt link, it fails if nothing is overdue, content includes invoices and totals, and level 3 has a license requirement. The remaining gaps are covered by the input 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 the schema already documents all six parameters. The description reinforces the level meanings and adds the Pro constraint, but it does not substantially enrich parameter semantics beyond 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 states a specific verb ('Write a payment chaser') and resource ('dunning letter') with clear level semantics. It distinguishes itself from sibling statement tools by focusing on overdue invoices and payment chasing.
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 clearly indicates when the tool applies: whenever overdue invoices exist, with level selection. It also gives an explicit exclusion ('Refused if nothing is overdue'), although it does not name sibling tools as alternatives.
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.
Age open invoices into 0-30, 31-60, 61-90 and over 90 days past DUE date at a date, per client and currency, with the invoices themselves. Free. statements_report rolls up the whole book instead.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Age the invoices as at this date, YYYY-MM-DD. Defaults to today | |
| limit | No | Maximum invoice rows returned, default and ceiling 2000 | |
| client | No | One client id or name. Omit to age every client in the books | |
| currency | No | Only this currency. Omit for every currency, each aged separately |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no real safety profile (all hints false/absent), so the description carries the burden. It adds useful facts: buckets are based on DUE date, invoices themselves are returned, and the tool is free. However, it does not state whether this is a pure read/report operation, whether any state changes occur, or any auth/rate-limit implications.
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 efficiently written sentences front-load the core aging logic and output, then close with a clear sibling distinction. 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 list/report tool with no output schema, the description conveys the essential return content ('the invoices themselves'), the aging bucket boundaries, and the main alternative. It could be more complete about output structure, ordering, or limit behavior, but the key calling context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents as_of, limit, client, and currency. The description reinforces the client/currency/date dimensions but adds no meaning the schema does not already provide.
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 specifies the operation ('Age open invoices'), defines the output (buckets by days past due, per client/currency, with invoices themselves), and names the distinguishing sibling (statements_report), making the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts itself with statements_report, telling the agent to use the sibling when the whole book is needed in rolled-up form. It also mentions the per-client/currency granularity, but it doesn't address other siblings like statement_build or statement_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build one client's statement for a period: opening, invoices, payments with deposits applied broken out, credit notes and closing, formatted and in minor units. Free: 5 a month; a rebuild is free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Last day of the period, YYYY-MM-DD, inclusive | |
| from | Yes | First day of the period, YYYY-MM-DD. Everything dated before it becomes the opening balance | |
| client | Yes | Client id from the invoice server, an exact client name, or a name containing this text | |
| currency | No | Only needed when the client has documents in more than one currency. Currencies are never added together |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuine behavioral context beyond the annotations: a monthly quota of 5 with free rebuilds, and output amounts formatted in minor units. However, with all annotations false and uninformative, the description carries the burden and leaves key behaviors undisclosed: what the tool returns (no output schema exists), what a 'rebuild' is, and what happens at quota exhaustion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no waste. The first front-loads action, scope, and contents; the second adds quota behavior. Every clause earns its place, and there is no redundant restatement of schema fields.
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?
Adequate coverage of scope, contents, and cost constraints for a tool with only four flat parameters. But with no output schema and uninformative annotations, the silence on return value, rebuild semantics, and quota-exhaustion behavior leaves an agent uncertain about the call's outcome and cost. More disclosure was warranted.
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 carries the parameter documentation and the baseline is 3. The description's 'for a period' merely echoes the from/to parameters and adds no syntax, format, or client-matching details beyond what the schema already provides. No param-specific value is added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Build') and resource ('one client's statement for a period') and enumerates the statement's contents (opening, invoices, payments with deposits broken out, credit notes, closing). The 'one client's' scope and the component list implicitly differentiate it from siblings like statements_report and statement_aging. However, sibling differentiation is implicit rather than explicit, and 'build' is ambiguous between 'generate a document' and 'create a stored artifact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance relative to alternatives such as statement_pdf, statement_text, or statements_report. The quota note ('Free: 5 a month; a rebuild is free') signals cost-awareness but does not tell an agent which sibling to choose or what conditions should route away from this tool. The conditional behavior lives in the schema ('currency' description), not in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this tool to render one client's A4 statement of account and return a download link valid for one hour. Titled STATEMENT OF ACCOUNT, movements in date order, BALANCE OUTSTANDING at the foot. Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Last day of the period, YYYY-MM-DD, inclusive | |
| from | Yes | First day of the period, YYYY-MM-DD | |
| as_of | No | Date printed on the statement, YYYY-MM-DD. Defaults to today | |
| client | Yes | Client id from the invoice server, an exact client name, or a name containing this text | |
| currency | No | Only needed when the client has documents in more than one currency. Currencies are never added together | |
| out_path | No | Name for the downloaded file, e.g. acme-statement. Defaults to the client, currency and period; the statement comes back as a download link valid for one hour |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds genuinely useful behavior beyond them: the download link expires after one hour, and the output document's layout is specified (A4, titled STATEMENT OF ACCOUNT, chronological movements, BALANCE OUTSTANDING at foot). No contradiction with 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 purpose front-loaded and the output format summarized compactly. The trailing 'Pro.' is terse and slightly cryptic, and the layout details, while useful, could arguably be trimmed, but overall every sentence contributes and the description is efficiently sized.
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 render tool with fully documented parameters and no output schema, the description covers purpose, deliverable form, and link expiry sufficiently. It does not explain return-value structure or error cases, but these are not required given the tool's simplicity and the annotation coverage.
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 fully documents all six parameters; the description adds no per-parameter meaning beyond what the schema provides. Baseline 3 is appropriate since the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('render one client's A4 statement of account') and adds a concrete deliverable detail (download link valid for one hour). It partially distinguishes from siblings via 'one client's', which implies batch tools like statements_report are different, but it never explicitly names or contrasts with statement_build, so full sibling differentiation is missing.
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?
'Call this tool to render one client's A4 statement of account' gives clear, directly actionable context for when the tool applies. The phrase 'one client's' implies a boundary against multi-client alternatives, but there are no explicit when-not conditions or named alternative tools, so it falls short of full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Receivables across every client at a date: totals and aging per currency, clients ranked by how much is OVERDUE, and the oldest overdue invoice. Pro. statement_aging is the free per-client view.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Age the invoices as at this date, YYYY-MM-DD. Defaults to today | |
| limit | No | How many clients to list, worst first. Default 20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by describing the date-bound aggregate output and signaling a Pro requirement. It does not detail response structure or error behavior, but the annotation coverage lowers the burden for this read-only report.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core behavior and output highlights are front-loaded, and the Pro/alternative note is packed into a short second 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 read-only tool with two optional, fully described parameters and no output schema, the description enumerates the key returned information: totals, aging per currency, overdue ranking, and oldest overdue invoice. The sibling pointer and annotations complete the picture, and openWorldHint=false supports treating the description as sufficient.
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 already carry clear meaning in the input schema: as_of is the aging date, and limit controls how many clients to list worst-first. The description echoes this and adds no materially new parameter-level semantics, 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 states the tool reports receivables across every client at a date, including totals, aging per currency, overdue ranking, and the oldest overdue invoice. It also distinguishes itself from the per-client sibling, statement_aging, so an agent can identify the right scope 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?
It explicitly names the alternative: 'statement_aging is the free per-client view.' The 'Pro' flag and the contrast between 'every client' and 'per-client' give an agent clear conditions for choosing this tool over its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn one client's statement into a plain-text letter for an email: movements in date order, opening and closing balances, deposit held, a sign-off. It is also a .txt download link valid one hour and counts toward the 5 a month; statement_pdf writes the A4 page.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Last day of the period, YYYY-MM-DD, inclusive | |
| from | Yes | First day of the period, YYYY-MM-DD | |
| as_of | No | Date printed on the statement, YYYY-MM-DD. Defaults to today | |
| client | Yes | Client id from the invoice server, an exact client name, or a name containing this text | |
| currency | No | Only needed when the client has documents in more than one currency. Currencies are never added together | |
| greeting | No | Opening line, default "Hello" and the client name | |
| sign_off | No | Closing line, default your business name from the shared profile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior; the description adds substantial non-obvious traits: the .txt download link is valid for one hour, the operation counts toward a 5-per-month quota, and the output is a formatted letter rather than a raw list. No contradiction with 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?
Two efficiently structured sentences front-load the core purpose and output components, then pack the link validity, quota, and sibling alternative into a compact second sentence. No filler or repetition of schema fields.
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, the description explains what the returned artifact is (a .txt download link), its validity, quota impact, and content. Together with the fully documented input schema and safety annotations, this gives an agent enough to select and invoke the 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?
Schema description coverage is 100%, so the baseline of 3 applies; the schema already explains client, date range, currency, greeting, and sign_off. The description does not materially deepen parameter meaning beyond noting the output includes a sign-off, so no higher score is warranted.
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 opens with a specific verb+resource: 'Turn one client's statement into a plain-text letter for an email' and enumerates the delivered contents, including movements in date order, balances, deposit held, and a sign-off. It also explicitly contrasts with statement_pdf, making sibling differentiation immediate.
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 identifies a clear use context (email letter for one client) and names statement_pdf as the A4-page alternative. It does not explicitly rule out other sibling tools such as dunning_text or statements_report, but the plain-text/email framing gives sufficient direction.
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.
dunning_textlicense_activatelicense_statusstatement_agingstatement_buildstatement_pdfstatement_textstatements_reportChase overdue invoices: reminder 1, reminder 2, final notice, escalation dates, aging.
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.