F
licenseNot graded
qualityD
maintenanceConnects Notion databases with LLMs to manage and analyze personal finances through natural language queries and bank statement uploads.
1
-
zombie-killer
by Baneado98
Detects Netflix subscriptions from transaction data and provides letters to cancel, renegotiate, or request data deletion.
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., "@zombie-killerscan my bank statement for zombie subscriptions"
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.
zombie-killer 🧟
Find the subscriptions silently draining your bank account — and get the exact letters to cancel them, renegotiate the bill down, or erase your data.
You paste your bank/card statement (or a list of subscriptions). zombie-killer detects the recurring charges, flags the zombies (forgotten, price-crept, free-trials-that-converted, hard-to-cancel), totals your yearly waste, and drafts ready-to-send letters. You send them. It never contacts the company, never impersonates you, never acts on your behalf.
Works for people (web app) and for AI agents (MCP server + x402 pay-per-call).
What it does
Detect — parses raw transaction text (CSV export or free-form lines), groups by merchant via an embedded catalog of ~50 high-frequency subscription services (with real cancellation / privacy contacts), classifies cadence (weekly / monthly / quarterly / yearly), and scores each charge ZOMBIE / REVIEW / ACTIVE. One-off purchases (gas, groceries) are not flagged.
Draft — for each charge, three ready-to-send letters:
Cancellation — firm request to cancel and stop all future billing (kills continuous payment authority).
Renegotiation — a retention/loyalty-discount script to lower a recurring bill before you cancel.
Data deletion — a GDPR Art. 17 (EU/UK) or CCPA/CPRA §1798.105 (California) erasure request.
Send — every letter ships with where/how to send it. You send it yourself from your own account.
Self-help templates, not legal advice. zombie-killer drafts; the human sends.
Related MCP server: IL Bank MCP
Web app
Open the site, paste your statement, hit Find my zombie subscriptions. The scan and the verdicts are free. Unlocking the full letter package is a one-time crypto payment (no account, no card).
MCP server (for AI agents)
{
"mcpServers": {
"zombie-killer": { "command": "npx", "args": ["-y", "subkill-mcp"] }
}
}Tools:
scan_subscriptions— raw data to recurring charges + zombie verdicts + annualized savings.generate_letter— draft one cancel / renegotiate / data-deletion letter.build_letter_package— scan + draft the full package in one call.
Or connect over HTTP at POST /mcp.
Pay-per-call (x402)
The /pro/package route is gated by x402. An agent pays in USDC on Base automatically — no sign-up, no API key.
GET /pro/package?data=2026-05-12,NETFLIX.COM,-12.99&jurisdiction=euHTTP API
Method | Path | |
POST |
| Free. |
POST |
| Paid. Full letter package (unlocked by a confirmed payment). |
GET |
| Paid via x402 (agents). |
POST |
| MCP-over-HTTP (free). |
GET |
| Discovery. |
Privacy
Your statement is processed in-memory to detect recurring charges and is not stored. Don't paste card numbers — they aren't needed.
License
MIT.
Available Tools
3 toolsbuild_letter_packageC
Scan raw data and build the full action package: for every detected zombie/review charge, draft the cancel + renegotiate + data-deletion letters in one go. The complete deliverable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Raw transaction text. | |
| onlyZombies | No | If true, only build letters for ZOMBIE-verdict charges (default: zombies + review). | |
| types | No | ||
| fullName | No | ||
| No | |||
| accountId | No | ||
| jurisdiction | No |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions scanning and building letters but omits details on side effects (e.g., data persistence), required permissions, or error handling.
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 that are front-loaded with the primary action. Efficient but could be slightly more concise by removing 'the complete deliverable' redundancy.
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?
For a complex tool with 7 parameters and no output schema, the description does not cover return value format, input prerequisites, or how the raw data should be structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (29%), but the description adds some meaning to onlyZombies by linking it to zombie/review charges. However, it fails to explain the role of other parameters like types, fullName, email, etc.
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?
Clearly states the verb 'scan' and 'build', identifies the resource ('full action package' with specific letter types), and differentiates from siblings by indicating it handles multiple charges in one go.
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 explicit guidance on when to use this tool versus alternatives like generate_letter or scan_subscriptions. The description lacks context on prerequisites or 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.
generate_letterB
Draft a ready-to-send letter for one recurring charge: a cancellation request, a renegotiation/retention script, or a GDPR/CCPA data-deletion request. You send it yourself; this only drafts it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| merchant | Yes | Merchant name as returned by scan_subscriptions. | |
| amount | No | ||
| currency | No | ||
| cadence | No | ||
| cancelHint | No | ||
| privacyContact | No | ||
| fullName | No | ||
| No | |||
| accountId | No | ||
| jurisdiction | No |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool only drafts and does not send, which implies no destructive actions, but lacks details on data handling, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the primary purpose. It could include more detail without becoming verbose.
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?
Given 11 parameters, no output schema, and no behavioral annotations, the description is incomplete. It misses prerequisites (e.g., source data from scan_subscriptions), output format, and parameter usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 9% schema description coverage, the description should compensate but only indirectly references the 'type' parameter via the three letter types. Other parameters like 'cancelHint', 'privacyContact', and 'jurisdiction' remain unexplained.
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 drafts a letter for one recurring charge, listing three specific types. It distinguishes itself from siblings by focusing on a single letter without sending, but does not explicitly differentiate from 'build_letter_package'.
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 explains that the tool only drafts and does not send, but lacks guidance on when to use this tool versus siblings like 'build_letter_package' or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_subscriptionsA
Detect recurring subscriptions and 'zombie' (forgotten / wasteful) charges from raw bank or subscription data. Paste a CSV export or free-form lines (date, description, amount). Returns each recurring charge with a ZOMBIE/REVIEW/ACTIVE verdict, cadence, annualized cost, and the estimated yearly savings from killing the zombies.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Raw transaction text: CSV bank export or lines like '2026-05-12, NETFLIX.COM, -12.99'. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns verdicts, cadence, cost, and savings, but does not explicitly state it is read-only, non-destructive, or mention any permissions needed.
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 concise, well-structured, and front-loaded. It starts with purpose, then input instructions, then output summary, with no wasted words.
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 single-parameter tool with no output schema, the description covers purpose, input format, and output fields (verdict, cadence, cost, savings). It is sufficiently complete, though it could mention limitations like maximum data size.
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?
Schema coverage is 100% for the single parameter. The description adds formatting guidance ('Paste a CSV export or free-form lines') beyond the schema's description, enhancing understanding.
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 clearly states the tool detects recurring subscriptions and 'zombie' charges from raw data. It uses specific verbs ('Detect') and resources ('subscriptions', 'zombie charges'), and is distinct from sibling tools like build_letter_package.
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 provides clear instructions on input format (CSV export or free-form lines with date, description, amount). However, it does not explicitly state when not to use this tool or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
build_letter_package - First observed
generate_letter - First observed
scan_subscriptions
TDQS
A3.7/5.0
Scored across 3 tools
Disambiguation5/5
Each tool targets a distinct step in the workflow: scanning for charges, drafting individual letters, and building a complete package. No overlap in purpose.
Naming Consistency5/5
All tools follow a clear verb_noun pattern: scan_subscriptions, generate_letter, build_letter_package. Consistent and predictable.
Tool Count5/5
Three tools is perfectly scoped for this focused domain—covering detection, single-action drafting, and batch processing without bloat.
Completeness5/5
The tool set covers the full lifecycle for the intended purpose: scanning to identify zombies, generating individual letters, and packaging them. No essential operation is missing.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
- RenewlyOAuthgg.renewly
Read contracts, track renewals, surface vendor leverage, and draft cancellation/renewal emails.
Track, analyze, and act on your streaming and SaaS subscriptions from any AI agent.
Turn bank statement PDFs, CSVs, XLSX and OFX into categorised transactions plus a summary.
Chat with your bank data: balances, transactions, budgets, bills. Reads only, never moves money.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceFinance assistant that brings your Israeli bank data to any AI assistant, enabling transaction analysis, spending patterns, and financial insights.11-
- FlicenseAqualityCmaintenanceAn MCP-powered AI agent that audits your Gmail for recurring subscriptions, detects silent price increases, and flags unused services.6-
Kordi MCP Serverofficial
AlicenseNot gradedqualityDmaintenanceTrack, analyze, and act on your streaming & SaaS subscriptions from any AI agent.MIT