Audit junk fees, project annual costs and draft dispute letters. Free.
Scored across 4 tools
Each tool targets a clearly distinct task: cost projection (annual_cost), problem-charge detection (audit_fees), range lookup (benchmark_fees), and letter drafting (dispute_letter). The descriptions explicitly cross-reference one another to steer selection, e.g. 'use annual_cost' vs 'use audit_fees', eliminating overlap.
All names are snake_case and readable, with audit_fees, benchmark_fees, and dispute_letter following a consistent verb_noun pattern. annual_cost is a minor deviation since it reads as a noun phrase rather than an action, but the set remains predictable.
Four tools is slightly thin for a fee-analysis domain but each one clearly earns its place in the workflow. No redundant or filler tools are present, though a couple more (e.g. fee comparison) could round it out.
The surface covers a full lifecycle: audit to find problem fees, benchmark to gauge normalcy, annual_cost to project, and dispute_letter to act. Minor gaps exist (no fee comparison across providers or savings estimate), but core workflows have no dead ends.
Project the cumulative cost of a fee list over 1-30 years by straight multiplication of each recurring fee's annualized amount, with one-time fees counted once (no compounding or inflation), with a per-fee breakdown. Use for 'what will these cost me over N years'. It does not flag fees: use audit_fees to find problem charges, benchmark_fees for typical ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| fees | Yes | Non-empty list of fees to project, each {name, amount, frequency, category?}; category is accepted but not used here | |
| years | No | Number of years to project, integer 1-30; default 1 |
| Name | Required | Description |
|---|---|---|
| note | Yes | Method note: recurring fees multiplied by years, one-time fees counted once, no compounding |
| years | Yes | Number of years projected (1-30) |
| per_fee | Yes | Per-fee projection, in input order |
| cumulative_total | Yes | Sum of all per-fee cumulative amounts, USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's real contribution is the calculation semantics: no compounding, no inflation, one-time fees counted once, per-fee breakdown. That is genuinely useful behavioral context beyond the annotations, though it leaves limits/rate behavior unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core computation front-loaded and the sibling routing at the end. Every clause carries information; the only slight density cost is the parenthetical negation about compounding.
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?
An output schema exists, so return values need not be described. With parameters fully covered by the schema, safety covered by annotations, and the calculation methodology, scope, and sibling boundaries all stated, nothing an agent needs in order to call this correctly is missing.
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 both parameters (fees, years) are already fully documented, including the enum values, the 1-30 bound, and the note that category is ignored. The description restates the multiplication logic but adds no syntax or format detail the schema lacks; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource (project cumulative cost of a fee list) and pins the mechanism (straight multiplication, 1-30 years). It explicitly distinguishes itself from siblings audit_fees and benchmark_fees, so an agent can route without opening any schema.
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?
Gives a concrete trigger phrase ("what will these cost me over N years") and an explicit exclusion clause ("It does not flag fees") that names the two correct alternatives. Both when-to-use and when-not-to-use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a list of fees: annualize each one (monthly x12), total the yearly cost and monthly average, and flag charges above the typical US range for their category, duplicate names and one-time fees of $30+ worth disputing. Use when the user lists fees to review. For a multi-year projection use annual_cost; for typical ranges alone use benchmark_fees.
| Name | Required | Description | Default |
|---|---|---|---|
| fees | Yes | Non-empty list of fees to audit, each {name, amount, frequency, category?} |
| Name | Required | Description |
|---|---|---|
| fees | Yes | One audited row per input fee, in input order |
| note | Yes | Plain-language summary of the audit result; lists any unknown category keys that were ignored |
| currency | Yes | Currency of all amounts; always USD |
| total_annual | Yes | Sum of all annualized fees, USD |
| flagged_count | Yes | Number of fees with at least one flag |
| total_monthly_average | Yes | total_annual divided by 12, USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral substance on top: the annualization formula (monthly x12), the aggregations produced, and the specific flagging thresholds (above typical US range, duplicate names, one-time fees of $30+). It does not discuss error handling for malformed fee entries, but the output schema carries the return 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?
Two sentences, zero filler. The core computation is front-loaded before the routing guidance, and every clause (annualization, totals, flag rules, alternatives) carries information an agent needs.
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?
An output schema exists so return values need not be described, and the description still covers the computation, aggregation and flagging semantics plus sibling routing. Nothing material is missing for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single fees parameter, including nested name/amount/category/frequency documentation and the benchmark category key list, so the baseline is 3. The description restates the monthly x12 rule and adds the $30 one-time threshold, which is a marginal gain over 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?
States a specific verb (audit) and resource (list of fees) and spells out the exact operations performed: annualize monthly x12, total yearly cost and monthly average, and flag outliers, duplicates and disputable one-time fees. It also names what it is not by pointing to annual_cost and benchmark_fees, so an agent can separate it from siblings without opening any schema.
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?
Gives an explicit trigger ('Use when the user lists fees to review') plus two named alternatives with the exact condition that selects each: multi-year projection -> annual_cost, typical ranges alone -> benchmark_fees. Both the when and the when-not are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up typical US consumer fee ranges (min/max per charge, USD) for one category such as bank_overdraft, or the full 14-category table when category is omitted. Use to answer 'is this fee normal?' questions. To check a user's own list of fees against these ranges, use audit_fees.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category key (case-insensitive; spaces/hyphens become underscores), one of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Omit to get the full table; an unknown key returns an error listing valid keys. |
| Name | Required | Description |
|---|---|---|
| basis | No | Basis label for the range (typical US range - verify current pricing) |
| count | No | Number of categories (full-table response only) |
| label | No | Human-readable fee label, e.g. 'Out-of-network ATM fee' |
| category | No | Benchmark category key, e.g. bank_overdraft |
| currency | Yes | Currency of all ranges; always USD |
| categories | No | Every benchmark row (full-table response only) |
| disclaimer | Yes | Informational-only disclaimer |
| source_note | Yes | Where the ranges come from and how to read them |
| typical_max | No | High end of the typical US range per charge, USD |
| typical_min | No | Low end of the typical US range per charge, USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only/idempotent/non-destructive profile, so the bar is lower. The description adds real context: what is returned (min/max per charge in USD), the default to the full 14-category table when category is omitted, and that unknown keys error. Minor remaining gap, but it is a substantive contribution beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the core capability front-loaded, followed by the use case and the sibling routing. No filler and every sentence carries a distinct piece of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with a documented parameter and an output schema covering return values, the description supplies everything the agent needs: purpose, modes, use case, and disambiguation from the sibling. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single category parameter, its accepted keys, case-folding rules, and the omit-for-all behavior are all documented in the schema. The description echoes the category example and fallback but adds no syntax beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('look up') and resource ('typical US consumer fee ranges (min/max per charge, USD)') plus the two operating modes (single category or full 14-category table). It also names the sibling audit_fees, so an agent can distinguish it from alternatives without opening the schema.
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?
Explicitly gives the use case ('answer is this fee normal? questions') and an exclusion with the named alternative ('to check a user's own list of fees against these ranges, use audit_fees'). When-to-use and when-to-use-something-else are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft (text only; nothing is sent) a firm, polite letter asking a company to reverse or refund one specific fee, with grounds, a 14-day written-response request, an escalation path and sending tips. Use once the user has picked a fee to contest. To find which fees are worth disputing first, use audit_fees.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Fee amount in USD, greater than 0, e.g. 38 | |
| reason | No | Optional grounds for the dispute; default cites an undisclosed/unexpected charge and asks for a courtesy reversal | |
| company | Yes | Company or bank that charged the fee, e.g. 'First National Bank' | |
| fee_name | Yes | Name of the fee being disputed, e.g. 'Overdraft fee' | |
| your_name | Yes | Account holder's full name, used in From and to sign the letter | |
| date_charged | No | Optional date the fee was charged, free text, e.g. 2026-09-14 | |
| requested_action | No | What to ask the company to do, e.g. 'waive' or 'refund'; default 'reverse or refund' | |
| account_reference | No | Optional account or reference number; prefer a masked form like '****1234' |
| Name | Required | Description |
|---|---|---|
| letter | Yes | Full letter text with To/From/Subject header and signature |
| subject | Yes | Subject line, e.g. Request to reverse or refund the $38.00 fee |
| disclaimer | Yes | Not legal or financial advice disclaimer |
| sending_tips | Yes | Practical tips for sending, following up and escalating |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with "text only; nothing is sent," which is exactly the concern an agent might have about a dispute tool. It further discloses the letter's content profile (grounds, 14-day written-response request, escalation path, sending tips). No rate limits or output format caveats, but the safety-relevant behavior is clearly covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and its key constraint ("text only; nothing is sent") before the timeline details and sibling routing. Every clause carries information; nothing is redundant.
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?
An output schema exists, so return-value explanation is not needed, and the description instead characterizes what the letter contains. Combined with the usage trigger and sibling routing, an agent has everything required to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters including defaults and examples. The description only adds that the dispute targets one specific fee; it offers no extra syntax or format guidance beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (draft a letter) and resource (fee dispute letter), plus the exact scope: one specific fee, reverse or refund. It also names the sibling audit_fees and how this differs from it (disputing vs. finding fees worth disputing).
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?
Explicitly states when to use it ("once the user has picked a fee to contest") and routes the agent to the alternative ("To find which fees are worth disputing first, use audit_fees"). The pre-condition is unambiguous.
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.
annual_cost4 fields changedInput schema / properties / fees / items / properties / category / descriptionPrevious value: -"Optional benchmark category key (case-insensitive; spaces/hyphens become underscores). One of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Unknown keys are ignored."New value: +"Optional benchmark category key (case-insensitive; spaces/hyphens become underscores). One of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Unknown keys are ignored for benchmarking and listed in audit_fees' note."Output schema / properties / note / descriptionPrevious value: -"Method note: straight multiplication, no compounding"New value: +"Method note: recurring fees multiplied by years, one-time fees counted once, no compounding"Output schema / properties / per_fee / items / properties / annualized / descriptionPrevious value: -"Yearly cost of this fee, USD"New value: +"Yearly cost of this fee, USD (monthly x12; annual as-is; one-time = the single charge, counted once)"Output schema / properties / per_fee / items / properties / cumulative / descriptionPrevious value: -"annualized x years, USD"New value: +"Total over the period, USD: annualized x years for monthly/annual fees; the single amount for one-time fees"audit_fees2 fields changedInput schema / properties / fees / items / properties / category / descriptionPrevious value: -"Optional benchmark category key (case-insensitive; spaces/hyphens become underscores). One of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Unknown keys are ignored."New value: +"Optional benchmark category key (case-insensitive; spaces/hyphens become underscores). One of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Unknown keys are ignored for benchmarking and listed in audit_fees' note."Output schema / properties / note / descriptionPrevious value: -"Plain-language summary of the audit result"New value: +"Plain-language summary of the audit result; lists any unknown category keys that were ignored"annual_cost13 fields changedInput schema / properties / fees / descriptionPrevious value: -"List of yearly fees as numbers in ISO currency code"New value: +"Non-empty list of fees to project, each {name, amount, frequency, category?}; category is accepted but not used here"Input schema / properties / fees / items / properties / amount / descriptionAdded value: +"Amount per charge in USD, greater than 0, e.g. 38 or 15.99 (for monthly fees, the monthly amount)"Input schema / properties / fees / items / properties / amount / exclusiveMinimumAdded value: +0Input schema / properties / fees / items / properties / category / descriptionAdded value: +"Optional benchmark category key (case-insensitive; spaces/hyphens become underscores). One of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Unknown keys are ignored."Input schema / properties / fees / items / properties / frequency / descriptionAdded value: +"How often the fee is charged: 'monthly' (x12 per year), 'annual' or 'one-time'"Input schema / properties / fees / items / properties / name / descriptionAdded value: +"Fee label as it appears on the statement, e.g. 'Overdraft fee' or 'Netflix'"Input schema / properties / fees / items / properties / name / minLengthAdded value: +1Input schema / properties / fees / minItemsAdded value: +1Input schema / properties / years / descriptionPrevious value: -"Years to project (integer 1-30), default 1"New value: +"Number of years to project, integer 1-30; default 1"Input schema / properties / years / maximumAdded value: +30Input schema / properties / years / minimumAdded value: +1Input schema / properties / years / typePrevious value: -"number"New value: +"integer"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "cumulative_total": {
+ "description": "Sum of all per-fee cumulative amounts, USD",
+ "type": "number"
+ },
+ "note": {
+ "description": "Method note: straight multiplication, no compounding",
+ "type": "string"
+ },
+ "per_fee": {
+ "description": "Per-fee projection, in input order",
+ "items": {
+ "properties": {
+ "annualized": {
+ "description": "Yearly cost of this fee, USD",
+ "type": "number"
+ },
+ "cumulative": {
+ "description": "annualized x years, USD",
+ "type": "number"
+ },
+ "name": {
+ "description": "Trimmed fee name",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "annualized",
+ "cumulative"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "years": {
+ "description": "Number of years projected (1-30)",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "years",
+ "per_fee",
+ "cumulative_total",
+ "note"
+ ],
+ "type": "object"
+}audit_fees9 fields changedInput schema / properties / fees / descriptionPrevious value: -"Fees to audit, each with name, amount, frequency and optional category"New value: +"Non-empty list of fees to audit, each {name, amount, frequency, category?}"Input schema / properties / fees / items / properties / amount / descriptionPrevious value: -"Amount charged in USD"New value: +"Amount per charge in USD, greater than 0, e.g. 38 or 15.99 (for monthly fees, the monthly amount)"Input schema / properties / fees / items / properties / amount / exclusiveMinimumAdded value: +0Input schema / properties / fees / items / properties / category / descriptionPrevious value: -"Optional benchmark category key, e.g. bank_overdraft"New value: +"Optional benchmark category key (case-insensitive; spaces/hyphens become underscores). One of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Unknown keys are ignored."Input schema / properties / fees / items / properties / frequency / descriptionPrevious value: -"How often the fee recurs"New value: +"How often the fee is charged: 'monthly' (x12 per year), 'annual' or 'one-time'"Input schema / properties / fees / items / properties / name / descriptionPrevious value: -"Fee description, e.g. 'Overdraft fee'"New value: +"Fee label as it appears on the statement, e.g. 'Overdraft fee' or 'Netflix'"Input schema / properties / fees / items / properties / name / minLengthAdded value: +1Input schema / properties / fees / minItemsAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "currency": {
+ "description": "Currency of all amounts; always USD",
+ "type": "string"
+ },
+ "fees": {
+ "description": "One audited row per input fee, in input order",
+ "items": {
+ "properties": {
+ "amount": {
+ "description": "Amount per charge, USD, rounded to cents",
+ "type": "number"
+ },
+ "annualized": {
+ "description": "Yearly cost of this fee, USD (monthly x12; annual and one-time as-is)",
+ "type": "number"
+ },
+ "flags": {
+ "description": "Problem flags; empty when none apply",
+ "items": {
+ "enum": [
+ "above typical",
+ "duplicate name",
+ "worth disputing"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "frequency": {
+ "description": "Charge frequency as given",
+ "enum": [
+ "monthly",
+ "annual",
+ "one-time"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "description": "Trimmed fee name",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "amount",
+ "frequency",
+ "annualized",
+ "flags"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "flagged_count": {
+ "description": "Number of fees with at least one flag",
+ "type": "integer"
+ },
+ "note": {
+ "description": "Plain-language summary of the audit result",
+ "type": "string"
+ },
+ "total_annual": {
+ "description": "Sum of all annualized fees, USD",
+ "type": "number"
+ },
+ "total_monthly_average": {
+ "description": "total_annual divided by 12, USD",
+ "type": "number"
+ }
+ },
+ "required": [
+ "currency",
+ "fees",
+ "total_annual",
+ "total_monthly_average",
+ "flagged_count",
+ "note"
+ ],
+ "type": "object"
+}benchmark_fees2 fields changedInput schema / properties / category / descriptionPrevious value: -"Category key to look up, e.g. bank_overdraft; omit for the full table"New value: +"Category key (case-insensitive; spaces/hyphens become underscores), one of: bank_overdraft, bank_monthly_maintenance, atm_out_of_network, late_payment, gym_membership_monthly, streaming_monthly, airline_checked_bag, airline_seat_fee, ticket_convenience, rental_application, subscription_app_monthly, delivery_fee, airline_change_fee, hotel_resort_fee. Omit to get the full table; an unknown key returns an error listing valid keys."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "basis": {
+ "description": "Basis label for the range (typical US range - verify current pricing)",
+ "type": "string"
+ },
+ "categories": {
+ "description": "Every benchmark row (full-table response only)",
+ "items": {
+ "properties": {
+ "basis": {
+ "description": "Basis label for the range (typical US range - verify current pricing)",
+ "type": "string"
+ },
+ "category": {
+ "description": "Benchmark category key, e.g. bank_overdraft",
+ "type": "string"
+ },
+ "label": {
+ "description": "Human-readable fee label, e.g. 'Out-of-network ATM fee'",
+ "type": "string"
+ },
+ "typical_max": {
+ "description": "High end of the typical US range per charge, USD",
+ "type": "number"
+ },
+ "typical_min": {
+ "description": "Low end of the typical US range per charge, USD",
+ "type": "number"
+ }
+ },
+ "required": [
+ "category",
+ "label",
+ "typical_min",
+ "typical_max",
+ "basis"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "category": {
+ "description": "Benchmark category key, e.g. bank_overdraft",
+ "type": "string"
+ },
+ "count": {
+ "description": "Number of categories (full-table response only)",
+ "type": "integer"
+ },
+ "currency": {
+ "description": "Currency of all ranges; always USD",
+ "type": "string"
+ },
+ "disclaimer": {
+ "description": "Informational-only disclaimer",
+ "type": "string"
+ },
+ "label": {
+ "description": "Human-readable fee label, e.g. 'Out-of-network ATM fee'",
+ "type": "string"
+ },
+ "source_note": {
+ "description": "Where the ranges come from and how to read them",
+ "type": "string"
+ },
+ "typical_max": {
+ "description": "High end of the typical US range per charge, USD",
+ "type": "number"
+ },
+ "typical_min": {
+ "description": "Low end of the typical US range per charge, USD",
+ "type": "number"
+ }
+ },
+ "required": [
+ "currency",
+ "source_note",
+ "disclaimer"
+ ],
+ "type": "object"
+}dispute_letter10 fields changedInput schema / properties / account_reference / descriptionPrevious value: -"Optional account or reference number"New value: +"Optional account or reference number; prefer a masked form like '****1234'"Input schema / properties / amount / descriptionPrevious value: -"Fee amount in USD"New value: +"Fee amount in USD, greater than 0, e.g. 38"Input schema / properties / amount / exclusiveMinimumAdded value: +0Input schema / properties / company / descriptionPrevious value: -"Company or bank that charged the fee"New value: +"Company or bank that charged the fee, e.g. 'First National Bank'"Input schema / properties / date_charged / descriptionPrevious value: -"Optional date the fee was charged"New value: +"Optional date the fee was charged, free text, e.g. 2026-09-14"Input schema / properties / fee_name / descriptionPrevious value: -"Name of the fee being disputed"New value: +"Name of the fee being disputed, e.g. 'Overdraft fee'"Input schema / properties / reason / descriptionPrevious value: -"Optional grounds for the dispute"New value: +"Optional grounds for the dispute; default cites an undisclosed/unexpected charge and asks for a courtesy reversal"Input schema / properties / requested_action / descriptionPrevious value: -"What to ask for, e.g. 'reverse or refund' or 'waive'; default 'reverse or refund'"New value: +"What to ask the company to do, e.g. 'waive' or 'refund'; default 'reverse or refund'"Input schema / properties / your_name / descriptionPrevious value: -"Your name, used to sign the letter"New value: +"Account holder's full name, used in From and to sign the letter"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "disclaimer": {
+ "description": "Not legal or financial advice disclaimer",
+ "type": "string"
+ },
+ "letter": {
+ "description": "Full letter text with To/From/Subject header and signature",
+ "type": "string"
+ },
+ "sending_tips": {
+ "description": "Practical tips for sending, following up and escalating",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "subject": {
+ "description": "Subject line, e.g. Request to reverse or refund the $38.00 fee",
+ "type": "string"
+ }
+ },
+ "required": [
+ "subject",
+ "letter",
+ "sending_tips",
+ "disclaimer"
+ ],
+ "type": "object"
+}annual_cost1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "feeBreakdown": {
- "description": "The cost of each fee over the specified number of years.",
- "items": {
- "properties": {
- "name": {
- "description": "The name of the fee.",
- "type": "string"
- },
- "totalAmount": {
- "description": "The total cost of the fee over the specified number of years.",
- "type": "number"
- },
- "yearlyAmounts": {
- "description": "The cost of the fee for each year in the projection.",
- "items": {
- "properties": {
- "amount": {
- "description": "The cost of the fee for that year.",
- "type": "number"
- },
- "year": {
- "description": "The year number in the projection.",
- "type": "integer"
- }
- },
- "required": [
- "year",
- "amount"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "name",
- "totalAmount",
- "yearlyAmounts"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalCost": {
- "description": "The cumulative cost of all fees over the specified number of years.",
- "type": "number"
- },
- "yearlyBreakdown": {
- "description": "The cost of all fees for each year in the projection.",
- "items": {
- "properties": {
- "cost": {
- "description": "The total cost for that year.",
- "type": "number"
- },
- "year": {
- "description": "The year number in the projection.",
- "type": "integer"
- }
- },
- "required": [
- "year",
- "cost"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "totalCost",
- "yearlyBreakdown",
- "feeBreakdown"
- ],
- "type": "object"
-}New value: +nullaudit_fees1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "annualizedFees": {
- "description": "A list of fees with their annualized amounts.",
- "items": {
- "properties": {
- "annualizedAmount": {
- "description": "The annualized amount of the fee.",
- "type": "number"
- },
- "name": {
- "description": "The name of the fee.",
- "type": "string"
- }
- },
- "required": [
- "name",
- "annualizedAmount"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "flags": {
- "description": "A list of flags indicating issues with specific fees.",
- "items": {
- "properties": {
- "details": {
- "description": "Additional details about the flagged issue.",
- "type": "string"
- },
- "issue": {
- "description": "The type of issue flagged for the fee.",
- "enum": [
- "above_typical_range",
- "duplicate_name",
- "disputable_one_time"
- ],
- "type": "string"
- },
- "name": {
- "description": "The name of the fee that triggered the flag.",
- "type": "string"
- }
- },
- "required": [
- "name",
- "issue"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "monthlyAverage": {
- "description": "The average monthly cost of all fees.",
- "type": "number"
- },
- "totalYearlyCost": {
- "description": "The sum of all annualized fees.",
- "type": "number"
- }
- },
- "required": [
- "totalYearlyCost",
- "monthlyAverage",
- "flags",
- "annualizedFees"
- ],
- "type": "object"
-}New value: +nullbenchmark_fees1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "category": {
- "description": "The category key looked up, e.g. bank_overdraft; or 'all' if the full table was returned.",
- "type": "string"
- },
- "fees": {
- "description": "List of typical fee ranges for the category.",
- "items": {
- "properties": {
- "fee_type": {
- "description": "The specific fee type within the category, e.g. 'overdraft fee'.",
- "type": "string"
- },
- "max": {
- "description": "The maximum typical fee amount.",
- "type": "number"
- },
- "min": {
- "description": "The minimum typical fee amount.",
- "type": "number"
- }
- },
- "required": [
- "fee_type",
- "min",
- "max"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "category",
- "fees"
- ],
- "type": "object"
-}New value: +nulldispute_letter1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "letter": {
- "description": "The full text of the dispute letter.",
- "type": "string"
- },
- "recipient": {
- "description": "The recipient of the letter, inferred from the company name.",
- "type": "string"
- },
- "subject": {
- "description": "The subject line of the letter.",
- "type": "string"
- }
- },
- "required": [
- "letter",
- "subject",
- "recipient"
- ],
- "type": "object"
-}New value: +nullannual_cost1 field changedInput schema / properties / fees / descriptionAdded value: +"List of yearly fees as numbers in ISO currency code"annual_cost1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "feeBreakdown": {
+ "description": "The cost of each fee over the specified number of years.",
+ "items": {
+ "properties": {
+ "name": {
+ "description": "The name of the fee.",
+ "type": "string"
+ },
+ "totalAmount": {
+ "description": "The total cost of the fee over the specified number of years.",
+ "type": "number"
+ },
+ "yearlyAmounts": {
+ "description": "The cost of the fee for each year in the projection.",
+ "items": {
+ "properties": {
+ "amount": {
+ "description": "The cost of the fee for that year.",
+ "type": "number"
+ },
+ "year": {
+ "description": "The year number in the projection.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "year",
+ "amount"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "totalAmount",
+ "yearlyAmounts"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalCost": {
+ "description": "The cumulative cost of all fees over the specified number of years.",
+ "type": "number"
+ },
+ "yearlyBreakdown": {
+ "description": "The cost of all fees for each year in the projection.",
+ "items": {
+ "properties": {
+ "cost": {
+ "description": "The total cost for that year.",
+ "type": "number"
+ },
+ "year": {
+ "description": "The year number in the projection.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "year",
+ "cost"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "totalCost",
+ "yearlyBreakdown",
+ "feeBreakdown"
+ ],
+ "type": "object"
+}audit_fees1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "annualizedFees": {
+ "description": "A list of fees with their annualized amounts.",
+ "items": {
+ "properties": {
+ "annualizedAmount": {
+ "description": "The annualized amount of the fee.",
+ "type": "number"
+ },
+ "name": {
+ "description": "The name of the fee.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "annualizedAmount"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "flags": {
+ "description": "A list of flags indicating issues with specific fees.",
+ "items": {
+ "properties": {
+ "details": {
+ "description": "Additional details about the flagged issue.",
+ "type": "string"
+ },
+ "issue": {
+ "description": "The type of issue flagged for the fee.",
+ "enum": [
+ "above_typical_range",
+ "duplicate_name",
+ "disputable_one_time"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "description": "The name of the fee that triggered the flag.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "issue"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "monthlyAverage": {
+ "description": "The average monthly cost of all fees.",
+ "type": "number"
+ },
+ "totalYearlyCost": {
+ "description": "The sum of all annualized fees.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalYearlyCost",
+ "monthlyAverage",
+ "flags",
+ "annualizedFees"
+ ],
+ "type": "object"
+}benchmark_fees1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "category": {
+ "description": "The category key looked up, e.g. bank_overdraft; or 'all' if the full table was returned.",
+ "type": "string"
+ },
+ "fees": {
+ "description": "List of typical fee ranges for the category.",
+ "items": {
+ "properties": {
+ "fee_type": {
+ "description": "The specific fee type within the category, e.g. 'overdraft fee'.",
+ "type": "string"
+ },
+ "max": {
+ "description": "The maximum typical fee amount.",
+ "type": "number"
+ },
+ "min": {
+ "description": "The minimum typical fee amount.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "fee_type",
+ "min",
+ "max"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "category",
+ "fees"
+ ],
+ "type": "object"
+}dispute_letter1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "letter": {
+ "description": "The full text of the dispute letter.",
+ "type": "string"
+ },
+ "recipient": {
+ "description": "The recipient of the letter, inferred from the company name.",
+ "type": "string"
+ },
+ "subject": {
+ "description": "The subject line of the letter.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "letter",
+ "subject",
+ "recipient"
+ ],
+ "type": "object"
+}annual_costaudit_feesbenchmark_feesdispute_letterOutcome-based bill negotiation — pay only a percentage of bank-verified savings. Free to try.
Is your US medical bill fair? Compares charges with Medicare rates and drafts a dispute letter.
Finds recurring charges in bank statements and flags what to cancel.
Find flight compensation, refunds and forgotten subscriptions you're owed; drafts claims for you.
Add one secure layer between your agents and this server.
