Server Quality Checklist

Tool Scores

• get_review_analyticsB
  3.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It adds valuable detail by enumerating returned metrics (frequency trends, freshness score, momentum indicators, etc.), revealing output behavior. However, it does not mention whether authentication is required, whether data is cached, or any potential side effects, though as a read-only analytics tool the risk is low.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: a clear purpose statement followed by a list of included metrics. Every item in the list is relevant and informative, with no filler. It loses one point because the list is somewhat long, but still highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple input (one required parameter) and absence of an output schema, the description does a good job of setting expectations by listing the analytics components. It could be more complete by noting conditions like 'attorney must have reviews' or how the time series is structured, but it is sufficient for an agent to decide whether this tool fits the user's need.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides a thorough description of the single `slug` parameter with a concrete example ('levine-law-llc-denver'). Since schema description coverage is 100%, the baseline is 3 even though the tool description adds no additional parameter information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get review velocity analytics for a specific attorney.' It names a specific resource and lists a comprehensive set of included metrics, making the purpose distinct from generic review lookups. However, it does not explicitly differentiate from sibling tools like get_review_intelligence, so it misses the top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus alternatives such as get_review_intelligence or get_attorney_reviews. The description implies usage for review analytics but provides no exclusions, prerequisites, or alternative tool references, leaving the agent without decision support.

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

• get_review_intelligenceA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. While the 'Get' verb implies a read operation, the description does not explicitly state whether the tool is read-only, requires any permissions, or has side effects. It also does not disclose how the response is structured beyond listing components, which is a gap for a tool with no output schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first front-loads the purpose, the second concisely lists the return components. Every sentence provides value, and there is no filler or repetition of schema information. It is appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, so the description must convey what the agent will receive. It lists the high-level categories (pain points, distribution, trust signals, etc.) but does not explain their structure or semantics (e.g., what the 12 dimensions are, how distribution is represented). For a complex AI-derived output, more detail would improve completeness, but the description is minimally adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%: the only parameter (firm_slug) is fully described as a canonical slug from search_attorneys. The description adds no additional meaning about the parameter, so it reaches the baseline of 3. There is no need for the description to compensate for schema gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: to get AI-analyzed review intelligence for a law firm. It enumerates the specific outputs (praise/complaint summaries, 12 pain point dimensions, case type distribution, etc.), which distinguishes it from sibling tools like get_attorney_reviews or get_review_analytics. The verb 'Get' and the resource 'review intelligence' 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when one needs synthesized review intelligence rather than raw reviews or analytics, but it does not explicitly state when to use this tool versus alternatives like get_review_analytics or compare_review_intelligence. There is no exclusion or direct comparison to siblings, so the guidance is only implied by the output list.

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

• get_attorney_reviewsA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses that results are paginated and includes a list of response contents (review text, rating, reviewer name, date, rating distribution breakdown), which is useful. However, it omits details like sorting order, error handling, or authentication requirements, so it is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that front-loads the primary action and includes key details about pagination and return fields. There is no redundant information or fluff, earning a perfect score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  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 appropriately lists the main fields returned. While it lacks details on pagination structure (e.g., total count, next page tokens) and sorting, it is sufficient for a straightforward read-only listing tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with all three parameters described. The description adds minimal value beyond the schema by mentioning pagination and a specific attorney, which align with existing param descriptions. It does not introduce new syntax or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('client reviews for a specific attorney'), clearly stating the tool's function. It distinguishes itself from siblings like search_attorney_reviews by emphasizing the specific attorney scope, even without explicitly naming alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of when to prefer this over search_attorney_reviews or get_review_analytics, nor any exclusion or prerequisite information.

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

• search_crashesA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It discloses the database size (500,000+ records) and that it returns key fields (location, date, severity, injuries, fatalities, contributing factors), giving some transparency about scope and output. However, it does not disclose pagination behavior, default ordering, data freshness, or any limitations beyond the implied read-only nature of a search. It neither contradicts nor enriches beyond basic function, so a mid-range score is appropriate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary purpose in the first few words, and each sentence adds distinct value: the first defines the search scope, the second provides context on data magnitude and return fields. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only search tool with six well-documented schema parameters and no output schema, the description provides a solid overview: it covers the search dimensions, dataset scale, and return fields. It falls short only in not explicitly differentiating from closely related sibling tools and not specifying how filters combine (e.g., whether all are required or optional), though the schema indicates all are optional. Given the tool's moderate complexity and strong schema coverage, the description is nearly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so the baseline is 3. The description adds minimal parameter-level meaning—it groups the filters into categories (location, date range, crash type, severity) but does not introduce syntax, format, or constraint details beyond the schema's own descriptions. It does not compensate for any gaps because there are none, but it also doesn't add significant value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with a specific verb ('Search') and resource ('Colorado crash records'), and enumerates filter dimensions (location, date range, crash type, severity). However, it does not explicitly distinguish itself from sibling tools like get_crash_details or get_nearby_crashes, though the broad filter set implies a search-over-details distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage (when you need to search crash records by filters) but provides no explicit when-to-use guidance or exclusions. There is no mention of alternatives like get_crash_details for individual crash details or get_nearby_crashes for location-based proximity, leaving the agent to infer relative suitability from the name and filter set.

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

