Server Quality Checklist

Tool Scores

• uptrace_get_monitorC
  2.9/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 implies a read-only operation via 'Get' but does not confirm this, nor does it describe error handling (e.g., behavior if ID not found), return format, or authentication requirements.

  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, efficient sentence with no wasted words. However, given the lack of annotations and output schema, it may be overly terse—leaving no room for behavioral context that would help an agent understand failure modes or return values.

  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?

  For a simple single-parameter lookup tool, the description meets the minimum threshold by stating the core function. However, with no output schema and no annotations, the description should ideally describe what details are returned or error conditions to be considered 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 description coverage is 100%, with the parameter 'monitor_id' fully documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, warranting a baseline score.

  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 clear verb ('Get') and resource ('monitor') with scope ('by ID'), making the basic function unambiguous. However, it does not explicitly differentiate from sibling tool 'uptrace_list_monitors' (e.g., stating to use this when the ID is known).

  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 'uptrace_list_monitors' or what prerequisites are needed (e.g., having the monitor ID). The description states what the tool does but not when to invoke it.

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

• uptrace_get_alertB
  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 full burden for behavioral disclosure. It only states 'Get details' without describing error behavior (e.g., what happens if the ID doesn't exist), authentication requirements, or what specific fields/details are returned in the response.

  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, front-loaded with the verb, zero wasted words. Appropriate length for the tool's simplicity.

  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?

  Adequate for a single-parameter retrieval tool, but the lack of output schema means the description should ideally characterize the returned alert details (severity, status, monitor reference, etc.) to compensate, which it does not.

  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 coverage is 100% ('ID of the alert incident to retrieve'), so the schema adequately documents the parameter. The description adds 'by ID' which aligns with the schema but provides no additional format details, constraints, or examples beyond the schema itself.

  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?

  Clear verb ('Get') and resource ('alert incident'), with specific scope ('by ID'). However, it doesn't explicitly differentiate from sibling 'uptrace_get_monitor' (alerts vs monitors are distinct resources in observability, but this isn't clarified), preventing 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?

  No guidance on when to use this tool versus 'uptrace_get_monitor' or the various search/list siblings. The description states what the tool does but not when to choose it over alternatives that also retrieve observability data.

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

• uptrace_get_traceB
  3.3/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 fails to indicate whether this is a read-only operation, what happens if the trace_id is not found, or performance implications of retrieving 'all spans' (which could be thousands). Only the use case context is provided.

  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 with zero waste: the first states the core action, the second provides usage context. It is appropriately front-loaded and sized for the tool's complexity.

  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 absence of an output schema, the description adequately identifies that 'spans' are returned, but lacks detail on the structure, nesting, or volume of returned data. For a simple 2-parameter retrieval tool, it meets minimum viability but leaves gaps in explaining the return value structure.

  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 fields already document both parameters thoroughly. The description mentions 'specific trace ID' which aligns with the required parameter, but adds no additional semantic detail about the format parameter's implications or trace_id format requirements beyond what the schema already provides.

  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 ('Get') and resource ('spans') with clear scoping ('for a specific trace ID'). However, it does not explicitly differentiate from sibling tool 'uptrace_search_spans', which likely searches across traces rather than retrieving a complete trace by ID.

  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 'Useful for debugging and understanding request flows' provides implied context for when to use the tool. However, it lacks explicit guidance on when NOT to use it (e.g., when to use search_spans instead) or prerequisites like obtaining the trace_id first.

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

• uptrace_list_monitorsA
  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. It partially compensates by disclosing return values (IDs, names, types, configuration), but omits other behavioral traits like pagination, rate limits, permissions required, or performance characteristics of listing 'all' items.

  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 consists of two efficient sentences with zero waste: the first states the action, the second states the return value. It is appropriately front-loaded and sized for a simple parameterless tool.

  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 zero-parameter list tool with no output schema, the description is reasonably complete. It compensates for the missing output schema by describing what fields are returned (IDs, names, types, configuration), though it could mention pagination or result limits.

  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 0 parameters, establishing a baseline score of 4. The description correctly implies no filtering is possible by stating 'List all,' which aligns with the empty 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 clearly states the verb (List), resource (alerting monitors), and scope (all). It implicitly distinguishes from sibling 'uptrace_get_monitor' (list vs. get) and 'uptrace_list_dashboards' (monitors vs. dashboards), though it doesn't explicitly name alternatives.

  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 siblings like 'uptrace_get_monitor' (which likely retrieves a single monitor) or when listing all monitors is inappropriate. No prerequisites or exclusions are mentioned.

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

• uptrace_search_spansA
  3.6/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Mentions support for 'aggregations' but doesn't clarify return behavior (raw spans vs aggregated results), rate limits, or performance characteristics. 'Search' implies read-only, but lacks explicit safety disclosure.

  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?

  Three sentences with zero waste: first establishes purpose, second lists capabilities, third provides concrete example. Front-loaded with the essential action and resource. No redundant or filler text.

  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?

  Adequate for a 5-parameter tool with complete schema coverage, but gaps remain: no output schema exists yet description doesn't clarify return structure (list of spans vs aggregations), and doesn't explain UQL limitations or time range constraints beyond the schema definitions.

  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%, establishing baseline 3. Description adds value by contextualizing the 'query' parameter with UQL syntax explanation and a concrete working example that demonstrates the where-clause format, exceeding the raw schema documentation.

  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 verb 'Search' and resource 'spans', and identifies the UQL query language as the mechanism. Distinguishes from siblings by specifying 'spans' (vs logs/groups/services in sibling tools), though could explicitly contrast with uptrace_search_logs for clarity.

  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?

  Provides a concrete usage example ('where _status_code = "error"') showing how to find error spans, but lacks explicit guidance on when to use this versus alternatives like uptrace_get_trace or uptrace_search_logs, and doesn't mention prerequisites like time range requirements.

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

• uptrace_search_groupsA
  3.7/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 mentions supported aggregation functions (count, avg, p99) which adds context, but fails to disclose safety characteristics (read-only vs destructive), rate limits, pagination behavior beyond the limit parameter, or return value structure.

  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 consists of two efficient sentences with zero waste. It front-loads the core action ('Search and aggregate spans by groups') before detailing capabilities, making it immediately scannable for an agent selecting tools.

  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 100% schema coverage, the description adequately covers the tool's conceptual purpose. However, lacking both annotations and an output schema, the description should ideally disclose the return format (aggregated groups vs individual spans) and safety profile (read-only) to be 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 description coverage is 100%, establishing a baseline of 3. The description mentions 'GROUP BY operations' and aggregation examples that align with the 'query' parameter's UQL format, but does not add significant semantic meaning beyond what the schema already provides for time formats or limit behavior.

  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 'Search[es] and aggregate[s] spans by groups', providing specific verbs (search, aggregate), resource (spans), and method (grouping). It effectively distinguishes from sibling uptrace_search_spans by emphasizing aggregation/GROUP BY operations versus raw span retrieval.

  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?

  While the description implies this tool is for aggregated analysis (mentioning GROUP BY and aggregation functions), it provides no explicit guidance on when to use this versus uptrace_search_spans (raw spans) or uptrace_query_metrics (metrics). No 'when-not-to-use' or prerequisites are stated.

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

• uptrace_search_logsA
  3.7/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Adds crucial behavioral context that logs are implemented as spans with specific attributes (_system='log:all'), but omits other behavioral details like rate limits, pagination behavior, or return format.

  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 total with zero waste. First sentence establishes purpose and search capabilities; second sentence provides essential implementation context. Information is front-loaded and appropriately sized.

  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?

  With 6 parameters (all optional) and no output schema, the description adequately covers the conceptual model but lacks return value documentation. Given 100% schema coverage for inputs, the omission of output structure prevents a higher score.

  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%, establishing baseline 3. Description provides high-level grouping of parameters ('by text, severity, service name, or custom UQL query') but does not add detailed semantics, constraints, or examples beyond what the schema already documents.

  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?

  Specific verb ('Search') and resource ('logs') clearly stated. Explicitly distinguishes from sibling tool 'uptrace_search_spans' by clarifying that logs are represented as spans with _system='log:all', helping the agent understand the domain model and tool scope.

  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?

  Implies usage through explanation of search dimensions (text, severity, service, UQL) and log representation, but lacks explicit guidance on when to use this versus 'uptrace_search_spans' or prerequisites for the UQL query parameter.

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

