Workers' Rights

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.

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

Beyond the readOnly/openWorld annotations, the description discloses important behavioral caveats: data is public-source and source-attributed, results are proximity-sorted, person-specific filters only apply where directories support them, and Google Places metrics are never presented as individual attorney ratings. This gives strong transparency about data limitations and filtering behavior.

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: the first states the core purpose, the second summarizes return data and ordering, and the third clarifies limitations and disclaimers. The most important information is front-loaded and there is no redundant filler.

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 adequately summarizes the return content as source-attributed identity, firm, location, and contact data sorted by proximity. It also covers key behavioral edge cases like unsupported person-specific filters and rating-source labeling. Minor gaps remain around exact response structure or error handling, but schema parameter descriptions fill much of the remaining 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?

The schema already documents all 10 parameters with detailed descriptions, so the baseline is 3. The description adds useful cross-parameter meaning by clarifying that person-specific filters depend on underlying directory support and that office/listing ratings are distinct from individual attorney ratings, which directly informs how min_rating and other profile-specific filters behave.

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 action and resource: finding public-source employment-law attorney listings near a US location. It clearly distinguishes this tool from the legal-information and research siblings by focusing on location-based attorney contact listings rather than rights explanations, case research, or track records.

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 makes the use case explicit: use this to find employment-law attorney listings near a US location. It also provides a clear exclusion by stating listings are not state-bar verification or an endorsement, which helps agents avoid overclaiming the tool's authority.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context about data sourcing (federal dockets), matching logic (algorithmic, lower-confidence excluded), and output normalization (one case = one court+docket). It stops short of explaining return shape details or edge cases like empty results, but for a read-only fact-lookup tool, this is well covered.

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?

Four focused sentences that pack in purpose, usage, data provenance, and edge-case handling. No wasted words and all information is directly relevant to an agent deciding to call the tool.

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 simple parameter set and the presence of readOnlyHint/openWorldHint annotations, the description is complete. It tells an agent what data will come back (cases with specific fields) and how to interpret the count, which is all that is needed for a straightforward lookup 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 description coverage is 100%, so both parameters are fully documented. The description reinforces the semantics of 'attorney' by mentioning it can be a name or slug and clarifies that the 'limit' parameter only applies to example cases, not counts. These are helpful nudges but don't add deeply 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 what the tool does: given an attorney name or profile slug, it returns federal employment-law cases with caption, court, year, nature-of-suit, and side represented. It distinctly differentiates from sibling tools like get_employer_track_record by focusing on 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?

Explicitly instructs when to use the tool ('when a user names an attorney and wants their public litigation history') and explains the behavioral boundaries (federal cases only, algorithmic matching, exclusion of ambiguous matches). Though it doesn't name an alternative tool, the use case is so specific that an agent can easily tell when this tool applies versus when it doesn't.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds transparency about the 'live' nature of the statistics, implying real-time data rather than cached figures, and lists the specific fields returned, which is useful behavioral context beyond the 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 a single, information-dense sentence followed by a concise usage note. It front-loads the action and immediately enumerates the specific statistics, with no filler or 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?

Given the tool has no parameters and no output schema, the description fully compensates by enumerating the exact return statistics (total rulings, attorney listings, monitored sources, last update, outcome distribution). The stated use cases round out the contextual picture, making this complete for its simplicity.

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 tool has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters. Per the guidelines, a no-parameter tool gets a baseline of 4, and the description adds no conflicting or redundant information.

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 live statistics' and enumerates the exact data points returned (court rulings, attorney listings, legal data sources, last updated date, case outcome distribution). This clearly distinguishes it from sibling tools like search_rulings or find_similar_cases, none of which provide corpus-level metrics.

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 it: 'Use this to establish scale/credibility or to answer "how much data do you have / how current is it"'. It does not explicitly state when not to use it or name alternatives, but the use cases are clear and contextually sufficient.

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

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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds behavioral context by specifying the scope (federal cases, published opinions) and the inclusion of docket records without written opinions, which goes beyond the annotations. This extra context about data coverage earns a 4.

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, information-dense sentence followed by a short usage directive. It is front-loaded with the primary purpose and includes no filler, but the long enumerations make it somewhat dense; it is reasonably concise for the tool's 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?

With no output schema, the description carries the responsibility of explaining returns, and it does so by enumerating the key components: cases, opinions, outcome breakdown, notable opinions, and docket count. It also clarifies the distinction between published opinions and docket records. It is sufficiently complete for an agent to know what to expect.

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 input schema provides thorough descriptions for both parameters, including the note that limit affects only example opinions, not totals, giving 100% coverage. The tool description does not add further parameter-specific meaning, so a baseline of 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 the specific verb 'return' and names the resource ('employer/company name') plus the specific outputs: distinct federal cases, opinions, outcome breakdown, notable opinions, and docket count. It distinguishes from sibling tools like get_attorney_track_record by focusing on the employer's track record. This is a clear purpose.

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 an explicit usage statement: 'Use this when a user names their employer and wants that company's litigation history + footprint.' This gives clear context, though it does not name alternatives or negative conditions, so it earns a 4 rather than a 5.

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

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.

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

Annotations already cover read-only and non-destructive behavior. The description adds value by describing the return content ('citations, outcomes, procedural stage, employers, claim types, damages, and links to the full opinion') and the quality-filtering behavior ('low-confidence and junk rows excluded'). It does not mention pagination or rate limits, but the given context is sufficient for a read-only search tool.

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 three sentences, front-loaded with the action and scope, then return payload, then use case and quality filter. Every sentence earns its place; there is no fluff or repetition of schema details.

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 optional parameters and no output schema, the description fully compensates by enumerating the return fields, stating the corpus size, quality filtering, and the grounding use case. The annotation openWorldHint is consistent with a live research corpus, and the description leaves no critical ambiguity about what the tool returns or 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?

Schema description coverage is 100%, so the baseline is 3. The description summarizes the main search dimensions (keyword, law, court, circuit, state, outcome, date) but adds no semantic depth beyond what the schema already provides via examples and descriptions. The 'keyword' and 'federal circuit' phrases map directly to existing properties without expanding their meaning.

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 and resource: 'Search a 140,000+ U.S. court-ruling research corpus by keyword, law, court, federal circuit, state, outcome, and date.' It also states the return payload ('published opinions with citations, outcomes, procedural stage, employers, claim types, damages, and links to the full opinion') and explicitly distinguishes its grounding purpose from sibling tools with 'Use this to ground any claim about how employment cases have been decided.'

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 gives an explicit use case: 'Use this to ground any claim about how employment cases have been decided.' This tells the agent when to choose this tool (for evidence about case outcomes) and implies it is the primary research tool for rulings. However, it does not explicitly name alternatives or exclusions, so it falls short of a 5.

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