• get_attorney_profileA
  3.8/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the burden. It usefully discloses the return fields and the conditional 'when available' for AI intelligence data. However, it does not mention behavior for missing slugs or other edge cases, nor any permissions or side effects, though the read-only nature is implied by 'Get'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that states the action and the key contents. It is concise, with no filler or repetition of the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple get-by-slug tool, the description covers the primary behavior and expected outputs, and the schema covers the parameter. It does not describe error responses or clarify overlap with get_attorney_reviews, but these are not critical given the explicit list of profile components.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with a detailed description for the only parameter 'slug' including where to obtain it. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get a detailed attorney profile by slug' with a specific verb and resource. It distinguishes from siblings by enumerating the returned contents (full bio, practice areas, reviews, credentials, office location) and noting AI-analyzed intelligence when available.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a detailed profile is needed, but it does not explicitly state when to use this over alternatives like get_attorney_reviews or search_attorneys. No exclusions or alternative references are provided, though the schema's parameter description hints at a workflow via search_attorneys.

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

• get_attorney_leaderboardA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the ranking methodology (composite score considering ratings, reviews, experience, and case outcomes) and geographic scope (Colorado), which adds meaningful behavioral context. However, it does not mention potential side effects, auth requirements, rate limits, or output structure limitations beyond what is implied.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and followed by a concise explanation of ranking criteria. Every word adds value, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter and no output schema, the description is complete. It states what the tool does, the criteria used, and the geographic scope, satisfying the need to explain return behavior without needing output schema details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single 'limit' parameter, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides; it simply implies a default limit via 'top-ranked' without referencing the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool 'Get the top-ranked personal injury attorneys in Colorado' with a specific verb ('Get') and resource ('attorney leaderboard'). It explicitly defines the ranking basis (composite score of ratings, reviews, experience, and case outcomes), distinguishing it from sibling tools like search_attorneys or get_city_review_leaderboard.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for retrieving a ranked list of top attorneys via the phrase 'top-ranked' and the ranking criteria, but it does not explicitly state when to use this tool versus alternatives like search_attorneys or get_city_review_leaderboard. No exclusions or alternatives are mentioned, so guidance is implied rather than explicit.

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

• compare_review_intelligenceA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden but only lists output content. It does not disclose whether the operation is read-only, any required permissions, or potential error conditions (e.g., firms without sufficient review data). This is a moderate disclosure level, enough to understand the result but not the full behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence. It front-loads the action (Compare) and resource (review intelligence) and then lists the return dimensions without wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description sufficiently explains what the tool returns, covering the main output aspects. Given there is no output schema, this is important. However, it omits any edge-case behavior or prerequisites (e.g., how many reviews a firm needs), leaving a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter firm_slugs is well-documented in the schema (array of 2-5 strings). The description adds no extra semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: comparing AI-analyzed review intelligence across 2-5 law firms. It lists specific output dimensions (pain points, sentiment, trust signals, etc.), distinguishing it from sibling tools like get_review_intelligence (single firm) and compare_attorneys (attorney-centric).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for competitive analysis and specifies the input range (2-5 firms), providing clear context. However, it does not explicitly mention when not to use this tool or name alternatives, 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.

