Reads and manages Stripe invoices for receivables collection: lists overdue open invoices with customer, amount owed, days late, and payment link, summarizes amounts owed by aging bucket (not yet due / 1–30 / 31–60 / 61–90 / over 90 days) per currency, reports a customer's recent invoices and typical late-payment behavior, and re-sends an overdue invoice email through Stripe when writes are explicitly enabled.
Click on "Deploy 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., "@stripe-collections-mcp Who owes me money right now?"
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.
Ask Claude who owes you money, and let it chase only the invoices you've cleared it to chase.
11 tests passing. 4 tools: 3 read tools and 1 write tool with a gate.
Safety checks: live key refused, writes off by default, re-check before send, audit log.
Cost to run: $0 locally with Stripe test mode.
An MCP server that connects Stripe to Claude, ChatGPT, or any MCP client. It reads your open invoices, works out who's late and by how much, and can re-send an overdue invoice to the customer. It starts read-only, and sending stays off until you turn it on.
Related MCP server: NitroWatch Billing Demo
Tool | What it does | Writes? |
| Open invoices past their due date, oldest first: who owes it, how much, how many days late, their payment link | No |
| Everything owed, grouped into not yet due / 1–30 / 31–60 / 61–90 / over 90 days, per currency | No |
| A customer's recent invoices and how many days late they usually pay | No |
| Re-sends an overdue invoice email through Stripe | Only with |
Test mode only. A live Stripe key stops the server before it connects to anything.
Read-only by default. send_invoice_reminder refuses to run unless the server was started with ALLOW_WRITES=true.
It re-checks before it sends. The invoice has to still be open and actually overdue, or nothing goes out.
Every call is logged. One JSON line per tool call, reads included, in ~/.stripe-collections-mcp/audit.jsonl. Set AUDIT_LOG to move it, or AUDIT_LOG=off to turn it off.
Bad input never reaches Stripe. Customer and invoice ids are validated first.
Use a restricted key. In Stripe, create a restricted key with Invoices: Read and Customers: Read. Add Invoices: Write only if you turn sending on.
An agent that can send money-related emails needs a hard off switch.
Invoice state can change between a recommendation and a send, so the server checks again before it sends.
An audit trail makes each tool call reviewable.
Needs Node 20 or newer. Clone the repo, then:
npm installnpm install builds it. The server lives at dist/src/index.js.
Claude Desktop: add this to claude_desktop_config.json, then restart Claude.
{
"mcpServers": {
"stripe-collections": {
"command": "node",
"args": ["/absolute/path/to/stripe-collections-mcp/dist/src/index.js"],
"env": {
"STRIPE_API_KEY": "rk_test_...",
"ALLOW_WRITES": "false"
}
}
}
}Claude Code:
claude mcp add stripe-collections -e STRIPE_API_KEY=rk_test_... -- node /absolute/path/to/stripe-collections-mcp/dist/src/index.js"Who owes me money right now?"
"How much is more than 60 days late?"
"How late does this customer usually pay?"
"Send a reminder for every invoice more than 30 days late." (Needs ALLOW_WRITES=true. Your client will still ask before each send unless you've auto-approved the tool.)
npm test11 tests call every tool through a real MCP client against a fake Stripe, so they never touch the network. They cover the sort order, the aging buckets, the late-payment math, sending blocked while writes are off, refusing invoices that are paid or not due yet, Stripe errors coming back as tool errors, and the live-key guard.
src/backend.ts: the only file that talks to Stripe. It flattens Stripe's invoice into the fields the tools need.
src/server.ts: the four tools, the aging math, and the write gate.
src/safety.ts: the test-mode key check and the audit log.
src/index.ts: stdio entry point. Logs go to stderr because stdout carries the protocol.
Swapping Stripe for another billing API means rewriting backend.ts and nothing else.
Built by Vanwayne Chaney. I build custom MCP servers that connect your API to Claude and ChatGPT.
A customer's recent invoices and how late they usually pay. Use it before deciding whether a reminder is worth sending.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| customer_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the useful note that the result includes a lateness pattern, not just raw invoices, but says nothing about the time window behind 'usually' or how far back 'recent' reaches — both of which materially change interpretation of the output.
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, no filler, and the usage cue follows immediately after the purpose statement. Every clause 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?
With no output schema and zero schema coverage, the description should say more about the shape of the returned history and the meaning of its two parameters. It conveys intent well enough to call the tool, but not enough to interpret 'how late they usually pay' reliably.
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 0%, so the description carries the full burden. It never mentions customer_id at all and never explains that 'recent' is controlled by a limit parameter defaulting to 12 with a 100 cap — an agent cannot infer the result-window semantics from the description alone.
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 the resource and its contents clearly ('a customer's recent invoices and how late they usually pay'), which tells an agent this is a per-customer payment-behavior lookup. It does not name the retrieval verb or explicitly distinguish itself from list_overdue_invoices or receivables_summary, so differentiation is left partly implicit.
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?
'Use it before deciding whether a reminder is worth sending' gives a concrete decision context that links directly to the send_invoice_reminder sibling. What's missing is any exclusion — it never says when a different sibling (e.g. receivables_summary) is the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open Stripe invoices that are past their due date, oldest first, with who owes it, how much, how many days late, and the customer's payment link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| min_days_overdue | No | Only invoices at least this many days past due. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine value beyond that: it specifies the status filter ('open'), the sort order ('oldest first'), and the shape of each record (who owes, amount, days late, payment link), which tells the agent what a call will actually yield.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence, front-loaded with the resource and scope, trailing into return-field detail. Nothing is padded or repeated.
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 usefully enumerates the returned fields and the ordering, which is the key missing piece. It does not explain pagination or how results behave past the 100-item cap, a minor gap for a pure read tool with safety annotations.
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 only 50% — min_days_overdue is documented in the schema, while limit is not. The description says nothing about either parameter, not even how the 'oldest first' ordering interacts with a result cap, so it fails to compensate for the coverage gap.
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 concrete operation and resource ('Open Stripe invoices that are past their due date') plus sort order and the fields returned, so the agent can picture the result. It does not explicitly contrast itself with siblings like receivables_summary, but the noun phrase 'open ... invoices past due' is naturally distinct from a summary or a reminder-send action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no sentence telling the agent when to prefer this over receivables_summary or customer_payment_history, nor any prerequisite or exclusion. Usage is only implied by the purpose statement itself — an agent will infer 'call this to get the overdue list' but must reason about the other tools on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything still owed on open invoices, grouped by how late it is (not yet due, 1-30, 31-60, 61-90, over 90 days), totaled per currency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description still contributes the exact aging bucket boundaries (not yet due, 1-30, 31-60, 61-90, over 90) and the currency-level aggregation, which an agent cannot infer from the schema. It omits softer behavior like whether amounts reflect as-of-today or a snapshot, and excludes unapplied credits/paid invoices, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with what is measured ('everything still owed on open invoices') followed by the grouping and totaling rules. Every clause adds information; nothing is padding.
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 does the job of explaining the return shape — buckets plus per-currency totals — which is exactly what an agent needs to plan a call. The remaining gap is the absence of an as-of date / data freshness note and confirmation that no parameters exist, which for a zero-input reporting tool is a minor rather than blocking omission.
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 takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate; baseline 4 applies. A brief note that no filtering (customer, date, currency) is possible would have raised this to a 5, since an agent may otherwise assume it can scope the report.
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?
Names a concrete resource (amounts owed on open invoices) and a concrete shape (aged buckets, per-currency totals), so the agent knows immediately this is an aggregated receivables aging report. It implicitly separates itself from list_overdue_invoices (detail list) by saying 'grouped' and 'totaled', but never names a sibling, so it falls short of the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the aggregation language suggests 'use for an overview, not for per-invoice drill-down'. There is no explicit statement of when to pick this over list_overdue_invoices or customer_payment_history, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-sends an overdue invoice email to the customer through Stripe. Blocked unless the server was started with ALLOW_WRITES=true, and it checks the invoice is still open and overdue before sending.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses a write-gating prerequisite (ALLOW_WRITES=true) and a server-side validation step before sending. It does not mention rate limits or exact failure behavior, but it meaningfully clarifies safety and preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and followed by the critical constraints. Every sentence adds useful information with 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?
Given one required parameter, no output schema, and existing annotations, the description covers the core purpose, write gate, and validation. It is nearly complete, with only minor gaps around the invoice_id semantics and precise error outcomes.
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 has zero description coverage for invoice_id, and the description never explains the parameter itself, its expected format, or how it relates to the open/overdue validation. The single parameter is obvious, but the description does not compensate for the schema gap.
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: 'Re-sends an overdue invoice email ... through Stripe.' This clearly distinguishes it from read-oriented siblings like list_overdue_invoices and receivables_summary.
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 gives clear operational context: the invoice must still be open and overdue, and the server must have ALLOW_WRITES=true. It does not explicitly mention sibling alternatives, but the preconditions are strong enough to guide correct use.
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.
v0.1.0customer_payment_historylist_overdue_invoicesreceivables_summarysend_invoice_reminderScored across 4 tools
Each tool has a distinct role: listing overdue invoices (row-level), aggregating receivables by aging bucket, per-customer payment behavior, and a write action to send a reminder. The only mild overlap is between list_overdue_invoices and receivables_summary, both about overdue amounts, but the descriptions make the list-vs-aggregate split clear.
Three tools follow a verb_noun snake_case pattern (send_invoice_reminder, list_overdue_invoices, customer_payment_history), while receivables_summary is noun-first and lacks a verb. Minor deviation, but all names are readable and domain-predictable.
Four tools is tightly scoped to the collections workflow: discover overdue invoices, summarize exposure, vet a customer, then act. Every tool earns its place with no filler.
The core collections lifecycle (identify, aggregate, assess, remind) is covered end to end. Minor gaps exist: no bulk reminder sending, no invoice-level detail/status lookup beyond the overdue list, and no snooze/write-off or reminder-history tracking.
An owner's own Stripe: who owes you, today's money, draft invoices. Every write needs a confirm.
Find overdue invoices, draft invoices, and chase payment. Sends need your confirmation.
Stripe MCP Pack — read-only access to Stripe data via API key.
MCP server for Autumn — read customers, plans, balances & invoices; track usage and attach plans.