Server Quality Checklist

Tool Scores

• debug_data_layerB
  3.1/5.0
  Behavior2/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 indicates a non-mutating 'Analyzes' operation and that recommendations are produced, but it does not describe return structure, side effects, or how the optional 'checkPoints' parameter changes behavior. This leaves significant behavioral ambiguity.

  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, front-loaded sentence that immediately conveys the tool's main purpose. The marketing-style phrase 'Perfect for troubleshooting tracking issues' is somewhat extra, but the overall length is appropriate and the message is compact.

  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?

  Given there is no output schema and no annotations, the description should explain what the tool returns and how 'checkPoints' affects the analysis. It does neither, leaving an agent without enough information to correctly interpret the tool's response or fully understand the optional parameter's role.

  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 documents both parameters with descriptions, providing 100% coverage. The description adds some context about the kind of analysis performed ('missing variables, type mismatches'), which loosely contextualizes the 'dataLayer' input, but it does not add meaningful detail about 'checkPoints' beyond what the schema already states.

  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 uses a specific verb ('Analyzes') and names the resource ('data layer'), and goes on to specify the scope: common issues, missing variables, type mismatches, and recommendations. This clearly states what the tool does, though it does not explicitly distinguish it from the sibling 'validate_data_layer'.

  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 phrase 'Perfect for troubleshooting tracking issues' gives a clear use case and implied context, but there is no explicit guidance on when to prefer this tool over sibling 'validate_data_layer' or when it should not be used. The selection guidance is largely implied rather than stated.

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

• validate_data_layerB
  3.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 of behavioral disclosure. It does disclose the return categories ('errors, warnings, and suggestions for improvement'), which is useful, but it does not mention side effects, whether the input is mutated, what happens with an invalid schemaUri, or other runtime 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 two tight sentences with no filler. It leads with the core action and immediately conveys the value of the return value, making every sentence earn 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?

  All parameters are documented in the schema, and the description communicates the tool's purpose and output categories. It is slightly incomplete because it does not help an agent distinguish this tool from similar siblings or describe the response shape, but for a validation tool with full schema coverage it is largely sufficient.

  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 parameters are already well documented in the schema. The description adds no parameter-specific details beyond that, so the baseline of 3 is appropriate.

  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 uses a specific verb and resource ('Validates a Tealium data layer object') and states the outcome (errors, warnings, suggestions). It is clear about what the tool does, but it does not explicitly differentiate it from sibling tools like debug_data_layer, so it falls short of a 5.

  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 on when to use this tool versus alternatives such as debug_data_layer or parse_tracking_spec. The description implies a validation use case but gives no explicit context, exclusions, or conditions for choosing this tool.

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

• generate_codeA
  3.5/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 burden of behavioral disclosure. It usefully reveals the artifacts it generates, but it does not describe side effects, output format, return behavior, or whether the code is returned inline or persisted somewhere.

  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 focused sentences with no filler. The core action and input are front-loaded, and the second sentence enumerates deliverables without redundancy.

  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 schema covers parameters well and the description specifies the kinds of output, but there is no output schema, no annotations, and no usage-selection guidance. An agent is left without clarity on how the generated code is returned or why this tool should be chosen over generate_documentation.

  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 schema already documents all four parameters. The description adds context by mentioning the input source and generated outputs, but it does not clarify parameter 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 names a specific verb and resource: 'Generates TypeScript or JavaScript code from a tracking specification or data layer.' It also lists concrete outputs (type definitions, helper functions, event tracking code), which clearly distinguishes it from siblings like validate_data_layer, debug_data_layer, and generate_documentation.

  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 select this tool over the sibling tools. The description implies it should be used when generated code is needed, but it does not state conditions, prerequisites, alternatives, 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.

• generate_documentationA
  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 of behavioral disclosure. It does state the core behavior: generating documentation from an input structure and outputting Markdown or JSON Schema. However, it does not disclose behavior around missing inputs, whether both spec and dataLayer can be provided simultaneously, or any side effects, which leaves meaningful gaps.

  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 short sentences with no filler, and the primary action is front-loaded. The second sentence is largely redundant with the format parameter's enum, but it is still efficient and aids quick comprehension. It could have been condensed into one sentence without losing meaning.

  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?

  This is a 3-parameter tool with no required fields, no output schema, and no annotations, yet the description does not clarify whether at least one of spec or dataLayer must be provided, what happens if neither is given, or how the two inputs interact. An agent lacks crucial calling constraints and return details beyond the format names.

  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 schema already documents all three parameters and their descriptions. The tool description only restates the concepts of 'data layer structure' and 'tracking specification' that the schema already covers. It adds no additional meaning beyond what the schema 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 action ('Generates documentation'), its input source ('data layer structure or tracking specification'), and its output formats ('Markdown or JSON Schema'). This distinguishes it from sibling tools like validate_data_layer, debug_data_layer, parse_tracking_spec, and generate_code, all of which have different purposes.

  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 the tool should be used by naming its purpose and inputs, but it does not explicitly state when to prefer it over alternatives or when not to use it. There is no mention of how it differs from generate_code or that validate/debug tools serve different needs. Usage context is only implied, not specified.

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

• parse_tracking_specA
  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 must carry the full burden. 'Parses' and 'Normalizes' suggest a read-only transformation, but the description does not mention side effects, error behavior on malformed input, or what the normalized 'structured format' looks like. This lack of detail leaves key behavior undisclosed.

  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 verb and resource, and contains no redundant filler. Every clause contributes to the tool's purpose. It is concise while conveying the essential input and processing intent.

  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?

  Input side is complete due to full schema coverage, and the description says the output is a normalized structured format. However, with no output schema, the description should specify the returned format or structure more concretely, and it does not cover error behavior on invalid input. Still, for a straightforward parser with fully documented inputs, this is adequate if not richly detailed.

  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's reference to 'CSV or JSON' and Google Sheets/Excel adds slight context to the content parameter but does not explain hasHeader or format choices beyond the schema. No parameter information is needed beyond what the schema already provides.

  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 ('Parses'), a resource ('tracking specifications'), and the input formats ('CSV or JSON'), which clearly differentiates it from siblings like validate_data_layer or generate_code. The normalization clause adds the tool's core purpose. An agent can identify what this tool does without opening the schema.

  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 provides a context clue with '(e.g., exported from Google Sheets or Excel)', implying when raw tracking spec files would be parsed. However, it does not explicitly state when to use this tool versus alternatives such as validate_data_layer or debug_data_layer, nor any exclusions. Usage is inferred from the verb rather than directly guided.

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