• get_city_review_leaderboardA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It does add behavioral context by revealing that attorneys are ranked by 'composite review metrics including velocity, freshness, momentum, and rating.' However, it does not disclose other behavioral traits such as sorting direction, pagination, or error behavior. This provides some transparency but leaves significant gaps for a read operation with no annotation support.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loaded with the action verb 'Get,' and provides essential context without any fluff. Every clause adds value: the tool's purpose, geographic scope, and ranking criteria are all covered in a compact form. It is concise yet informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read tool with no output schema, the description adequately covers the purpose, scope, and ranking basis. It does not explain return format or pagination, but the absence of an output schema and the tool's simplicity mean the description is nearly sufficient. It could still benefit from mentioning that results are ordered or that a default limit exists, hence a 4 rather than 5.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: both 'city' and 'limit' have detailed descriptions with examples and constraints. The tool description does not add additional param-specific meaning beyond that already in the schema. The mention of composite metrics relates to ranking logic, not to parameter semantics. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get the review-based leaderboard for attorneys in a specific Colorado city.' It specifies the resource (attorney leaderboard), the scope (Colorado city), and the basis (review metrics), distinguishing it from sibling tools like get_attorney_leaderboard which likely covers broader leaderboards.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: use this tool when you need a review-based leaderboard for a specific Colorado city. However, it does not explicitly name alternatives or provide exclusion criteria (e.g., 'for overall leaderboard use get_attorney_leaderboard'). The description implies the use case without making alternatives explicit, which fits the 'clear context, no exclusions' level.

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

• get_crash_detailsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It does say the tool 'Returns complete crash record' and enumerates included content, but it does not disclose behavior for missing CUIDs, error cases, data freshness, or any access restrictions. This is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loads the primary purpose, and every phrase adds value (specific identifier, record contents). There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter lookup tool with no output schema, the description provides enough context by enumerating the major return categories. However, it does not mention behavior for invalid or missing CUIDs, which would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% parameter coverage with a clear description and example for 'cuid'. The tool description expands the acronym but does not add meaningful semantics beyond the schema, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches full details for a specific Colorado crash using a CUID, using a specific verb ('Get') and resource ('crash by CUID'). This distinguishes it from sibling search tools like search_crashes and get_nearby_crashes, which focus on discovery rather than single-record retrieval.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys that the tool is for retrieving a single, known crash via CUID, making the use case clear. It does not explicitly mention when not to use it or point to alternatives, such as searching by criteria first, so it stops 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.

