employment-law

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 that the tool returns educational information, not legal advice, and specifies the scope (federal and state laws). 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 three sentences, front-loaded with the core functionality, and every sentence adds value. No redundancy or unnecessary detail.

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 3 optional parameters, no output schema, and comprehensive annotations, the description covers inputs, outputs, and important caveats (educational disclaimer). It is complete for an information-retrieval tool of this 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?

Schema description coverage is 100% with clear parameter descriptions. The tool description adds context by explaining the role of each parameter (e.g., 'if a state is given' for state parameter) and integrating them into the overall purpose, going slightly 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 it explains applicable employment-law rights and lists specific outputs (statutes, citations, coverage, deadlines, agencies, remedies). It distinguishes itself from sibling tools like find_employment_attorney and find_similar_cases by focusing on legal explanation rather than attorney search or case lookup.

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 directs use to 'ground an answer about a worker’s legal protections' and notes it's educational, not legal advice. It implies when to use but does not explicitly state when not to use or compare to alternatives, though siblings are different 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?

Annotations indicate read-only, open-world, non-destructive behavior. The description adds value by specifying the directory size (9,800+), that results are sorted by proximity, and that attorneys are 'verified'. These details supplement the annotations without contradicting them.

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 covering purpose, filters, return info, and usage guidance. Every sentence is necessary and free of redundancies. It is front-loaded with the core action.

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 explains return fields (firm, city, contact info, rating, experience, sorted by proximity). All 10 parameters have schema descriptions. For a read-only search tool, this is complete and sufficient for an agent to select and invoke 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 description coverage is 100%, so baseline is 3. The description lists general filter categories (specialization, language, rating, consultation, contingency) but does not add details beyond the schema's parameter descriptions. It provides a helpful overview but does not add new 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 clearly states the verb 'Find' and the resource 'employment-law attorneys', specifying the directory size (9,800+) and location requirement (US location). It distinguishes from siblings like 'explain_my_rights' and 'find_similar_cases' by focusing on finding a lawyer, not legal information or case 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 includes an explicit usage statement: 'Use when a user wants to talk to a lawyer about their workplace situation.' This provides clear context. However, it does not explicitly mention when not to use it or direct to alternative tools among siblings, though the sibling names imply alternatives.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds context by explaining it returns aggregate statistics and example cases, and that it's educational. 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 with three sentences: first states functionality, second states output, third provides use case and 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?

The description thoroughly covers the tool's output (win rate, settlement rate, damages, factors, examples) and its educational nature. While no output schema exists, the description provides sufficient context for an agent to understand 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?

All 6 parameters have full descriptions in the schema (100% coverage). The tool description does not add additional meaning to individual parameters beyond the schema's descriptions, so baseline 3 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 analyzes similar cases based on employment facts and returns aggregate statistics. It distinguishes itself from siblings like search_rulings by being the 'highest-value grounding tool for what are my chances' 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?

Explicitly positions the tool for 'what are my chances / what matters' questions and includes a caveat that it's educational, not prediction or legal advice. However, it does not explicitly state when not to use it or name alternative tools.

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 mark readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds behavioral specifics: it returns 'live statistics' and enumerates the exact data fields, which is helpful 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?

Two sentences: the first explains what the tool returns, the second gives usage examples. No wasted words, front-loaded with key 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?

Given zero parameters and no output schema, the description fully describes the return value with specific fields. It provides complete context for an agent to understand what this tool does and when to invoke 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?

The input schema has zero parameters, making the description's parameter coverage irrelevant. Per guidelines, 0 parameters gives a baseline of 4.

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 verb 'Return' and specifics: 'live statistics about the Workers' Rights corpus' followed by enumerated items (court rulings, attorneys, data sources, last updated date, case outcome distribution). This distinguishes it from sibling tools like search_rulings 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?

The description explicitly provides usage context: 'Use this to establish scale/credibility or to answer 'how much data do you have / how current is it'. This gives clear when-to-use guidance, though it does not explicitly state when not to use or name alternative tools.

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 mark the tool as readOnly, non-destructive, and open-world. The description adds behavioral details: it provides a guide with typical durations, key tips, and do/don't guidance, which is consistent with annotations and adds value beyond structured fields.

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 concise sentences that front-load the purpose and immediately explain usage. Every sentence is necessary and information-dense with 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?

The description covers the main user queries (overview and deep-dive) and addresses common questions like duration and guidance. While no output schema is provided, the description sufficiently explains what to expect from the response. Minor gap: does not mention return format, but acceptable for a guide 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% for the single parameter, and the schema description already explains omit for overview vs. provide stage number. The description adds extra semantics by detailing what a deep-dive includes (expectations, duration, tips, guidance), going 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 is a plain-English guide to the 9 stages of an EEOC charge, distinguishing it from sibling tools that cover rights, attorney finding, or case searches. The verb 'explain' and resource 'EEOC charge process' are specific and 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?

The description explicitly tells when to use this tool (when someone asks about the EEOC process, duration, etc.) and how to invoke it (no arguments for overview, stage number for deep-dive). It does not explicitly mention when not to use it or what alternatives to consider, but the user context provides sibling tools for differentiation.

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?

The description adds context about the tool's output (breakdown, notable cases) beyond the annotations (readOnlyHint, openWorldHint, destructiveHint). However, it does not disclose any additional behavioral traits such as rate limits, authentication requirements, or error handling, which would enhance transparency.

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, each earning its place: the first states the tool's purpose, the second gives usage guidance. It is front-loaded with the key information, no 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's moderate complexity (2 required parameters, no output schema, annotations present), the description covers the core functionality and usage context. It does not address edge cases (e.g., employer not found) but is sufficient for an agent to invoke 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 both parameters described. The description adds value by clarifying that the limit parameter affects only example cases while the total count reflects the full corpus, and that common suffixes are ignored for the employer parameter. This goes beyond the schema's basic 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 verb 'return' and the resource 'litigation track record' with specific details about what is included (number of rulings, outcome breakdown, notable cases). It distinguishes from siblings like 'search_rulings' and 'get_corpus_stats' by focusing on a specific employer.

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 this tool ('when a user names their employer and wants to know that company's litigation history'). While it does not mention when not to use it or list alternatives, the context signals from sibling tools imply scenarios where other tools would be more appropriate.

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 indicate read-only and non-destructive. Description adds that results are quality-filtered (low-confidence/junk excluded), which is important 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?

Four concise sentences, front-loaded with purpose, then return types, usage guidance, and quality note. 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?

Covers purpose, return data, usage, and quality. Could mention pagination or rate limits, but for a search tool with required limit param, it is adequately 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% with detailed descriptions. Description lists filterable fields but adds no new semantic meaning beyond what the schema provides. 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 clearly states it searches employment-law court rulings by multiple filters, and the verb 'search' is specific. It distinguishes from siblings like find_similar_cases and get_corpus_stats.

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?

Provides explicit guidance to 'use this to ground any claim about how employment cases have been decided.' Context implies when to use, but does not explicitly state alternatives or when not to use.

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