Server Quality Checklist

Tool Scores

• normalize-promptC
  2.6/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. It only states it's an alias with the same input/output schema as 'cleaner', but doesn't disclose behavioral traits such as whether it's read-only, destructive, has rate limits, or requires authentication. This leaves significant gaps in understanding how the tool behaves beyond basic functionality.

  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 brief and to the point, consisting of two sentences that efficiently convey key information (alias relationship and keywords). However, it could be more front-loaded with a clearer purpose statement, but it avoids unnecessary verbosity.

  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 no annotations, no output schema, and a vague purpose, the description is incomplete. It doesn't adequately explain what the tool does, when to use it, or its behavioral aspects, making it insufficient for an agent to fully understand the tool's role and operation in context.

  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 fully documents the parameters. The description adds no additional meaning beyond stating it has the 'same input/output schema as cleaner', which doesn't explain parameter semantics further. This meets the baseline of 3 since the schema handles the heavy lifting.

  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 states this is an 'alias of cleaner' and lists keywords like 'normalize, restructure, clarify, tighten, format, preflight', which gives a vague sense of purpose but lacks a specific verb+resource statement. It doesn't clearly explain what the tool actually does beyond being related to 'cleaner', making it somewhat ambiguous rather than tautological.

  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 mentions it's an alias of 'cleaner' and lists keywords, but provides no explicit guidance on when to use this tool versus alternatives like 'cleaner' or 'sanitize-text'. There's no context on use cases, prerequisites, or exclusions, leaving the agent with minimal direction.

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

• sanitize-textC
  2.6/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 of behavioral disclosure. It hints at functionality through keywords (e.g., 'pii', 'redact') but doesn't explain what the tool actually does behaviorally—such as whether it modifies input, returns cleaned output, or handles errors. This leaves critical operational traits unspecified.

  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 brief and front-loaded with key information (alias and keywords), but the second sentence about the schema is somewhat redundant given the structured input. It avoids unnecessary elaboration, though it could be more streamlined by integrating the alias and keyword info more cohesively.

  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 no annotations and no output schema, the description is incomplete for a tool with 3 parameters. It fails to explain what the tool returns or how it behaves, relying too heavily on the schema and leaving gaps in understanding the tool's overall functionality and results, which is inadequate for effective agent use.

  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 fully documents parameters like 'prompt', 'mode', and 'temperature'. The description adds no additional semantic context beyond stating 'Same input/output schema as cleaner', which doesn't enhance understanding of parameter purposes or interactions, meeting the baseline for high schema coverage.

  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 states this is an 'alias of cleaner' and lists keywords like 'sanitize, scrub, redact, filter, pii, normalize, preprocess', which gives a general sense of purpose. However, it doesn't specify a clear verb+resource combination (e.g., 'sanitize text by removing PII') and doesn't distinguish it from its sibling 'cleaner' beyond stating it's an alias, leaving the relationship ambiguous.

  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 no explicit guidance on when to use this tool versus alternatives like 'cleaner' or 'normalize-prompt'. It mentions it's an alias of 'cleaner' but doesn't clarify if they are interchangeable or if there are specific contexts favoring one over the other, offering minimal usage direction.

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

• health-pingB
  3.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 states the tool returns '{ ok: true }', which implies a read-only, non-destructive operation, but doesn't cover other traits like error handling, latency, or side effects. This is adequate as a minimal disclosure but lacks depth.

  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 extremely concise and front-loaded, consisting of just two phrases that directly state the tool's function and output. Every word earns its place with no waste, making it highly efficient.

  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 (0 parameters, no output schema, no annotations), the description is complete enough for a basic liveness probe. However, it could benefit from more context, such as when to use it or what 'ok: true' signifies, but it meets the minimum viable standard for this low-complexity tool.

  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 0 parameters, and the schema description coverage is 100%, so no parameter information is needed. The description doesn't add parameter details beyond the schema, but with no parameters, this is acceptable, aligning with the baseline of 4 for zero-parameter tools.

  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 purpose as a 'liveness probe' that returns a specific response, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'cleaner' or 'normalize-prompt', which appear to serve different functions, so it doesn't fully meet the highest standard for sibling differentiation.

  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 no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent without usage instructions. This is a basic gap in guidance.

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

• cleanerA
  4.5/5.0
  Behavior4/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 effectively describes key traits: 'read-only, idempotent, no side effects', which clarifies safety and operational characteristics. However, it lacks details on rate limits, error handling, or specific PII types redacted, leaving some behavioral aspects unspecified.

  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 well-structured with clear sections (purpose, usage, behavior, input, output, keywords) and front-loaded key information. Most sentences earn their place, but the keyword list at the end is somewhat redundant with earlier content, slightly reducing efficiency without adding new insights.

  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 moderate complexity, no annotations, and no output schema, the description does a good job covering purpose, usage, behavior, and parameters. It explains the output format ('JSON { retouched, notes?, openQuestions?, risks?, redactions? }'), compensating for the lack of output schema. However, it could provide more detail on error cases or specific redaction rules for completeness.

  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 100%, so the baseline is 3. The description adds value by explaining parameter defaults ('defaults mode='general', temperature=0.2') and usage context for 'mode' ('mode='code' only for code-related prompts'), which enhances understanding beyond the schema's enum and descriptions. It doesn't fully elaborate on 'temperature' effects, keeping it from a perfect score.

  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 specific verbs ('normalize', 'redact', 'structure') and resources ('raw/free-form user text'), distinguishing it from siblings like 'normalize-prompt' and 'sanitize-text' by emphasizing pre-reasoning processing and PII redaction. It explicitly mentions preserving user intent, which adds nuance beyond basic normalization.

  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 provides explicit guidance on when to use this tool ('when you receive raw/free-form user text and need it cleaned before planning, tool selection, or code execution') and distinguishes it from alternatives by specifying mode usage ('mode='code' only for code-related prompts'). It also positions it as a 'good default to run automatically', offering clear context for application.

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