Workers' Rights
Server Details
Read-only employment-law research: 140K+ rulings, employer track records, rights & EEOC guides.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 8 of 8 tools scored.
Each tool has a distinct purpose: rights explanation, lawyer search, case analysis, attorney/employer track records, EEOC process, corpus stats, and ruling search. No overlapping functionality.
All tools follow a consistent verb_noun pattern (explain, find, get, search) with clear, descriptive nouns, making the set predictable and easy to navigate.
8 tools is well within the optimal 3-15 range, covering the core aspects of employment law without being excessive or sparse.
The tool set covers the full lifecycle: understanding rights, finding legal help, analyzing cases, tracking entities, understanding processes, and searching rulings. No obvious gaps.
Available Tools
9 toolsexplain_my_rightsExplain applicable employment-law rightsARead-onlyInspect
Explain which federal (and state, if a state is given) employment laws may protect a worker based on the type of issue (e.g. discrimination, harassment, retaliation, wrongful termination) and/or the protected class involved (e.g. race, sex, age, disability, pregnancy). Returns the relevant statutes with citations, who they cover (employer-size thresholds), filing deadlines and agencies, and available remedies. Use this to ground an answer about a worker’s legal protections. Deadline guidance covers private-sector and state/local government workers; federal employees follow a separate process with a much shorter deadline (45 days to contact their agency's EEO counselor). Educational information, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| issue | No | Type of workplace issue, e.g. "discrimination", "harassment", "retaliation", "wrongful termination", "unpaid wages", "disability accommodation". | |
| state | No | US state (2-letter code or full name) to include state-specific protections and the correct EEOC filing deadline. | |
| protected_class | No | Protected characteristic involved, e.g. "race", "sex", "age", "disability", "religion", "national origin", "pregnancy". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions returning specific legal details (statutes, citations, filing deadlines, agencies, remedies) and includes the federal employee exception. Annotations already indicate readOnly and openWorld, which align with the description.
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?
The description is a single paragraph but efficiently packs essential information. It starts with the core purpose and progressively adds details, making it easy to scan.
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?
Given there is no output schema, the description comprehensively covers what the tool returns (relevant statutes, citations, coverage thresholds, deadlines, agencies, remedies) and includes important caveats (federal employee deadline, educational nature). All parameters are addressed.
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?
Although schema coverage is 100%, the description adds value by explaining how including a state triggers state-specific protections and correct EEOC deadline, and it contextualizes the parameters within the overall explanation.
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?
The description clearly states the tool's purpose: explaining federal and state employment laws based on issue and protected class. It specifies what is returned (statutes, citations, deadlines, remedies) and distinguishes itself from sibling tools like find_employment_attorney.
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?
The description explicitly says to 'Use this to ground an answer about a worker’s legal protections' and provides critical guidance on the difference between private-sector/state workers and federal employees regarding deadlines. It also clarifies the tool provides educational information, not legal advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_employment_attorneyFind an employment attorneyARead-onlyInspect
Find employment-law attorneys near a US location from a public directory of 9,800+ attorneys. Filter by specialization, language, minimum rating, free consultation, and contingency-fee availability. Returns attorneys with firm, city, contact info, rating, and experience, sorted by proximity. Use when a user wants to talk to a lawyer about their workplace situation.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Optional precise latitude. Overrides city/state when paired with lng. | |
| lng | No | Optional precise longitude. Overrides city/state when paired with lat. | |
| city | No | Optional city to tighten the search center (e.g. "Tampa"). | |
| limit | No | Max attorneys to return (1–25). | |
| state | No | US state — 2-letter code or full name (e.g. "FL" or "Florida"). Required unless lat/lng given. | |
| language | No | Filter to attorneys who speak this language, e.g. "Spanish". | |
| min_rating | No | Minimum star rating (0–5). | |
| radius_miles | No | Search radius. Defaults to 100mi for broad statewide coverage. | |
| contingency_fee | No | Only attorneys who work on contingency (no upfront fee). | |
| free_consultation | No | Only attorneys offering a free initial consultation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds transparency by detailing return fields (firm, city, contact info, rating, experience) and sorting by proximity, which goes beyond the annotations. No contradictions.
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?
The description is two sentences long, front-loaded with the main action, and every sentence adds value. No unnecessary words.
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?
The description adequately covers the tool's purpose, filters, and output for a straightforward search tool. However, it does not mention edge cases like empty results or pagination, which would make it more complete.
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 coverage is 100%, so the baseline is 3. The description mentions some filters (specialization, language, etc.) but does not add significant meaning beyond the already clear parameter descriptions in the schema.
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?
The description clearly states 'Find employment-law attorneys near a US location' with a specific verb and resource. It lists filtering options and return fields, distinguishing it from sibling tools like 'explain_my_rights' and 'find_similar_cases'.
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?
The description provides a clear usage cue: 'Use when a user wants to talk to a lawyer about their workplace situation.' However, it does not explicitly mention when not to use the tool or suggest alternatives, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_casesFind how similar cases were decidedARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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"]. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. The description adds behavioral transparency by detailing the specific outputs: win rate, settlement rate, damages range, factors, and example cases. It also clarifies that the tool provides educational statistics, not predictions or legal advice, which is valuable context beyond 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?
The description is concise, using only 3-4 sentences to convey purpose, outputs, and usage guidance. It is front-loaded with the core purpose, then lists return values and context. No redundant or extraneous sentences.
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 tool with 6 optional parameters, 100% schema coverage, and no output schema, the description adequately explains the tool's function and key outputs. It could optionally note that all parameters are optional, but the schema covers that. The description effectively sets expectations for result content, which is sufficient given the lack of output schema.
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 coverage is 100%, with each parameter described. The description adds meaning beyond the schema by naming 'claim_types' as the 'single highest-value signal', helping the agent prioritize. It also explains that 'employer_name' is used for fuzzy match, adding context not in schema.
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?
The description clearly states what the tool does: analyze similar real cases based on employment situation facts, returning aggregate statistics and representative examples. It uses specific verbs like 'analyze' and specifies the resource 'similar real cases in the corpus'. It distinguishes itself from siblings by calling itself 'the highest-value grounding tool' for certain questions.
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?
The description explicitly notes it is 'the highest-value grounding tool for 'what are my chances / what matters' questions', guiding when to use it. It lacks explicit 'when not to use' instructions but provides clear context and a disclaimer about educational purposes. Sibling tool names are listed, aiding differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_attorney_track_recordGet an employment attorney's case track recordARead-onlyInspect
Given an employment attorney name (or profile slug), return the federal employment-law cases on file in which that attorney appeared — case caption, court, year, nature-of-suit, and the side they appeared for when on record. Use this when a user names an attorney and wants their public litigation history. Facts only, sourced from federal court dockets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of example cases to return (1–25). Counts reflect all cases on file, not just these. | |
| attorney | Yes | Employment attorney full name (e.g. "Jane Doe") or their workers-rights.com profile slug. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds context: 'Facts only, sourced from federal court dockets' and specifies that only federal employment-law cases on file are returned, which aligns with openWorldHint. No contradiction.
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?
The description is compact (two sentences) and front-loaded with the core purpose. Every sentence adds value without redundancy.
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?
The description lists all returned fields and sets scope (federal employment-law cases). With no output schema, this is helpful. It could mention limit/pagination behavior, but the schema covers the limit parameter. Overall fairly complete given annotations and sibling context.
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?
Both parameters (attorney and limit) are fully described in the input schema (100% coverage). The tool description reinforces that attorney can be a name or slug but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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?
The description uses a specific verb ('return') and resource ('federal employment-law cases') and lists the fields returned (case caption, court, year, nature-of-suit, side). It clearly distinguishes from sibling tools like get_employer_track_record and find_employment_attorney.
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: 'when a user names an attorney and wants their public litigation history.' It implies the context relative to siblings but does not explicitly state when not to use (e.g., for general attorney info, use find_employment_attorney).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_corpus_statsGet corpus size and freshnessARead-onlyInspect
Return live statistics about the Workers' Rights corpus: total number of employment-law court rulings, number of attorneys in the directory, number of monitored legal data sources, the date the corpus was last updated, and the distribution of case outcomes across the analyzed rulings. Use this to establish scale/credibility or to answer 'how much data do you have / how current is it'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and destructiveHint=false, so the description doesn't need to re-state safety. The description adds value by listing exactly what statistics are returned and their live nature, which is moderate additional context.
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?
The description is extremely concise: two sentences that front-load the purpose and provide usage guidance. No wasted words, and every part serves a clear function.
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 stat retrieval tool with no parameters and no output schema, the description is complete. It enumerates all return values (rulings, attorneys, sources, update date, outcome distribution) and provides context for when to use it.
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?
There are zero parameters, so the schema is fully covered. The description adds no parameter info because none is needed. Baseline score of 4 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?
The description clearly states the tool returns 'live statistics about the Workers' Rights corpus' and lists specific data points (total rulings, attorneys, sources, date, outcome distribution). This differentiates it from sibling tools like 'search_rulings' or 'get_attorney_track_record' which serve different purposes.
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?
The description explicitly tells the agent when to use the tool: 'establish scale/credibility or to answer how much data do you have / how current is it'. While it doesn't say when not to use it, the context is clear because the tool is purely informational and read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eeoc_processExplain the EEOC charge processARead-onlyInspect
Plain-English guide to the 9 stages of an EEOC discrimination/retaliation charge, from pre-filing through resolution. Call with no arguments for an overview of all stages with typical durations; call with a stage number (1-9) for a deep-dive on that stage: what to expect, how long it takes, the key tip, and do/don't guidance. Use this whenever someone asks what happens after filing with the EEOC, how long the process takes, what a position statement or rebuttal is, or what to do at the stage they are currently in. Covers private-sector and state/local government workers; federal employees follow a separate EEO process with a much shorter deadline (45 days to contact their agency's EEO counselor).
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Stage number 1-9 for a deep-dive on one stage. Omit for an overview of all nine stages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive behavior. The description adds behavioral context: coverage scope (private-sector, state/local) and the exception for federal employees. No contradictions.
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?
Single, well-structured paragraph. Front-loaded with purpose, followed by usage instructions, and ends with an important exclusion. Every sentence is necessary and informative, no wasted words.
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?
With only one optional parameter and no output schema, the description fully explains what to expect (stages overview or deep-dive content). It covers topics, durations, and the key exclusion. No gaps remain.
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 coverage is 100% with a description for the 'stage' parameter. The description adds significant context: omitting stage gives an overview, providing a number (1-9) yields a stage deep-dive with specific details. This far exceeds the schema baseline.
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?
The description clearly defines the tool as a 'Plain-English guide to the 9 stages of an EEOC discrimination/retaliation charge,' specifying both overview and deep-dive modes. It distinguishes from sibling tools by focusing on process steps, not rights explanations or attorney referrals.
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: when someone asks about EEOC process steps, timelines, or specific stage details. Also provides an important exclusion: federal employees follow a separate process, guiding the agent away from misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_employer_track_recordGet an employer's litigation track recordARead-onlyInspect
Given an employer/company name, return how many employment-law rulings in the corpus involve that employer, the breakdown of outcomes (employee wins, employer wins, settlements, dismissals), the most notable recent cases, AND the count of federal docket filings on record (active/filed cases that may not have a written opinion yet). Use this when a user names their employer and wants that company's litigation history + footprint.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of example cases to return (1–25). The total count and outcome breakdown reflect the full corpus, not just these examples. | |
| employer | Yes | Employer/company name to look up, e.g. "Walmart", "Acme Corporation". Common suffixes like Inc/Corp/LLC are ignored when matching. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds specifics: returns notable cases and docket filings, going beyond annotations without contradiction.
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 well-structured sentences, front-loaded with the tool's output, no redundant 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?
Despite no output schema, the description covers all key outputs (cases, breakdown, docket filings). Two parameters are fully explained, making the tool's functionality clear.
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 coverage is 100%, and description adds meaningful context: limit affects example count only, employer matching ignores suffixes, clarifying behavior beyond the schema.
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?
The description clearly states the tool returns employer litigation history including counts, outcome breakdown, notable cases, and docket filings, distinguishing it from siblings like get_attorney_track_record.
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?
The description advises when to use: when a user names their employer. It lacks explicit when-not-to-use or alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_evidence_preservation_checklistEvidence preservation checklist (before losing access)ARead-onlyInspect
Concrete checklist for a worker who senses termination coming or is in a deteriorating work situation: what to save (emails, chat DMs, performance reviews, HR records, pay records), in what order, and how to do it without crossing lines — preserving your own employment record is legal; taking company IP is not. Use this whenever someone says they think they are about to be fired, fears retaliation is escalating, mentions a PIP or sudden access changes, or asks what to do before reporting discrimination. Sections: 'today' (highest-leverage, minutes matter), 'this-week', 'quiet' (low-priority prep). Time-sensitive — employers often revoke system access during the termination call itself.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Checklist section for a focused list: 'today' (highest-leverage, do first), 'this-week', or 'quiet' (lower-priority quiet prep). Omit for the full checklist. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, openWorldHint, and non-destructive. The description adds behavioral context: time-sensitive, legal/ethical boundaries, and sections prioritized. No contradiction with 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?
Description is detailed but well-structured, front-loaded with purpose and usage scenarios. Slightly verbose but each sentence adds context; a minor trim could improve conciseness.
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 simple checklist tool with one optional parameter, the description fully covers functionality, usage, and limitations. No output schema needed as return is implied.
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 covers the single enum parameter completely. The description adds value by explaining the priority of each section ('today' highest-leverage, etc.), which aids selection beyond schema.
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?
The description clearly states the tool provides a concrete checklist for preserving evidence before losing access, specifying what to save, in what order, and legal boundaries. It distinguishes itself from sibling tools by focusing on practical preservation steps.
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 enumerates when to use: termination suspicion, deteriorating work situation, PIP, sudden access changes, or before reporting discrimination. It also implies when not to use (taking company IP is not recommended), providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rulingsSearch employment-law rulingsARead-onlyInspect
Search 140,000+ U.S. employment-law court rulings by keyword, law, court, federal circuit, state, outcome, and date. Returns real cases with citations, outcomes, case stage, employers, claim types, damages, and links to the full opinion. Use this to ground any claim about how employment cases have been decided. Results are quality-filtered (low-confidence and junk rows excluded).
| Name | Required | Description | Default |
|---|---|---|---|
| law | No | Filter by a related law id, e.g. "title-vii", "adea", "ada", "fmla", "flsa". | |
| court | No | Filter by CourtListener court id, e.g. "scotus", "ca11" (11th Circuit). | |
| limit | No | Max rulings to return (1–25). | |
| query | No | Free-text search across case name and opinion snippet (e.g. "pregnancy discrimination retaliation"). | |
| state | No | Two-letter US state code the case was filed in, e.g. "FL", "CA". | |
| circuit | No | Filter to a federal appeals circuit (the appeals court plus its district courts). Preferred values: first-circuit, second-circuit, third-circuit, fourth-circuit, fifth-circuit, sixth-circuit, seventh-circuit, eighth-circuit, ninth-circuit, tenth-circuit, eleventh-circuit, dc-circuit, federal-circuit. Display forms like "Eleventh Circuit" or "11th" are also accepted. | |
| date_to | No | Latest filing date (YYYY-MM-DD). | |
| outcome | No | Filter to a specific case outcome. | |
| date_from | No | Earliest filing date (YYYY-MM-DD). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses quality filtering (exclusion of low-confidence and junk rows), which adds behavioral context beyond the annotations (readOnlyHint, destructiveHint). No contradictions with 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?
Two sentences: the first concisely lists capabilities and filters, the second states usage guidance, the third adds quality filter. Every sentence adds value; no fluff.
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 search tool with 9 parameters and no output schema, the description covers purpose, filtering dimensions, return contents (citations, outcomes, etc.), and quality filtering. Missing pagination/ordering details, but still comprehensive.
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 coverage is 100%, so the schema fully documents parameters. The description does not add extra meaning beyond enumerating filter types (keyword, law, court, etc.) and briefly mentioning return contents, but it does not deepen understanding of individual parameters.
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?
The description clearly states the tool searches 140,000+ U.S. employment-law court rulings by multiple filters (keyword, law, court, circuit, state, outcome, date). It uses a specific verb and resource, distinguishing it from sibling tools like find_employment_attorney.
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?
The description explicitly says 'Use this to ground any claim about how employment cases have been decided,' providing clear context for when to use. It does not mention exclusions or alternatives, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!