• search_attorney_reviewsA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'most relevant matches' and 'detailed reviews' but does not specify how relevance is determined, whether results are sorted, or what the return format contains. This is acceptable for a read-only search tool, but more detail on ranking and result structure would improve transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise at two sentences, front-loading the primary purpose in the first sentence and usage context in the second. Every word earned its place with no filler or repetition of structured data.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 7 parameters, no output schema, and no annotations, the description covers the core purpose and usage context well. It does not explain the exact shape of the response or ranking algorithm, but the use cases and parameter relationships are clear. Sibling tool references in the schema (e.g., firm_slug source) are already covered, making the description reasonably complete for a search tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage of all 7 parameters, so the baseline is 3. The description adds examples like 'communication, wrongful death, motorcycle crashes' that map to the need, case_type, and injury parameters, providing slight extra context. However, it does not elaborate on parameters such as limit, dimension, or sentiment beyond what the schema already states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Search a law firm's detailed reviews for the most relevant matches to a specific need, case type, injury, sentiment, or pain point.' It uses a specific verb ('search'), identifies the resource ('law firm's detailed reviews'), and differentiates from sibling tools like get_attorney_reviews by emphasizing ranking by relevance to stated criteria.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: 'Use this when someone asks for reviews about communication, wrongful death, motorcycle crashes, fees, settlement clarity, or similar client concerns.' It does not explicitly mention when not to use or name alternatives, but the context is clear enough to guide an agent.

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

• search_attorneysA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of disclosing behavior. It does state that the tool returns attorney profiles plus a canonical slug, which is useful. However, it does not explicitly indicate that this is a read-only operation, nor does it mention pagination behavior or any side effects, leaving some ambiguity for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that clearly states the action, scope, filters, and return value. Every phrase earns its place, with no redundant or vague wording. It is highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (9 parameters, no output schema), the description covers the primary use case well: it explains the return value (profiles and canonical slug) and the main filter dimensions. It does not detail the profile structure or pagination, but the schema covers pagination, and the absence of an output schema makes the return description sufficient for initialization. It is slightly incomplete in not clarifying that the search is scoped to Colorado, but that is explicit.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline for parameter semantics is 3. The description adds contextual meaning by mapping filters (city, county, specialty, rating, verification) to the corresponding schema parameters and clarifying the geographic scope (Colorado). It does not add syntax or value restrictions beyond what the schema already documents, so no higher score is warranted.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Search'), a clear resource ('personal injury attorneys in Colorado'), and enumerates key filters (city, county, specialty, rating, verification). It also distinguishes the tool from siblings by mentioning the canonical slug for use with profile, review, and comparison tools, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: to search for Colorado personal injury attorneys with filters and obtain slugs for other tools. It does not explicitly name alternatives or exclusion criteria, but the scope (Colorado, personal injury, attorney search) and the mention of the canonical slug imply differentiation from siblings like search_attorney_reviews or find_nearby_attorneys.

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

• compare_attorneysA
  4.2/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full burden. It discloses return elements (ratings, reviews, specialties, etc.) and implies a read-only operation, but does not explicitly state that no data is modified or discuss error/edge-case behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The first sentence front-loads the core purpose, the second provides input source and return content. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description covers what it does, how to get inputs, and what to expect in return. It lacks explicit mention of output format or error behavior, but is reasonably 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already fully describes the slugs parameter (array of 2-4 strings). The description adds value by specifying that slugs must be canonical from search_attorneys, which is not in the schema, improving parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the tool's function: compare 2-4 attorney profiles side-by-side. It uses a specific verb ('compare') and resource ('attorney profiles'), and the side-by-side framing distinguishes it from sibling tools like get_attorney_profile. The 2-4 range is also explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance to use canonical slugs from search_attorneys, establishing a prerequisite and source of input. It doesn't explicitly compare to close sibling tools like compare_review_intelligence, but the guidance is clear enough for most use cases.

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

• find_nearby_attorneysA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the Haversine distance calculation and the return format (sorted by distance, contact info, ratings). This adds meaningful behavioral context beyond the schema, though it omits potential edge cases or error behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each adding value: purpose, method, and output. It is front-loaded with the core purpose and contains no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description appropriately explains the return values (attorneys sorted by distance with contact info and ratings). It covers the main behavior of the tool well, but could mention things like limit/radius constraints, though these are already in the schema. Overall, sufficient for a straightforward search tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is already well-documented. The description adds minimal parameter semantics beyond the schema, only hinting at 'near' and distance calculation. It does not clarify how radius_miles interacts with the distance formula beyond what the schema states.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool finds 'personal injury attorneys near a geographic location,' using a specific verb and resource. It distinguishes itself from siblings like search_attorneys and get_nearby_crashes by focusing on proximity-based attorney discovery.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (near a geographic location) but does not explicitly mention alternatives or when not to use it. It implies the tool is for location-based searches, which differentiates it from general search tools, but lacks explicit exclusions.

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

• get_nearby_crashesA
  4.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full transparency burden. It implies a read operation ('Get') and notes the search is centered on the attorney's office address, which is useful. However, it does not disclose potential caveats like approximate address matching, rate limits, or whether results are paginated. This is a moderate gap, but the core behavior is clear enough for a basic understanding.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences long, front-loading the primary purpose and then adding necessary usage context. Every sentence is informative, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema, so the description should ideally explain what the response contains. It mentions 'crash records' but does not clarify the structure (e.g., whether distances are included) or how records relate to the office location. Given the well-documented parameters and clear purpose, this is adequate but leaves some ambiguity for an agent preparing to use the results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing a baseline of 3. The description adds extra meaning to the required parameter attorney_slug by specifying it must be a canonical slug from search_attorneys and serves as the center point, while also clarifying that the tool is not raw lat/lng search. This adds value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Get crash records near a specific attorney's office location') and clearly differentiates this tool from a raw lat/lng search by emphasizing it is attorney-centered. This distinguishes it from sibling tools like search_crashes, which presumably perform generic searches.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the user to first obtain a canonical attorney slug from search_attorneys, and clarifies this tool is not for raw coordinate searches. This provides clear when-to-use and prerequisite guidance, effectively steering users away from misuse.

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

• list_attorney_citiesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It transparently discloses the output format (city names with attorney counts) and implies a read-only list operation. It does not mention potential limitations like data freshness or whether cities with zero attorneys are omitted (though implied), but it's adequate for a simple tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the main action and output. The second sentence adds usage context without redundancy. Every word earns its place, making it highly efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema), the description fully explains what it does and what it returns (cities with attorney counts). It provides enough context for an agent to invoke it correctly without any additional requirements.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description requires no parameter explanation, and the input schema is empty, making it clear no arguments are needed. The description adds no parameter details because none exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('List'), resource ('all Colorado cities'), and output ('count of attorneys in each city'). It distinguishes from sibling tools like get_city_review_leaderboard by focusing on attorney presence rather than reviews.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use case ('discovering which cities have coverage'), giving agents a reason to invoke it. However, it does not explicitly mention alternatives or when not to use this tool, lacking the explicit differentiation seen in top-tier examples.

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