FeeFighter

Dispute letter

dispute_letter

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description
`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'

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 10, 2026

changedInput schema / properties / account_reference / description

Previous value: -"Optional account or reference number"New value: +"Optional account or reference number; prefer a masked form like '****1234'"

changedInput schema / properties / amount / description

Previous value: -"Fee amount in USD"New value: +"Fee amount in USD, greater than 0, e.g. 38"

addedInput schema / properties / amount / exclusiveMinimum
```
Added value: +0
```

changedInput schema / properties / company / description

Previous value: -"Company or bank that charged the fee"New value: +"Company or bank that charged the fee, e.g. 'First National Bank'"

changedInput schema / properties / date_charged / description

Previous value: -"Optional date the fee was charged"New value: +"Optional date the fee was charged, free text, e.g. 2026-09-14"

changedInput schema / properties / fee_name / description

Previous value: -"Name of the fee being disputed"New value: +"Name of the fee being disputed, e.g. 'Overdraft fee'"

changedInput schema / properties / reason / description

Previous 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"

changedInput schema / properties / requested_action / description

Previous 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'"

changedInput schema / properties / your_name / description

Previous value: -"Your name, used to sign the letter"New value: +"Account holder's full name, used in From and to sign the letter"

changedOutput 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"
+}

Changed1 schema field changedOct 10, 2026

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: +null

Changed1 schema field changedOct 6, 2026

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"
+}

First observedOct 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

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 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All FeeFighter tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Dispute letter

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources