Server Quality Checklist

Tool Scores

• analyze_reviews_gapC
  2.8/5.0
  Behavior2/5

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

  There are no annotations, so the description must carry the behavioral burden. It only states a high-level analysis and suggestion outcome, without disclosing how the analysis is performed, whether any data is modified, or what the tool returns. This provides minimal insight into the tool's actual 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 a single, front-loaded sentence with no filler. It wastes no words and clearly states the action, making it highly concise. While brevity omits detail, that is a completeness concern rather than a conciseness issue.

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

  Completeness1/5

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

  With 7 parameters, no output schema, and no annotations, the description must compensate by explaining inputs, outputs, and edge cases. It does not. The one-sentence purpose statement is grossly inadequate for an analytical tool of this complexity.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not explain any of the 7 parameters. The phrase 'review gaps vs competitors' hints at using ratings and review counts, but it does not clarify specific parameters like unanswered_reviews or competitor_avg_rating, leaving the agent without meaningful context.

  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 the specific verb 'Analyze' with the resource 'Google review gaps vs competitors' and the outcome 'suggest an outreach angle', clearly distinguishing it from sibling tools that focus on email generation, lead scoring, sequences, or trade lists.

  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?

  The description gives no explicit guidance on when to use this tool versus alternatives. It implies a use case for analyzing review gaps for outreach, but does not mention exclusions or alternative tools like generate_cold_email or score_local_lead.

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

• build_email_sequenceB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavioral traits. It only states the sequence structure (3 emails on days 0, 3, 7), but does not mention output format, return values, side effects, permissions, or whether emails are actually sent or just generated. This is minimal disclosure, similar to the 'update_drive' example that scored 2.

  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, concise sentence that front-loads the core action and timing. Every word adds value, and there is no unnecessary verbosity. It is appropriately sized for a simple tool.

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

  Completeness2/5

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

  The tool has four parameters, no output schema, and no annotations, so the description must be self-sufficient to guide correct invocation. It fails to explain parameter semantics, return values, or any preconditions. The schedule detail is helpful but insufficient for an agent to confidently use the tool without additional assumptions.

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

  Parameters1/5

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

  With 0% schema description coverage, the description must compensate by explaining parameter meanings, but it mentions none. The input schema lists 'trade', 'business_name', 'city', and 'owner_name' with no descriptions, and the description provides no clue about what these parameters represent or how they are used. The agent is left without guidance, making this a critical 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 clearly states the tool's function with a specific verb ('Build') and resource ('3-email outreach sequence'). It also specifies the schedule (day 0, 3, 7), distinguishing it from single-email generation tools like 'generate_cold_email'. The purpose is unambiguous and easy to grasp.

  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 creating a multi-email sequence, but it does not explicitly mention when to choose this tool over siblings such as 'generate_cold_email' or 'score_local_lead'. There is no direct comparison or exclusion, leaving the agent to infer the appropriate context. This is borderline between implied and no guidance, warranting a 3.

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

• score_local_leadB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry full behavioral disclosure. It states that scoring is based on observable signals and yields a 0–100 score, but it does not explain the scoring model, whether the operation is read-only, or what the response structure contains. This leaves significant 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 with no wasted words. It efficiently communicates the core action, target, and output scale.

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

  Completeness2/5

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

  Despite having 7 parameters and no output schema, the description fails to specify what the tool returns (e.g., a number or JSON object), how the score is computed, or the role of each input. This is inadequate for a complex scoring tool with no annotations or output schema.

  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 only 14% (only 'trade' has a description). The tool description uses the generic phrase 'observable signals' but does not define how individual parameters (e.g., review_count, google_rating, responds_to_reviews) influence the score. The parameter names provide some semantic clues, but the description adds minimal 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 clearly states a specific verb ('Score'), a resource ('local business lead'), an output range (0–100), and a purpose ('outreach priority'). It distinguishes from sibling tools like generate_cold_email by focusing on scoring rather than generation.

  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 when to use the tool—when you have a lead to score for outreach—but it does not explicitly mention alternatives or exclusions. No mention of when not to use it or how it relates to sibling tools.

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

• generate_cold_emailA
  3.5/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 adds one useful behavioral detail ('No API keys required'), which helps set expectations about authentication. However, it does not disclose output format, whether external services are called, or other side effects, leaving gaps 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, concise sentence with no wasted words. It is front-loaded with the action ('Generate') and the core purpose, making it easy to parse quickly.

  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 the moderate complexity (5 params, no output schema, no annotations), the description is minimal. It doesn't clarify what the output looks like or provide richer context about the generated email's structure, though 'Generate' implies the output is the email. Additional context about output format or personalization would improve completeness.

  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 is 3. The description does not add any parameter-level semantics beyond what the schema already provides, but it also doesn't need to since the schema fully documents each parameter.

  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 generates a value-first cold email for local service businesses, using a specific verb and resource. While it doesn't explicitly distinguish from the sibling 'build_email_sequence', the singular 'cold email' implies a single email, providing implicit differentiation.

  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 context (when you need a cold email for a local service business) but provides no explicit guidance on when to use this tool versus alternatives like build_email_sequence. There are no exclusions or comparisons to sibling tools.

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

• list_tradesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It conveys that the tool returns a list of trades with associated hooks and offers, implying a read-only operation. However, it does not disclose details like data freshness, ordering, or any potential side effects, leaving some gaps.

  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 one-sentence description is front-loaded with the verb and resource, and every word contributes to understanding the tool's output.

  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 (zero params, no output schema), the description fully covers what the agent needs to know: it lists trades with their pain hooks and value offers. No further detail is necessary.

  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 tool has zero parameters and the schema coverage is trivially 100%, so the description adds no parameter-specific semantics beyond the baseline.

  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 the specific verb 'List' and identifies the resource ('supported local service trades') and the included fields ('pain hooks and value offers'), making it distinct from sibling tools that generate or score content.

  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?

  The description does not provide any guidance on when to use this tool versus alternatives like generate_cold_email or score_local_lead. There is no mention of workflows or exclusions.

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