Read-only employment-law research: 140K+ rulings, employer track records, rights & EEOC guides.
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.
Average 4.6/5 across 9 of 9 tools scored.
Each tool targets a distinct resource and action: rights explanation, attorney search, case similarity, attorney/employer records, corpus stats, EEOC process, evidence checklist, and ruling search. The two track-record tools are clearly separated by subject (attorney vs employer), and find_similar_cases differs from search_rulings in purpose and output.
All tool names follow a consistent verb_noun pattern with imperative verbs (explain, find, get, search) and descriptive noun phrases. The variation in verbs is minor and maintains a predictable structure, with no mixed casing or inconsistent styles.
Nine tools is well within the ideal 3-15 range and appropriately scoped for the workers' rights domain. Each tool occupies a distinct niche, from educational resources to litigation research, without unnecessary redundancy.
The toolset covers the core worker journey: understanding rights, preserving evidence, navigating EEOC process, researching case law, and finding attorneys. Minor gaps exist (e.g., no dedicated federal-employee-specific workflow or document drafting tool), but agents can work around these using existing tools.
explain_my_rightsExplain applicable employment-law rightsAExplain 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". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true. Description adds context about return content, scope limitations, and the educational nature, which are useful beyond the annotations. 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?
Description is a single paragraph without wasted words, front-loading the purpose. Could be slightly more structured (e.g., bullet points), but it's concise and informative.
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 thoroughly explains return values: statutes, citations, employer thresholds, deadlines, agencies, remedies. Also addresses scope and limitations for federal employees. No gaps for a knowledge-base tool.
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 clear parameter descriptions. Description adds value by explaining what the tool returns for each parameter combination, including caveats about federal employee deadlines. Baseline 3, elevated for added context.
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 states exactly what the tool does: explain applicable federal (and optionally state) employment laws based on issue and/or protected class. Differentiates from sibling tools like find_employment_attorney or find_similar_cases by focusing on legal rights explanation.
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 says 'Use this to ground an answer about a worker’s legal protections' and notes scope (private-sector, state/local government vs. federal employees). Also clarifies it's educational, not legal advice. Lacks explicit when-not-to-use but is clear enough.
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 attorneyAFind employment-law attorneys near a US location from a public directory of 9,500+ attorneys. Returns source-attributed identity, firm, location, and contact data sorted by proximity. Person-specific filters and fields apply only where the underlying directory supports them; Google Places metrics are labeled as firm/office listing data, never individual ratings.
| 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 source-supported attorney language data; Google office listings are excluded. | |
| min_rating | No | Minimum individual-profile rating; Google office ratings are excluded. | |
| radius_miles | No | Search radius. Defaults to 100mi for broad statewide coverage. | |
| contingency_fee | No | Filter source-supported attorney fee data; Google office listings are excluded. | |
| free_consultation | No | Filter source-supported attorney fee data; Google office listings are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it notes that 'person-specific filters and fields apply only where the underlying directory supports them' and that 'Google Places metrics are labeled as firm/office listing data, never individual ratings.' These caveats clarify data reliability and source attribution, complementing the readOnlyHint and openWorldHint 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?
The description is compact and well-structured: three sentences covering purpose, return data, and key caveats. It front-loads the core function and avoids redundancy, making every sentence informative.
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 10 optional parameters and no output schema, the description provides a solid summary of return categories (identity, firm, location, contact) and proximity sorting. It also addresses data limitations, though it does not enumerate all output fields or pagination details. The openWorldHint and schema descriptions fill remaining gaps, making the tool adequately contextualized.
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?
The schema already provides 100% description coverage for all parameters, so the baseline is 3. The description adds value by explaining that filters such as language, min_rating, and fee-related parameters are conditional on directory support, and that Google office ratings are excluded. This helps agents understand when parameters may be ignored, exceeding the schema's per-parameter descriptions.
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: 'Find employment-law attorneys near a US location from a public directory of 9,500+ attorneys.' It specifies the verb (Find), resource (employment-law attorneys), and scope (near a US location), and distinctly differentiates from siblings like find_similar_cases or explain_my_rights by focusing on attorney discovery.
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 implies a clear use case—locating employment attorneys by proximity—and provides context about the directory and sorting. It does not explicitly mention alternatives or when not to use the tool, but the purpose is sufficiently distinct from sibling tools that a user can infer when it applies.
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 decidedAGiven 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"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. The description adds valuable context about return values and educational nature, with 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 concise (4 sentences) and well-structured: purpose, returns, value, caveat. 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?
Despite no output schema, the description fully enumerates all return values (win rate, settlement rate, damages, factors, examples) and includes an educational disclaimer.
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%, baseline is 3. The description mentions some parameters but does not add meaning beyond the schema descriptions.
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: analyze similar employment cases and return aggregate statistics and examples. It uses specific verbs and distinguishes itself as 'the highest-value grounding tool' for assessing chances.
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 clear context for use ('what are my chances / what matters' questions) and includes a caveat about educational use. However, it does not explicitly state when not to use or offer alternatives among siblings.
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 recordAGiven 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. Attorney identities are algorithmically matched; ambiguous and lower-confidence matches are excluded.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is set. The description adds important behavioral context: data is 'sourced from federal court dockets,' matches are 'algorithmically matched,' and 'ambiguous and lower-confidence matches are excluded,' which tells the agent about potential incompleteness and data provenance. This goes 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?
Three sentences, each with distinct value: return information, usage context, and data caveats. 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 2-parameter read-only tool with no output schema, the description covers input formats, output fields, data source, confidence filter, and usage context. The limit parameter's behavior is documented in the schema, and the description's listing of return fields compensates for the missing 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?
Both parameters are described in the schema with 100% coverage, so the bar is high. The description reinforces that 'attorney' accepts either a full name or a profile slug, but does not add new semantics beyond the schema's existing descriptions. 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 opens with a specific verb-resource pairing: 'Given an employment attorney name (or profile slug), return the federal employment-law cases...' and enumerates exact output fields. It clearly distinguishes from sibling get_employer_track_record by targeting attorneys, so purpose is unambiguous.
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?
It explicitly states 'Use this when a user names an attorney and wants their public litigation history,' which tells the agent when to invoke it. It does not name alternative tools, but the when-condition is clear and the sibling set makes the distinction implicit.
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 freshnessAReturn 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds value by detailing the exact contents of the live statistics, such as case outcome distribution, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description is front-loaded with the action and purpose. Every sentence is informative with 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 zero parameters and no output schema, the description fully covers what the tool does, what it returns, and why it would be used. Annotations fill in safety 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?
No parameters, so baseline 4 applies. Description does not need to add parameter info.
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 it returns live statistics about the Workers' Rights corpus, enumerating specific fields (total rulings, attorneys, sources, update date, outcome distribution). This distinguishes it from siblings like search_rulings or 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?
Explicitly advises using this tool to 'establish scale/credibility' or answer queries about data quantity and currency, providing clear contextual guidance for when to invoke it.
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 processAPlain-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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it returns an overview for no arguments or a deep-dive for a stage number, covers private-sector and state/local workers, and explicitly mentions the federal employee exception. 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?
The description is moderately long but front-loads the core purpose. Every sentence contributes information about usage, scope, or output. Slightly verbose but clear and well-organized.
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 no output schema, the description adequately describes what the tool returns: an overview with stages and durations for no arguments, and a deep-dive with expectations, timing, tips, and do/don't for a stage argument. It also clarifies the scope (private-sector/state-local) and notes the federal exception, making it complete for the tool's complexity.
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 the input schema provides a parameter 'stage' with a description, the description adds significant meaning: it explains that omitting the parameter yields an overview, while providing a stage (1-9) gives a deep-dive with specific details (duration, key tip, do/don't). This goes well beyond the schema's minimal description.
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 identifies the tool as a plain-English guide to the 9 stages of an EEOC charge process. It specifies the verb 'guides' and the resource 'EEOC charge process', and it implicitly distinguishes from sibling tools like 'explain_my_rights' by focusing on procedural stages.
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 states when to use: 'whenever someone asks what happens after filing with the EEOC...'. It also provides exclusion context by noting that federal employees follow a separate process, and it differentiates the tool's behavior with and without the stage argument.
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 recordAGiven 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, destructiveHint) are present and consistent. The description adds behavioral details beyond annotations, such as returning federal docket filings and notable cases. 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 a single paragraph that is clear and front-loaded with the main purpose. It is concise without being terse, though it could be slightly more streamlined.
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 the tool has 2 parameters, full schema coverage, and no output schema, the description adequately explains the return values (rulings count, breakdown, cases, docket filings). It also references sibling tools implicitly, providing sufficient context for an AI agent.
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 description coverage is 100%, and both parameters have clear descriptions in the schema. The tool description lists the return values but does not add additional semantic meaning for the parameters 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 explicitly states the verb (return) and resource (employer's track record), and lists specific elements: rulings count, outcome breakdown, notable cases, and docket filings. It clearly distinguishes from sibling tool 'get_attorney_track_record' which is for attorneys.
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 includes a direct guidance: 'Use this when a user names their employer and wants that company's litigation history + footprint.' It implies the context and contrasts with sibling tools, but does not explicitly state when not to use it.
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)AConcrete 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by explaining the checklist is time-sensitive, includes legal boundaries (preserving employment record is legal, taking company IP is not), and sections have priorities. Does not contradict 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?
Well-structured with clear front-loading of purpose, then use cases, then sections. Every sentence adds value without redundancy. Length is appropriate for the complexity.
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?
No output schema, but the description explains what the checklist contains (sections, order, legal boundaries) sufficiently. Covers all necessary context for an agent to use the tool correctly.
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 enum descriptions. The description enhances the 'group' parameter by adding context: 'today' is highest-leverage minutes matter, 'quiet' is low-priority prep. This adds meaning beyond the bare 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 it provides a 'concrete checklist' for workers anticipating termination, specifying what to save and in what order. It distinguishes from sibling tools like 'explain_my_rights' or '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 lists use cases: 'when someone says they think they are about to be fired, fears retaliation, PIP, access changes, before reporting discrimination'. Provides clear when-to-use guidance without needing exclusions.
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 rulingsASearch a 140,000+ U.S. court-ruling research corpus 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the annotations (readOnlyHint=true, destructiveHint=false) already communicate safety, the description adds valuable behavioral context: it lists the fields returned (citations, outcomes, case stage, damages, links) and warns that results are quality-filtered ('low-confidence and junk rows excluded'). This transparency is not present in the annotations or schema.
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?
Three sentences, each earning its place: first states the core action and scope, second lists return fields, third provides a usage directive and data-quality caveat. No fluff, front-loaded with the most important 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?
With 9 parameters, no output schema, and moderate complexity, the description covers the essential return fields and quality filtering, which helps set expectations. It could mention default sorting or pagination, but those are not critical for high-level selection. The annotations fill in the safety profile, making this sufficiently 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 description coverage is 100%, so the baseline is 3. The description briefly echoes the filter dimensions (keyword, law, court, circuit, state, outcome, date) but does not add syntax, format, or precedence details beyond what the schema already provides. It adequately summarizes without needing to compensate.
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 opens with 'Search a 140,000+ U.S. court-ruling research corpus' — a specific verb and resource that clearly distinguishes this from sibling tools like find_similar_cases or get_corpus_stats. It enumerates filter dimensions and return fields, leaving no ambiguity about the tool's function.
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?
It includes a direct usage directive: 'Use this to ground any claim about how employment cases have been decided,' which tells the agent when to invoke this tool. It does not explicitly name alternatives or state exclusions, but the context is clear enough for typical decision-making.
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.
No comments yet. Be the first to start the discussion!
