Server Quality Checklist

Tool Scores

• loki_label_valuesA
  3.8/5.0
  Behavior3/5

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

  No annotations provided; description states 'This is read-only' which discloses the main behavioral trait. However, it does not cover potential issues like error handling or limits, leaving some gaps for a tool with no annotation support.

  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 concise sentences with no extraneous information. First sentence presents the action, second the usage context. Efficient and clear.

  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 (one parameter, no output schema, no annotations), the description covers purpose, usage, and read-only nature. It lacks details on return format but that is likely intuitive for a label value list.

  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 already describes the parameter with examples. Description adds 'host or service' which reinforces but does not significantly add beyond schema coverage (100%). Baseline 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?

  Description clearly states 'List values for one Loki label' with examples (host, service), and relates to discovering filter values. It distinguishes from siblings like loki_labels (which likely lists labels), but does not explicitly differentiate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'Use this to discover valid filter values before running a log query.' Provides clear when-to-use guidance. Does not mention when not to use or alternatives, but the context is sufficient.

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

• loki_recentA
  3.8/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It lacks any behavioral details beyond the basic fetch operation, such as authentication requirements, rate limits, or potential side effects. For a read tool, stating it is non-destructive would have been helpful.

  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 sentences, no fluff. First sentence states purpose and key filters, second provides usage guidance. Efficiently front-loaded.

  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 simple log fetch tool with good schema descriptions, the description covers key usage aspects. Lacks return format details, but overall adequate.

  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 covers 100% of parameters with descriptions, so baseline is 3. The description adds value by advising that at least one of host or service should normally be supplied, but does not enhance understanding of since or limit beyond 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?

  Clearly states the action ('Fetch recent logs') and the resource ('logs'), with optional filtering by host and service. Differentiates from sibling tools like loki_query by noting it avoids raw LogQL.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: use for common troubleshooting when raw LogQL is not needed. Advises supplying at least one of host or service to avoid broad queries. No explicit when-not-to-use or direct sibling comparison, but context is clear.

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

• loki_labelsA
  4.5/5.0
  Behavior4/5

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

  The description states it is read-only and returns only label names, which clarifies its non-destructive nature and output scope. However, with no annotations, more detail on output format or limitations could be added.

  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 concise sentences, each adding value. The first sentence states the action, the second provides usage guidance and behavioral notes. No wasted words.

  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?

  For a tool with no parameters and no output schema, the description covers purpose, usage context, and behavior completely. Nothing else is needed.

  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?

  There are no parameters, so the description adds no parameter details. Baseline 4 is appropriate for a zero-parameter tool, and the schema coverage is 100% (trivially).

  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 it lists Loki label names, which is the core purpose. It distinguishes from sibling tools like loki_label_values (which lists values for a label) and loki_query (queries logs).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly advises using this before querying to discover dimensions like host, service, or level. It provides a clear use case but does not mention when not to use or alternative tools.

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

• loki_queryA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so description must carry the burden. It mentions that the query is bounded and that since and limit are capped, implying read-only behavior. However, it does not detail error handling, authentication requirements, or the exact response format beyond 'compact log records'.

  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 (two sentences) with no unnecessary words. The first sentence captures purpose and output, the second provides usage guidance. Every sentence 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 no output schema, the description explains the return value ('compact log records') but not its structure. The three parameters are all documented in the schema, and the description adds context about server caps. This is generally sufficient for a simple query tool, though more detail on the response format would improve 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 coverage is 100%, but the description adds value by clarifying that since and limit are subject to server configuration caps, which is not in the schema. It also describes the output as 'compact log records', though the schema does not define output.

  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 verb 'Run', the resource 'bounded LogQL range query', and the output 'compact log records'. It effectively distinguishes from sibling tools like loki_labels and loki_recent by specifying that this tool is for LogQL queries with text filters.

  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 explicitly states when to use ('when you already know the LogQL selector or need text filters') and when not to use ('Do not use for unbounded or long-history searches'), and mentions server-side caps on since and limit. This provides clear decision support.

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