Server Quality Checklist

Tool Scores

• neighborhood_local_indexA
  3.7/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. It discloses the sampling methodology, LocalRoots scoring, aggregation into a Local Index, and the emphasis on per-category breakdown. However, it does not address potential external API calls, rate limits, or exact interpretation of the output score scale.

  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 3 sentences, front-loads the main purpose, and includes a purposeful explanation of why per-category stats matter. It is concise without unnecessary filler, though the final sentence is more explanatory than operational.

  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?

  Given there is no output schema and no annotations, the description provides a reasonable overview of the tool's purpose, methodology, and use case, but it leaves gaps such as the default values for radius_km and sample_size, the expected output format details, and potential edge cases. It is adequate but not fully complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions the default categories list, which is helpful, but it does not explain the semantics of radius_km, sample_size, or how the neighborhood parameter is used. This leaves users guessing about important parameter behavior.

  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 action ('Score a neighborhood'), the subject ('independent-business density'), and the output ('single Local Index plus per-category stats'). It also implicitly distinguishes itself from sibling tools by focusing on neighborhood-level aggregation, not individual business scoring or farm 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 explicitly says to use this tool 'when a user asks how local is X neighborhood or wants to compare two areas,' which provides clear usage context. It does not explicitly list when-not-to-use cases or alternative sibling tools, but the guidance is direct and actionable.

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

• compare_local_vs_chainA
  4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses the Google Places resolution, LocalRoots scoring, side-by-side output, warning behavior, and Wayback Machine tenure check. While it doesn't mention side effects or rate limits, it offers substantial behavioral detail.

  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?

  At five sentences, the description is slightly long but every sentence adds useful information. The first sentence is a strong front-loaded summary, and the rest covers usage, edge cases, and the tenure check.

  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 no output schema, the description covers the key output elements (side-by-side breakdown, delta, verdict) and process steps. It also handles likely edge cases (chain scoring higher, thin Google profile) and the tenure check, making it quite complete for a comparison tool.

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

  Parameters2/5

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

  Schema coverage is 0%, and the description does not explicitly name the parameters (independent_name, chain_name, near, category). It implies their roles contextually (independent vs chain, location) but leaves category unexplained and doesn't provide format details, so compensation is insufficient.

  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 opens with a specific verb and resource: 'Score a local independent head-to-head against a national chain.' It clearly distinguishes from siblings by focusing on comparison, and details the process and output.

  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?

  Explicitly states 'Use this when a user wants to understand exactly how much more independent a local spot is compared to the chain down the street, or to validate that a suspected chain is actually disqualified.' This provides clear use cases, though it doesn't name alternative tools or when not to use it.

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

• find_farms_with_online_storeA
  4.1/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 and does well: it reveals the detection method (fingerprinting against a specific platform list), the ranking behavior (DTC-confirmed farms first, then unconfirmed), and the optional product_focus filter. It lacks details on error handling or result format, but it is far more transparent than typical tool descriptions.

  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 efficient and front-loaded. Five sentences cover purpose, detection method, ranking, usage guidance, and parameter semantics, with no fluff. The structure flows logically from 'what' to 'how' to 'when'.

  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 search tool with 4 parameters and no output schema, the description covers the core purpose, detection approach, ranking, and usage context. It does not explain return values or the three unspecified parameters, but these are somewhat secondary for a local search tool. Overall, it is more complete than average but has clear gaps.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It only explains product_focus (listing valid values) and leaves near, radius_km, and max_results undefined. While names are somewhat self-explanatory, 'near' format and radius_km units are not clarified. This is a significant gap given the low schema coverage.

  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 (`Find`) and resource (`independent farms near a location`) and clearly states the unique capability: detecting direct-to-consumer e-commerce via website fingerprinting. It distinguishes from sibling tools by focusing on farm-first DTC platforms and ranking confirmed stores first.

  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 explicitly states when to use the tool: 'when a user wants to buy direct from a farm without going through an aggregator or marketplace.' It does not list alternatives or exclusions, but the context is clear and actionable. No mention of sibling tools, 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.

• discover_local_independentsA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and it delivers: it details the algorithm's penalties and rewards (high review counts, chain disqualification, tenure, etc.), explains the tier system (tier_1 through tier_4), and indicates it returns a score breakdown and practical_note. It also instructs the agent to always include place_id, which is practical behavioral guidance.

  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 sentences, each earning its place: first gives purpose and ranking, second gives usage trigger and examples, third describes output and the place_id follow-up. It is front-loaded with the core purpose and contains no filler or repetition.

  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 absence of an output schema, the description adequately explains what is returned (tier, total score, signal_breakdown, practical_note) and gives follow-up guidance about place_id. It is less complete on parameter details like radius_km and min_tier, but overall the tool has enough context for correct invocation in most cases.

  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 only 17% (just include_chains), so the description must compensate. It does explain 'query' and 'near' as the query and location, mentions max_results explicitly, and touches on include_chains via chain disqualification and min_tier via tier definitions. However, it never clarifies the meaning or filtering behavior of radius_km or how min_tier values map to filtering, leaving a clear gap.

  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 opens with a specific verb 'Find' and a clear resource: 'independent local businesses for a given query and location,' with a differentiating ranking criterion ('LocalRoots' independence score instead of Google's review-volume default'). It distinguishes itself from siblings like find_farms_with_online_store by covering general local business discovery and from score_specific_business by focusing on a list of results rather than one business.

  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 trigger examples ('Use this when a user asks for local coffee, an independent bookstore, a real bakery, etc.'), which is strong guidance. However, it does not explicitly state when not to use the tool or point to alternative sibling tools for specific cases (e.g., farms or scoring a known business), 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.

• score_specific_businessA
  4.4/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 discloses key behaviors: fetching Place Details from Google Places when place_id is given, and running a top-1 text search when only name+near are given. It also mentions the return shape mirrors discover_local_independents, which sets expectations about the response. It doesn't cover side effects or rate limits, but for a scoring tool this is adequate.

  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 compact and well-structured: it states the purpose, clarifies the return shape, provides usage context, and explains parameter behavior in a few sentences. No filler or redundant wording.

  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 lacking annotations and output schema, the description covers the core aspects: inputs, behavior, usage scenario, and return shape reference. It relies on discover_local_independents for the exact shape, which is acceptable given sibling context. It could be more self-contained, but it's sufficient for an agent to select and invoke the tool correctly.

  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 0%, so the description must explain the parameters. It does: 'by place_id, or by (name + near)' and details that place_id triggers a Places fetch while name+near triggers a text search. This gives meaningful semantics to all three parameters beyond bare names, though it doesn't address the case when both are provided.

  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 opens with a specific verb+resource: 'Score a specific business'. It clearly distinguishes from sibling tools by stating it's for a single place the user already has in mind, versus discovery-oriented siblings like discover_local_independents and find_farms_with_online_store.

  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?

  Explicit when-to-use guidance is provided: 'Use this when a user asks "is X actually independent?" or wants to understand why a particular business ranked where it did.' It implies the tool is not for broad discovery, but does not explicitly state exclusions or name all alternative tools, so a 4 is appropriate.

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