• uptrace_search_servicesA
  3.7/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. While 'Search' implies read-only and 'reported spans' provides domain context, the description fails to disclose return format (list of service names? IDs?), pagination behavior, or any permission requirements.

  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 total with zero waste. First sentence defines the operation, second explains the utility. Front-loaded with the core action and appropriately sized for the tool's simplicity.

  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?

  Adequate for a single-parameter discovery tool with full schema coverage, but gaps remain given the lack of output schema and annotations. Missing description of return values (what constitutes a 'service' object?) and operational safety details that annotations would typically provide.

  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 coverage is 100% with the 'hours' parameter fully documented ('Number of hours to look back'). The description does not add parameter-specific context beyond the schema, meeting the baseline for high-coverage schemas.

  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?

  Specific verb 'Search' + resource 'services' + context 'reported spans' clearly defines the tool's function. Effectively distinguishes from sibling 'uptrace_search_spans' by clarifying this searches for services (the entities) rather than the spans themselves.

  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 usage context ('Useful for discovering available services') indicating when to use this tool. However, lacks explicit when-not-to-use guidance or named alternatives for different discovery scenarios (e.g., when to use search_groups vs search_services).

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

• uptrace_list_dashboardsA
  3.8/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 successfully discloses the return format (IDs and names) but fails to mention critical operational traits like pagination behavior, rate limits, permission requirements, or whether 'all' implies unbounded retrieval versus a default limit.

  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 short sentences with zero redundancy. The first states the action and resource; the second states the return value. Every word earns its place and critical information is 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?

  Given the low complexity (zero parameters, simple list operation) and absence of an output schema, the description adequately compensates by specifying the return payload structure. It loses a point only for omitting pagination or result limiting behavior, which is important for 'list all' operations that could return large datasets.

  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 contains zero parameters. Per evaluation guidelines, 0 params warrants a baseline score of 4. The description appropriately does not invent parameters, though it could have mentioned that no filtering is possible (confirming the schema intent).

  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 uses specific verb 'List' with clear resource 'dashboards' and explicit scope 'all'. The second sentence clarifies the specific return payload ('dashboard IDs and names'), providing precise expectations about what data is retrieved without needing to read an output schema.

  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 like the search_* siblings (e.g., uptrace_search_services) or get_* tools. It does not mention prerequisites, filtering limitations, or why one might prefer listing all dashboards versus querying specific metrics directly.

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

• uptrace_query_metricsA
  4.2/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 full burden. It discloses the query language compatibility (UQL/PromQL) which is valuable behavioral context, and 'Query'/'retrieve' imply read-only access. However, it lacks details on rate limits, pagination behavior beyond the limit parameter, or authentication requirements.

  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 with zero waste. The first establishes capability and syntax; the second provides concrete examples. Every word earns its place and critical information is 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?

  Given the moderate complexity (6 parameters, query language), 100% schema coverage, and lack of annotations/output schema, the description adequately covers the tool's domain and syntax. It could be improved by mentioning the read-only nature or result format, but it is sufficient for correct invocation.

  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?

  With 100% schema description coverage, the baseline is 3. The description adds meaningful context by specifying the UQL/PromQL syntax applies to the query parameter and providing concrete metric examples ('CPU usage') that illuminate the metrics parameter's purpose.

  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?

  Description specifies the exact action (Query), resource (metrics), and query language (UQL/PromQL). It clearly distinguishes from siblings like uptrace_search_logs or uptrace_get_trace by explicitly targeting 'metrics' rather than logs, traces, or alerts.

  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 concrete usage examples ('CPU usage, request rates') that clarify when to use this tool for metric retrieval. However, it does not explicitly state when NOT to use it or contrast with the sibling uptrace_get_query_syntax tool.

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

• uptrace_get_query_syntaxA
  4.3/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. It adequately discloses what the tool returns (operators, functions, examples, patterns) providing clear behavioral context that this is a documentation retrieval operation. However, it does not explicitly state safety characteristics (read-only) or cache behavior that annotations would typically cover.

  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 consists of two efficient sentences with zero waste. It is front-loaded with the core action ('Get UQL...documentation') and follows with specific return value details. Every word serves a purpose in clarifying scope and content.

  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?

  Given the tool has zero parameters and no output schema, the description is appropriately complete. It compensates for the missing output schema by detailing the return structure (operators, functions, examples), providing sufficient information for the agent to understand what will be returned.

  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 contains zero parameters. Per the baseline rule for zero-parameter tools, this scores a 4. The description appropriately does not invent parameter semantics where none exist.

  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 uses specific verbs ('Get', 'Returns') and clearly identifies the resource as 'UQL syntax documentation' rather than actual telemetry data. It effectively distinguishes itself from siblings like uptrace_query_metrics and uptrace_search_logs by specifying it returns documentation content (operators, functions, examples) rather than query results.

  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?

  While the description implies this is a reference tool for understanding the query language, it lacks explicit guidance on when to invoke it (e.g., 'use this before constructing queries for uptrace_query_metrics') or prerequisites. The distinction from data-retrieval siblings is clear from the name and description but not explicitly stated as usage guidance.

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