Server Quality Checklist

Tool Scores

• label_valuesC
  2.6/5.0
  Behavior1/5

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

  The description claims 'List values' which implies a read-only operation, but annotations declare readOnlyHint=false and destructiveHint=true. This is a direct contradiction that could lead to catastrophic misuse by an agent believing this is a safe query when it actually performs destructive operations.

  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?

  Single sentence is appropriately brief, but given the destructive annotations and operational complexity, the description is under-sized rather than elegantly concise. Critical safety information is omitted, making the brevity inappropriate.

  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 destructive annotations and three parameters (including time ranges), the description provides no output schema hints, no explanation of the destructive nature, and no guidance on the Loki query patterns. The contradiction with annotations further erodes 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?

  With 100% schema description coverage, the structured documentation carries the full parameter semantics. The description mentions 'specific label name' which aligns with the required 'label' parameter, but adds no format details, validation rules, or time range behavior beyond the schema.

  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 provides a clear verb ('List') and resource ('values for a specific label name in Loki'), specifying the domain. However, it does not explicitly differentiate from sibling tool 'labels' (which likely lists label names rather than values), which could cause selection ambiguity.

  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 provided on when to use this tool versus alternatives like 'query' or 'labels'. No mention of prerequisites such as requiring the label name to exist, or when the time range parameters are necessary versus optional.

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

• query_rangeC
  2.6/5.0
  Behavior1/5

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

  Annotations indicate destructiveHint=true and readOnlyHint=false, implying data modification or deletion, but description frames the tool as simply 'fetching' logs (a read operation). This creates a dangerous mismatch between expected and 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.

  Conciseness3/5

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

  Single sentence is structurally efficient and front-loaded, but inappropriate brevity given the tool's destructive annotations. The conciseness comes at the cost of omitting critical safety 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?

  Lacks output schema and description fails to indicate return format, pagination behavior, or what gets destroyed. For a tool marked destructive with 5 parameters, the description is insufficiently complete.

  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 has 100% description coverage, establishing baseline 3. Description mentions 'LogQL' (clarifying the query parameter format) and 'time window' (referencing start/end), adding contextual meaning without repeating schema details.

  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?

  Clearly states the action (execute LogQL range query), target system (Loki), and scope (fetch logs over time window). Mentions 'range' which distinguishes from sibling 'query', though could explicitly contrast with instant queries.

  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?

  Provides no guidance on when to use this vs. the sibling 'query' tool or others. Fails to warn about the destructive nature implied by annotations, giving no prerequisites or conditions for safe usage.

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

• seriesC
  2.6/5.0
  Behavior1/5

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

  The description uses 'Find', which implies a safe read operation, but the annotations declare readOnlyHint=false and destructiveHint=true. This is a significant contradiction: a destructive 'find' operation requires explanation (e.g., if it creates temporary resources or modifies indexes), which is completely absent.

  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 single sentence is front-loaded with the verb and contains no waste, but it is inappropriately brief given the tool's complexity, contradictory annotations, and need for sibling differentiation. It sacrifices necessary context for brevity.

  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?

  Fails to explain the destructive nature indicated by annotations, lacks differentiation from similar query tools, and provides no guidance on the output format or cardinality (unique series vs. log lines). Incomplete for a tool with 3 parameters and destructive side-effects.

  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 100% schema description coverage, the schema adequately documents all three parameters (end, match, start). The description mentions 'matching a selector' which loosely maps to the 'match' parameter, but adds no semantic value beyond the schema's 'Stream selector' description.

  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 specific action ('Find'), resource ('active log stream series'), and system context ('in Loki'). However, 'Find' is slightly weaker than verbs like 'List' or 'Retrieve', and it doesn't explicitly clarify the distinction between 'series' (unique streams) and log lines returned by the sibling 'query' 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?

  Provides no guidance on when to use this tool versus the sibling 'query', 'query_range', 'labels', or 'label_values' tools. In Loki, series discovery and log querying are distinct operations, but the description offers no selection criteria or prerequisites.

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

• labelsB
  3.2/5.0
  Behavior1/5

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

  The description contradicts the annotations by describing a 'List' operation (typically read-only) while annotations declare destructiveHint=true and readOnlyHint=false. It fails to explain what makes this destructive or how the time range parameters affect 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?

  Single sentence of 12 words with zero waste. The value proposition is front-loaded and immediately clear.

  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?

  While the core purpose is stated, the description is incomplete given the destructive annotations and lack of output schema. It fails to resolve the contradiction between 'listing' and 'destructive' behavior or explain what data is returned.

  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 100% schema description coverage, the baseline is 3. The description adds no additional parameter context beyond what the schema already provides regarding the time range format or semantics.

  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 specific action (List), resource (label names in Loki), and context (for building LogQL queries), distinguishing it from sibling tools like query or label_values.

  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?

  It mentions the purpose ('for building LogQL queries') providing implied context, but lacks explicit guidance on when to use this versus label_values or query tools, and doesn't mention prerequisites.

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

• queryA
  4/5.0
  Behavior3/5

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

  The description discloses the external system (Loki) and query language (LogQL), adding context beyond annotations. However, it does not explain the implications of destructiveHint=true or idempotentHint=false, nor does it describe the return payload or query cost characteristics.

  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 single sentence is tightly constructed with no wasted words, front-loading the action ("Execute") and clearly stating the domain-specific operation type ("instant query").

  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 complete input schema (100% coverage), present annotations covering safety hints, and simple parameter structure, the description is nearly complete. A minor gap exists regarding the output format (absent output schema), though 'query' implies data retrieval.

  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?

  While the schema has 100% coverage, the description adds valuable domain context: "LogQL" clarifies the query parameter's syntax, and "point-in-time" clarifies the time parameter's purpose. This exceeds the baseline expectation for well-schemed parameters.

  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 provides a specific verb ("Execute"), resource ("LogQL instant query"), and target system ("Loki"). The phrase "point-in-time evaluation" effectively distinguishes it from the sibling tool "query_range" (which implies a time range), making the scope clear.

  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 terms "instant query" and "point-in-time evaluation" implicitly suggest when to use this tool (single timestamp evaluation) versus the "query_range" sibling, but it does not explicitly name alternatives or state 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.