Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-statement-of-account Build a statement of account for Acme Corp for last month as a PDF."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
One-click install: download statement-of-account.mcpb from the latest release and double-click it in Claude Desktop.
Hosted endpoint (no install): https://mcp.zovo.one/mcp/statement-of-account (streamable-http; send Authorization: Bearer <Pro key or anonymous token from https://mcp.zovo.one/mcp/token>).
Read-only mirror of mcp-servers/servers/statement-of-account. See MIRROR.md.
Send a client the one document that answers "what do I actually owe you". This MCP server reads the books you already keep in this suite -- your invoices, your credit notes and your deposits -- and turns them into a statement of account for a period: the balance you were carrying at the start, every invoice you issued, every payment that came in, every credit note you gave, and the balance at the end. It ages what is still open into 0-30, 31-60, 61-90 and over 90 days past due, so you can see at a glance which client is the problem; it writes the statement as pasteable text or as an A4 PDF that looks like your invoices; and it drafts the chaser, at a friendly, a firm or a final level. It never writes anything back into your invoices, and it never invents a late fee.
Built by theluckystrike.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or
%APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"statement-of-account": {
"command": "npx",
"args": ["-y", "@theluckystrike/mcp-statement-of-account"]
}
}
}claude mcp add statement-of-account -- npx -y @theluckystrike/mcp-statement-of-account~/.cursor/mcp.json (global) or .cursor/mcp.json (project), same entry as Claude Desktop.
Related MCP server: Xero MCP Server
tool | what it does |
| One client's statement for a period: opening balance, invoices issued, payments received, credit notes, deposits applied, closing balance. Every figure in minor units and formatted |
| What is owed, split into 0-30, 31-60, 61-90 and over 90 days past the due date as at a chosen date, for one client or for everyone, per currency |
| The same statement as plain text, movements in date order, ready to paste into an email |
| The same statement as an A4 PDF titled STATEMENT OF ACCOUNT, on the same page layout as your invoices and credit notes |
| A payment chaser at level 1 (friendly), 2 (firm) or 3 (final demand), with the overdue list and your bank details |
| Every client at once: what is outstanding per currency, aged, and the oldest overdue invoice in the book |
| Free or Pro, and where to upgrade |
| Activate a Pro key |
Plus the statement://sources resource, which says which of the three stores this server
could read and how many rows each holds, and the chase_overdue prompt.
Free | Pro | |
Statements built | 5 a calendar month | unlimited |
Rebuilding a statement already built | unlimited | unlimited |
| unlimited | unlimited |
| yes | yes |
| yes | yes |
| no | yes |
| no | yes |
| no | yes |
PDF footer credit | shown | removed |
Aging is free and unlimited on purpose. "Who owes me money" is the question this whole server exists for, and a free tier that hides it is a demo rather than a tool. The meter is on the statement, the document that actually goes to a client, and it counts distinct statements: the same client, period and currency built again is free forever.
Get Pro -- one-time, lifetime, for this server. Keys verify offline.
Nothing here is typed in twice. The server reads three stores and writes to none of them:
store | server | what is taken from it |
|
| the invoices, their due dates and how much of each is paid |
|
| the credit notes, already stored with a negative sign |
|
| the deposit applications, and what is still held |
A store you have never installed is simply absent, and the statement is built without it. A store that is on disk and cannot be READ is a different thing entirely, and is reported as such on every figure, because a balance that could not be computed must never be shown as a balance of nothing owed. The one store the server refuses to work without is the invoice ledger.
Aging a past date with today's payment figures is not slightly wrong, it is silently
empty. Aging is usually written as "take each invoice, subtract what has been paid, and
bucket by the due date". The subtraction is the part nobody dates. On the worked month in
test/_client.mjs, aged at 2026-06-10, the two rules give:
rule | outstanding | overdue |
as at 2026-06-10 | 2,500.00 EUR | 500.00 EUR, 31 days late |
today's | 1,700.00 EUR | 0.00 EUR |
The naive rule understates what was owed by 800.00 of 2,500.00, a third of the balance,
and it reports NOTHING overdue on a date when an invoice was a month late, because a
payment that arrived two days later has already been subtracted from it. The failure is
invisible: the answer looks tidy, the buckets add up, and it cannot be reproduced next
month because the input keeps moving. So every figure in statement_aging is taken as at
the date asked for, in both directions: an invoice issued after it is not on the books, a
payment made after it has not happened, and a credit note issued after it has not been
given.
The second thing measurement showed: paid_minor and payments[] on an invoice do not
have to agree, and routinely do not. invoice_mark_paid writes both, but deposit_apply
raises paid_minor and appends no payment row at all, and an invoice created before that
field existed has no rows either. Reconstructing receipts from payments[] would have
lost 300.00 of the worked month's 900.00 of receipts, a third of the cash, with no error
anywhere. paid_minor is treated as the authority and the rows are only the attribution.
A deposit is money that moves once. Applying a deposit already writes the payment on the invoice, so the statement counts it there and breaks it out as "of which deposits applied" rather than crediting it a second time. Deposit money still held is a memo line and is never part of the balance: it is the client's money until it is applied.
Currencies are never added together. One statement is one currency, and a client billed in two is asked which. There is no exchange rate in this server, so a single figure across a EUR ledger and a USD one would be one it made up.
Due today is not overdue. An invoice enters the 0-30 bucket on the first day past its due date. What is outstanding but not yet due is reported beside the buckets, never inside them and never hidden.
A credit note reduces the invoice it names and no other. An open balance floors at zero and any excess is reported as unapplied credit, rather than quietly cancelling an invoice the client never agreed it against.
No chaser invents a charge. The three dunning levels differ in tone and deadline and in nothing else. No level states a late fee, an interest rate or a legal cost, because this server holds no contract terms, no statutory rate and no jurisdiction, and the one place never to put a made-up number is a demand for money.
A chaser for a client with nothing overdue is refused, and the refusal says what is outstanding but not yet due.
All data stays on your machine. The invoices, credit notes and deposits are read from
${XDG_DATA_HOME:-~/.local/share}/mcp-servers/, this server's own register of built
statements is written to .../mcp-servers/statement-of-account/, and nothing is sent
anywhere. There is no network call in this server at all. License keys verify offline.
MIT. Support: support@zovo.one
Built by theluckystrike.
Write a payment chaser for one client at level 1 friendly, 2 firm or 3 final demand, listing every overdue invoice with its age and total, plus your bank details when the profile has them. 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?
With no annotations, the description carries the transparency burden. It usefully discloses that the letter lists every overdue invoice with age and total, conditionally includes bank details, and treats level 3 as Pro. However, it does not state whether the tool only returns text or performs any send/update side effects, so some behavioral uncertainty remains.
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 pack the purpose, levels, invoice detail behavior, and bank-details condition without padding. The repeated 'Level 3 is Pro' note is redundant with the schema, keeping it from a perfect conciseness score.
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 text-generation tool with full schema coverage of all six parameters, the description is largely complete: it states the output's content and the conditional bank-details behavior. It lacks an explicit statement of the return format and behavior when there are no overdue invoices, but those are minor given the unambiguous 'Write a payment chaser' phrasing.
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 in detail. The description reinforces level meaning and client scope but does not add meaningful parameter-level semantics beyond the schema, matching the baseline for high coverage.
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 leads with a specific verb and object ('Write a payment chaser for one client') and goes on to define the three escalation levels and the content of the letter. This makes the tool's function unmistakable and, together with the dunning-specific wording, separates it from statement/PDF siblings.
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 situates the tool for producing a dunning letter for a single client and describes the level selection. It does not name sibling tools or give explicit when-not-to-use guidance, so it misses the top score but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate a Pro license key (format MCPL1.xxx.yyy). Verified offline and saved locally.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from the checkout confirmation page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It usefully discloses that verification is offline and the license is saved locally, which are meaningful traits. However, it does not disclose what happens on invalid keys, whether activation overwrites an existing license, or what the call returns on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that front-loads the primary action and object, then adds format and behavior, with zero 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?
The tool is simple, and the description covers the core action, key format, and behavioral facts. But with no output schema, it omits what the agent should expect in response and how to handle an invalid or already-activated key, leaving some operational ambiguity.
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 describes the single 'key' parameter, so baseline is 3. The description adds the expected key format (MCPL1.xxx.yyy), giving the agent actionable validation guidance beyond the schema's source-of-key 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 clearly states the action ('Activate'), the resource ('a Pro license key'), and the required key format. It is distinct from sibling tools because activation is a specific operation not mentioned elsewhere, though it does not explicitly differentiate itself from license_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 implies when to use it: when the user has a Pro license key from checkout. However, it provides no exclusions or mention of alternatives like license_status for checking current license state, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show whether this server runs in free or Pro mode and where to upgrade.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a non-mutating informational operation ('Show whether...'), which implies no side effects. It does not discuss caching or permission requirements, but for a simple status query this is adequate.
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, well-structured sentence that immediately states what the tool does and the location of upgrade guidance. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description fully covers what the agent can learn and the follow-up action (upgrade location). The absence of an output schema is acceptable here because the expected result is straightforward mode information plus an upgrade pointer.
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, so there is no parameter semantic burden. The description adds no parameter information because none is needed; the baseline of 4 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 ('Show') and identifies the exact resource (server license mode) and the actionable outcome (where to upgrade). It clearly distinguishes this read-only status check from the sibling license_activate tool.
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 makes the use case evident: check whether the server is free or Pro and find the upgrade path. It does not explicitly mention exclusions or alternatives, but the contrast with license_activate is implicit and sufficient for a simple status tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Break what is owed into 0-30, 31-60, 61-90 and over 90 days past the invoice due date as at a chosen date, for one client or for every client, per currency. Free and unlimited.
| 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?
No annotations are present, so the description carries the full burden. It covers what the tool does but omits important behavioral details such as output format, how limits apply, whether results are grouped, and potential side effects. The phrase 'Free and unlimited' is potentially misleading given the schema's 2000-row maximum.
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, dense sentence that front-loads the core behavior and filtering options. The 'Free and unlimited' clause is slightly extraneous but not harmful.
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 annotations and no output schema, the description is the only guide to expected results. It explains the aging logic but does not describe the result structure, how rows are grouped, ordering, or the default limit behavior, leaving important gaps for the agent.
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 provides 100% coverage for all four parameters with clear descriptions, so the baseline is 3. The description reinforces the meaning of as_of, client, and currency but adds no new semantic detail 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 clearly states the tool's function: breaking owed amounts into aging buckets (0-30, 31-60, 61-90, over 90 days) by due date, with options for client and currency. It is specific and distinct from sibling tools, though it does not explicitly contrast itself with 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 use case is clearly implied: use when you need an aging breakdown of open invoices as of a date. However, there is no explicit guidance on when not to use it or how it differs from related statements tools.
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 of account for a period: opening balance, invoices issued, payments received, credit notes, deposits applied and closing balance, in minor units and formatted.
| 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?
With no annotations, the description carries the full burden. It reveals that output is in minor units and formatted and lists statement contents, but it does not disclose the return format, whether the operation is read-only or has side effects, authentication needs, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler: the verb, scope, period, and contents are all conveyed efficiently. Every phrase 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?
No output schema and no annotations mean the description must cover behavior and return value, but it only hints at formatting with 'minor units and formatted.' The relationship to statement_text/statement_pdf and the exact output structure are missing, so an agent cannot fully anticipate the tool's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already explains from, to, client, and currency. The description adds no parameter-specific meaning beyond implying the period and client are used.
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 ('Build') and identifies the resource as one client's statement of account for a period, enumerating the included components (opening balance, invoices, payments, credit notes, deposits, closing balance). It is clear and not tautological, but it does not explicitly differentiate from sibling tools such as statement_text or statement_pdf.
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 guidance is given on when to choose this tool over the sibling statement tools. The description simply states what it does, leaving the agent to infer selection criteria from the tool name and sibling names.
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 write one client's A4 statement of account and return the file path. Titled STATEMENT OF ACCOUNT, every movement in date order, closing with the balance outstanding. 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 | Where to write the PDF; defaults to this server's data directory under pdf/. Use a .pdf path: the bytes written are always PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it does a solid job: it states the output is a PDF file path, describes the A4 format, the statement title, the date ordering of movements, and the closing balance. It omits edge-case behaviors like overwrite policy or empty-statement handling, but the core side effect (writing a file) is clearly disclosed.
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 short and front-loaded, with the main action in the first clause and output characteristics compactly listed. The trailing 'Pro.' appears to be a stray or unexplained fragment that adds noise, preventing a perfect score.
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 and no output schema, the description covers the essential context: what the PDF contains, how it is formatted, and what the tool returns. The rich schema covers parameter details, so the description is adequate; only minor gaps such as overwrite behavior and error cases remain.
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 is 3. The description adds a little semantic color ('one client's' for client, 'return the file path' for out_path) but does not meaningfully explain parameter formats or constraints beyond what the schema already documents.
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 resource ('one client's statement of account'), and a clear deliverable ('return the file path'). It is distinct from sibling text/aging tools by explicitly framing this as a PDF-rendering operation, though it does not name any sibling it is not.
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 opening sentence ('Call this tool to write one client's A4 statement...') gives a clear, direct usage context and scopes the tool to a single client and PDF output. It does not, however, provide explicit when-not-to-use guidance or name alternatives such as 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.
Show what is outstanding across every client, totalled per currency and aged, with the oldest overdue invoice and the clients carrying it. Pro.
| 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?
With no annotations provided, the description carries the behavioral burden. It does disclose the computed contents (per-currency totals, aging, oldest overdue invoice) and the verb 'Show' implies a read-only operation. However, it does not explicitly state that it is non-mutating, whether a Pro license is required despite the cryptic 'Pro.' suffix, or any additional access or output constraints.
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 sentence that front-loads the core purpose before adding detail, making it quick to parse. The trailing 'Pro.' is cryptic and adds little clarity, which prevents a perfect score, but the overall structure is efficient and waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must carry more weight. It explains what the report contains but leaves gaps around return format, how aging buckets are defined, currency handling details, and the meaning of 'Pro.' The tool is simple enough to be usable, but not fully specified.
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 input schema already fully documents as_of and limit. The tool description adds no parameter-specific meaning beyond the general implication that aging depends on the as_of date, which is already covered by the schema's own 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 names a specific verb ('Show'), a clear resource ('what is outstanding across every client'), and detailed output characteristics: totalled per currency, aged, oldest overdue invoice, and the clients carrying it. This scope clearly separates it from the sibling statement_build/statement_text/statement_pdf tools, which appear to be per-client or format-specific operations.
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 usage context is implied rather than explicit: 'across every client' signals this is an aggregate report, and the title 'What every client owes' reinforces that. However, there is no direct statement of when to choose this over statement_aging or other siblings, and no exclusions or alternatives are mentioned.
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 ledger with every movement in date order, the opening and closing balances and a sign-off, ready to paste into an email.
| 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?
With no annotations, the description carries the full burden of explaining behavior. It discloses the output composition (every movement, opening/closing balances, sign-off) and the format (plain text). It does not mention edge cases or side effects, but this is a read/generate operation with no mutation risk, so the transparency is adequate.
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, efficient sentence with no filler. The core action is front-loaded, and each clause adds necessary detail about scope, ordering, balances, and intended use.
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, scope, output content, and format despite the absence of an output schema and annotations. It could be more complete by specifying behavior for empty results or multiple currencies, but the schema fills in parameter details and the description gives enough context for an agent 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?
The input schema already documents all seven parameters with 100% coverage, so the baseline is 3. The description adds light context by mentioning 'one client's statement' and 'sign-off', but it does not provide syntax or additional meaning beyond what the schema already gives.
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 a clear verb ('Turn'), a precise resource ('one client's statement'), and a concrete output ('plain-text ledger' with movements in date order, balances, and sign-off). The emphasis on 'plain-text' and 'one client' implicitly distinguishes this tool from siblings like statement_pdf and statements_report, making its purpose 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 phrase 'ready to paste into an email' provides a clear and practical use context, indicating this tool is for generating a text version of a statement for email communication. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the context is clear.
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. Dates show when Glama detected each change.
v0.14.0dunning_textlicense_activatelicense_statusstatement_agingstatement_buildstatement_pdfstatement_textstatements_reportMost tools have clear boundaries: statement_build produces structured data, statement_text and statement_pdf are distinct output formats, and dunning_text is clearly a payment chaser. The main potential confusion is between statement_aging and statements_report, since both cover aged receivables, but their scope and output level differ.
The names consistently use snake_case and are grouped by domain prefix such as statement_ and license_, which makes them predictable. The main deviation is that suffixes mix verbs, gerunds, and nouns instead of following a strict verb_noun pattern, but this is readable and minor.
Eight tools is well-scoped for a statement-of-account server: statement generation, formatting outputs, aging, dunning, an aggregate report, and license management each have a purpose. There is no bloat and no sense of a thin or incomplete toolset.
The server covers the core statement workflow well: build a statement, render it as text or PDF, age outstanding balances, generate dunning text, and view an all-client summary. Minor gaps exist, such as no batch statement generation or explicit client listing, but they do not create obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Statements of account, aging buckets and dunning letters from your invoices.
Security and retainer deposits per client: hold, apply to an invoice, refund, statement.
Chilean DTE/SII invoicing — issue invoices, reconcile payments and manage clients with AI agents.
Sits between accounting and payment rails for reminders, Pay Now, autopay, portal, and book sync.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/theluckystrike/mcp-statement-of-account'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
