mcp-statement-of-account

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.14.0
Disambiguation4/5
Most 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

mcp-statement-of-account MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![mcp-statement-of-account MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/theluckystrike/mcp-statement-of-account/badges/card.svg)](https://glama.ai/mcp/servers/theluckystrike/mcp-statement-of-account)

Score Badge

Copy to your README.md:

[![mcp-statement-of-account MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/theluckystrike/mcp-statement-of-account/badges/score.svg)](https://glama.ai/mcp/servers/theluckystrike/mcp-statement-of-account)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![mcp-statement-of-account MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Ftheluckystrike%2Fmcp-statement-of-account%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/theluckystrike/mcp-statement-of-account)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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