Workers' Rights

Find how similar cases were decided

find_similar_cases

Read-only

Given the facts of an employment situation — claim types, protected class, employer, state — analyze how similar real cases in the corpus were decided. Returns the aggregate plaintiff (employee) win rate, settlement rate, typical damages range, the factors that most helped employees win vs. lose, and a few representative example cases. This is the highest-value grounding tool for 'what are my chances / what matters' questions. Educational statistics, not a prediction or legal advice.

Input Schema

TableJSON Schema

Name	Required	Description
`state`	No	Two-letter US state code the situation arose in, e.g. "FL", "CA".
`law_ids`	No	Related law ids, e.g. ["title-vii","adea","ada","fmla","flsa"].
`industry`	No	Employer industry, e.g. "healthcare", "retail", "transportation".
`claim_types`	No	Claim types alleged, snake_case, e.g. ["retaliation","wrongful_termination","discrimination","harassment"]. The single highest-value signal.
`employer_name`	No	Employer / defendant name, e.g. "Union Pacific Railroad". Used for a fuzzy match.
`protected_classes`	No	Protected classes at issue, e.g. ["sex","race","age","disability","pregnancy","national_origin"].

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 4, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Changed18 schema fields changedAug 20, 2026
- removedInput schema / properties / claim_types / default
```
Removed value: -[]
```
- addedInput schema / properties / claim_types / items / maxLength
```
Added value: +80
```
- addedInput schema / properties / claim_types / items / minLength
```
Added value: +1
```
- addedInput schema / properties / claim_types / maxItems
```
Added value: +20
```
- addedInput schema / properties / employer_name / minLength
```
Added value: +1
```
- changedInput schema / properties / industry / maxLength
```
Previous value: -60New value: +80
```
- addedInput schema / properties / industry / minLength
```
Added value: +1
```
- removedInput schema / properties / law_ids / default
```
Removed value: -[]
```
- addedInput schema / properties / law_ids / items / maxLength
```
Added value: +80
```
- addedInput schema / properties / law_ids / items / minLength
```
Added value: +1
```
- addedInput schema / properties / law_ids / maxItems
```
Added value: +20
```
- removedInput schema / properties / protected_classes / default
```
Removed value: -[]
```
- addedInput schema / properties / protected_classes / items / maxLength
```
Added value: +80
```
- addedInput schema / properties / protected_classes / items / minLength
```
Added value: +1
```
- addedInput schema / properties / protected_classes / maxItems
```
Added value: +20
```
- removedInput schema / properties / state / maxLength
```
Removed value: -2
```
- removedInput schema / properties / state / minLength
```
Removed value: -2
```
- addedInput schema / properties / state / pattern
```
Added value: +"^[A-Za-z]{2}$"
```
Changed2 schema fields changedJul 15, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / required
```
Removed value: -[
-  "claim_types",
-  "protected_classes",
-  "law_ids"
-]
```
First observedJun 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, non-destructive, and open-world traits. The description adds important behavioral context by clarifying that output is educational statistics and not a prediction or legal advice, and by describing the aggregate nature of the return values. This exceeds the baseline but does not disclose deeper mechanics such as how similarity is determined.

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 concise sentences with no filler. The first sentence states the action and inputs, the second enumerates the output, and the third provides usage positioning. Every sentence contributes value.

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 having no output schema, the description enumerates the returned information in detail: win rate, settlement rate, damages range, influencing factors, and example cases. Combined with strong parameter descriptions and annotations, an agent has enough context to select and invoke the tool appropriately. It also sets appropriate expectations with the educational disclaimer.

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 description coverage is 100%, so the schema already documents all six parameters. The description adds meaning by positioning claim_types as 'the single highest-value signal' and by framing the other fields as the facts of an employment situation. This is useful selection guidance beyond the schema.

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 uses a specific verb and resource: 'analyze how similar real cases in the corpus were decided.' It clearly defines the tool's function and even identifies its intended high-value use case. However, it does not explicitly name or contrast sibling tools, so it stops short of full sibling differentiation.

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 gives clear usage context: it is the go-to grounding tool for 'what are my chances / what matters' questions. It does not, however, state when not to use it or point to alternative tools such as search_rulings or get_corpus_stats, so exclusions and alternatives are missing.

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

All Workers' Rights 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.

Resources

Need Help?