Settlement Claim Finder

Find open class action settlements you may claim

find_settlements

Read-onlyIdempotent

Use this when someone asks which class action settlements they can claim, or whether a purchase, a data breach letter or a service they used has a settlement. Pass where (US state or 'US') and bought_or_used in plain words; both are optional. Only US settlements are covered today: pass the person's real place, and a UK or Australian place returns not_covered_yet. Returns open US settlements with who can claim, the payout as stated, the deadline and days left, the official claim link and the source page with an as_of date. Facts come only from court-approved settlement sites. Show not_legal_advice and safety as given. It never files a claim.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "where": "Texas",
      "bought_or_used": "iPhone 16"
    },
    "name": "find_settlements"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Rows to return, 10 by default
`where`	No	Where the person lives: a US state name or code ('Texas', 'TX'), 'New York City', or 'US'. Leave out for the whole US
`bought_or_used`	No	Brands, products or services they bought or used, in plain words ('iPhone 16, Kroger pharmacy, rent an apartment'). Leave out to list every open settlement

Output Schema

Name	Required	Description
`as_of`	Yes	ISO 8601 time the data was published by its source or fetched from it. A cached answer keeps the time of its fetch.
`notes`	Yes
`where`	Yes	The place the rows were filtered for
`safety`	Yes	Show this line to the person
`source`	Yes	Who the data comes from, to cite and to check it against.
`status`	Yes
`matched`	Yes	Rows that matched before the limit
`results`	Yes
`data_as_of`	Yes	When the daily page check last ran (UTC); null before the first run
`open_for_you`	Yes	Open settlements for this place before matching
`bought_or_used`	Yes	What the rows were matched to; null when every open settlement is listed
`not_legal_advice`	Yes	Show this line to the person

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

removedOutput schema / properties / ad

Removed value: -{
-  "description": "One labeled house ad line",
-  "properties": {
-    "label": {
-      "type": "string"
-    },
-    "text": {
-      "type": "string"
-    },
-    "url": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "label",
-    "text",
-    "url"
-  ],
-  "type": "object"
-}

changedOutput schema / required

Previous value: -[
-  "status",
-  "where",
-  "bought_or_used",
-  "open_for_you",
-  "matched",
-  "results",
-  "data_as_of",
-  "notes",
-  "not_legal_advice",
-  "safety",
-  "ad",
-  "as_of",
-  "source"
-]New value: +[
+  "status",
+  "where",
+  "bought_or_used",
+  "open_for_you",
+  "matched",
+  "results",
+  "data_as_of",
+  "notes",
+  "not_legal_advice",
+  "safety",
+  "as_of",
+  "source"
+]

First observedOct 21, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive and closed-world, and the description still adds real behavior: facts come only from court-approved settlement sites, results carry an as_of date, non-US input yields not_covered_yet, and 'It never files a claim' plus the instruction to surface not_legal_advice and safety. It does not discuss rate limits or result freshness beyond as_of, but the disclosure is well beyond what annotations provide.

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?

Front-loaded with the trigger before the mechanics, and nearly every sentence carries a distinct fact (scope, input guidance, output fields, provenance, disclaimer handling). It is dense—seven clauses in one block—but there is no filler.

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?

Despite an output schema existing, the description still names the returned fields (eligibility, payout, deadline, days left, claim link, source, as_of) and covers the two things an agent most needs to handle correctly: the non-US error code and the mandatory not_legal_advice/safety passthrough. Nothing material for correct invocation is missing.

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%, so baseline is 3, and the description still adds meaning: both filters are optional, `where` accepts a state, city or 'US', and `bought_or_used` is intended as plain words (brands, products, services). The `limit` parameter is not mentioned at all, which is the only gap.

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 and resource ('Find open class action settlements you may claim') and immediately scopes it to eligibility questions ('whether a purchase, a data breach letter or a service they used has a settlement'). That is clearly distinct from the verification-flavored sibling check_settlement_site and the feedback/utility 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?

Gives an explicit trigger ('Use this when someone asks which...'), tells the agent what inputs to pass for that situation, and draws a hard scope boundary with a named failure mode ('a UK or Australian place returns not_covered_yet'). It stops short of naming an alternative tool for the case where the user already has a settlement URL, which is the one routing decision left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Settlement Claim Finder 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.