Server Quality Checklist

Tool Scores

• get_next_actionsC
  2.6/5.0
  Behavior2/5

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

  There are no annotations, and the description does not disclose side effects, read-only guarantees, error behavior, or visibility semantics. 'Visible to audience' hints at filtering but does not explain what happens for each audience value.

  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 one compact, front-loaded sentence. No filler. It could be clearer, but it is efficiently structured and does not bury the key parameter.

  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?

  For a tool with no annotations and an opaque 'joint/internal' qualifier, the description leaves too much unexplained: what makes an action 'joint' or 'internal', whether the output is a list or a single recommendation, and how `audience` affects results.

  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?

  With 0% schema description coverage, the description at least ties `audience` to the visibility of results, which adds some meaning beyond the raw enum. However, it does not clarify the 'internal' vs 'customer' values or the meaning of 'joint'.

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

  Purpose3/5

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

  The description names the resource ('joint/internal next actions') and ties it to the `audience` parameter, and the resource name distinguishes it from sibling tools like get_risks and get_expansion_pipeline. However, it is a noun phrase rather than an explicit action, and the term 'joint/internal' is ambiguous, so an agent cannot be certain what is being returned.

  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 given about when to prefer this tool over alternatives, how to choose between 'internal' and 'customer', or what qualifies as a 'next action'. The only usage hint is 'visible to audience', which is too weak to route an agent reliably.

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

• get_claims_checkC
  2.8/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 carry the behavioral burden. 'The three headline-claim checks' weakly implies a read-only retrieval, but the description does not disclose whether results are cached, computed on demand, require prior state, or return arbitrary historical data. The parenthetical about ClaimCheck internal fields is cryptic, not an informative behavioral disclosure.

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

  Conciseness3/5

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

  The description is short and front-loaded with the main subject, but the parenthetical at the end is cryptic and adds little. It earns a middling score because it is compact yet not self-explanatory.

  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 are no parameters, the tool is trivially callable/myfreecams, and the output schema is marked present, the main missing piece is a clear statement of what the three headline-claim checks are and when to use them. The parenthetical provides a small structural hint but does not explain return semantics or use cases.

  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 input schema has no parameters defining a 100% schema coverage baseline, so the description is not required to explain parameter details. The brief mention of 'no internal fields' attempts to describe the shape of the returned ClaimCheck, but does not provide actionable parameter semantics.

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

  Purpose3/5

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

  The description names the subject ('the three headline-claim checks') but never states an action—it is a noun phrase, not a sentence like 'returns' or 'retrieves'. It distinguishes the payload from sibling get_* tools by name, but not by explicit behavior. It contains a confusing parenthetical ('no internal fields exist on ClaimCheck') that is not explained.

  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 call this tool versus get_health_score, get_metric_trend, or get_risks. The description implies the tool returns claim checks, but it never states contexts, exclusions, or alternatives. There is no misleading guidance, but the agent is left to infer everything.

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

• get_metric_trendC
  2.9/5.0
  Behavior3/5

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

  The description discloses that the tool returns daily values and L7/F7 means, which is a basic behavioral summary. However, with no annotations provided, the description carries the full burden and does not mention operational facts like computation of the means, time range, or output shape beyond the schema. It adds some value by defining what is returned, but not enough for a mutation-free read-only 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 a single sentence with no filler, and it front-loads the principal output ('Daily values') before the aggregate details. Every phrase contributes to clarifying the data set. It is concise without losing useful information.

  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 an output schema, the description leaves important gaps: the 'audience' parameter is doubly unexplained (schema also has no description), the L7/F7 definitions are not expanded, and the expected date range is not indicated. The combination of a missing parameter explanation and no annotations makes the description incomplete for a confident invocation of this tool.

  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?

  The description does not explain the actual parameters: 'audience' is solely mentioned in the schema, and the description's phrase 'one numeric DayRow metric' maps vaguely to 'metric'. With schema description coverage at 0%, the description was responsible for compensating, but it does not define either parameter or how the audience filter affects the output. This leaves the agent unable to correctly choose the metric or understand the audience scope beyond guessing from enum names.

  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 output ('Daily values' for a metric plus L7/F7 means), which maps to a specific verb-resource: retrieving a metric trend. It does not explicitly say 'returns' or 'retrieves', but the tool name and described outcomes make the purpose clear. It is also distinct from the sibling tools about health scores, claims, risks, and expansion, which improves clarity.

  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 the sibling tools. It implies the result is daily metric data but never states 'use this when you need a daily trend' or names any alternative. An agent must infer that this is the only tool for metric trends, which is left to inference rather than explicit direction.

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

