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

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly and openWorld annotations, the description details exactly what the tool returns (aggregate win rate, settlement rate, damages range, factors, representative examples) and adds an important disclaimer: 'Educational statistics, not a prediction or legal advice.' This goes well beyond the annotations' scope.

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, each adding unique value: purpose, outputs, and usage guidance plus caveat. Front-loaded and free of fluff.

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?

Since there is no output schema, the description fully covers return values and caveats, ensuring an agent knows what to expect and how to frame results. It addresses the tool's role in the overall workflow, making it complete for its complexity.

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?

With 100% schema coverage, the baseline is 3. The description adds meaningful context by framing inputs as 'the facts of an employment situation' and naming key parameters (claim types, protected class, employer, state), reinforcing how an agent should map user language to these inputs without restating schemas.

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?

Description clearly states the tool analyzes how similar cases were decided and enumerates specific outputs (win rate, settlement rate, damages range, factors, examples). It is easily distinguishable from siblings like search_rulings or get_corpus_stats because it frames the tool's unique role in outcome analysis.

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 explicitly identifies the tool as 'the highest-value grounding tool for ''what are my chances / what matters'' questions,' giving clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, which prevents a perfect score.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: legal explanation, attorney lookup, case analytics, attorney history, employer history, EEOC process, evidence preservation, corpus stats, and ruling search. Even the two case-research tools are clearly differentiated by input type and output (aggregate outcomes vs. individual rulings).

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern, with 'get_*' used for retrieval tools, 'find_*' for lookup tools, and 'search_*'/'explain_*' for their respective functions. There is no mixing of naming conventions or vague verbs.

Tool Count5/5

Nine tools is well-scoped for a workers' rights research and guidance server. Each tool covers a meaningful capability without redundancy, and the count is comfortably within the expected range for a focused domain server.

Completeness5/5

The tool set covers the full worker-facing research journey: understanding rights, preserving evidence, navigating EEOC process, researching precedents and outcomes, finding attorneys, and checking attorney/employer track records. No critical dead-end or missing core operation is apparent for the stated informational purpose.

Resources

Need Help?