• get_expansion_pipelineB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose that the output is ranked and that customer-facing output is scrubbed of internal fields, which is useful behavioral context. However, it does not mention side effects, authorization, or any other operational traits; as a read-style tool this is acceptable 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.

  Conciseness4/5

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

  The description is a single sentence with no wasted words, and the core resource phrase is front-loaded. It loses one point because the noun-phrase structure is slightly less actionable than a clear verb-led instruction.

  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 tool's simplicity—one optional enum parameter and an output schema present—the description is mostly adequate. It communicates the core product and the customer-scrubbing behavior, but lacks any usage context or sibling differentiation that would help an agent decide when to invoke it.

  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 0%, so the description must compensate. It hints at the audience parameter by saying the pipeline is 'scrubbed of internal fields for customer,' implying the customer variant differs from internal. But it never names the parameter or explicitly explains the internal/customer distinction, leaving part of the semantic burden on the enum labels alone.

  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 identifies a specific resource ('ranked brand expansion pipeline') and adds a scoping detail ('scrubbed of internal fields for customer'). The name's 'get' verb conveys retrieval, and the resource is distinct from siblings like get_risks and get_next_actions. It falls short of a 5 because it is phrased as a noun phrase rather than an explicit action statement.

  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 about when to use this tool versus its siblings, and no conditions or exclusions are stated. The audience default is discoverable from the schema, but the description does not explain when the internal vs. customer variant is appropriate.

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

• get_health_scoreA
  3.5/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. It adds a meaningful behavioral detail—'scrubbed of internal fields for customer'—which tells the agent that output content changes by audience. It does not go further to discuss authentication, latency, or what 'operational health' includes, so transparency is only partial.

  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 one tight sentence that front-loads the tool's purpose before the parameter-specific scrub detail. Every word earns its place; no 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 tool with an output schema available, the description covers the core purpose and the main behavior difference by audience. It omits sibling differentiation and explicit usage conditions, but the availability of an output schema reduces the burden of describing return shape.

  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%, but the description directly addresses the single `audience` parameter by tying it to the report and explaining that customer output is scrubbed of internal fields. This adds value beyond the raw enum values and default, though it doesn't explicitly define what an internal audience receives.

  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?

  States the tool produces an 'operational health report' scoped by `audience`, which identifies the resource and intent clearly. It distinguishes itself from trend/risks/claims siblings by naming a distinct report type, though it doesn't explicitly say 'returns' or 'gets' and doesn't name the alternative tools.

  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 audience context and mentions scrubbing for customer, so there is an implied target use, but it provides no explicit when-to-use guidance or exclusions relative to siblings like get_metric_trend or get_risks. An agent is left to infer the right selection from the name and phrase 'operational health report.'

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

• get_risksA
  3.8/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 that results are ranked and filtered by audience, which is useful. However, it does not explicitly state read-only behavior, authentication requirements, or any side effects, though the 'get' verb implies a read operation.

  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?

  A single 13-word sentence with no waste, front-loaded with the main action and parameters. 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?

  Given the tool's simplicity (two optional parameters) and the presence of an output schema, the description covers purpose, ranking, and filtering adequately. It lacks error conditions or prerequisites, but for a simple read operation this is sufficient.

  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 description coverage is 0%, but the description explains both parameters: top_n as the count and audience as the visibility filter. This adds meaning beyond the schema's types and defaults, effectively compensating for the lack of schema descriptions.

  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 verb ('get'), resource ('risks'), and the ranking logic (severity x likelihood), clearly distinguishing it from siblings like get_health_score or get_metric_trend. The scope is unambiguous.

  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 provides context on what the tool returns but does not explicitly state when to use it over alternatives or when not to use it. No exclusions or comparisons are given, leaving the agent to infer usage.

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