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

No annotations are provided, so the description carries the full behavioral burden. It discloses that results include detailed error messages, stack traces, and LLM-specific error information, which adds some transparency about output content. However, it does not state whether the operation is read-only, what permissions are required, or how pagination/limits behave beyond the limit parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with the purpose and structured with Args/Returns sections, making it easy to scan. It is appropriately sized. The Returns section is somewhat redundant because an output schema exists, but it does not detract much from overall conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity, four parameters, and an output schema, the description is adequate but has gaps. It covers purpose, parameters, and return format. However, it lacks usage guidance relative to sibling tools and does not disclose behavioral traits such as read-only safety, which is more important because no annotations are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate; it does so for all four parameters. It gives time format (ISO 8601), explains service_name as a filter, and defines limit as the maximum number of error traces with a default of 100. It could add more detail (e.g., timezone, inclusive/exclusive bounds), but it substantially covers the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Find traces with errors.' This distinguishes it from generic trace searching siblings like search_traces. However, it does not explicitly differentiate itself from search_traces or get_trace, so an agent must infer the distinction.

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

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 such as search_traces or get_trace. It does not mention prerequisites, exclusions, or contextual conditions for selection. Usage is only implied by the tool's purpose.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the sort order (top N by total token usage) and threshold semantics, but says nothing about permissions, pagination, rate limits, or whether only LLM-instrumented traces are considered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loads the purpose, then args, then returns, with no redundancy. 'Useful for cost optimization' is mild filler but earns its place by hinting at usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, annotation-free tool this covers each parameter acceptably, and the output schema exists so return-value detail is not required. Missing behavior-level notes (auth, default time window when start/end are omitted) keep it short of 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the prose must compensate, and it does: ISO 8601 format with an example, min_tokens threshold behavior, and the request-vs-response model distinction. The only shortfall is repeating the schema's default for limit without adding new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Find traces with highest LLM token usage,' with a clear sort criterion (total token usage). However, it does not distinguish itself from near-identical siblings like get_llm_slow_traces or get_llm_usage, so an agent must infer the boundary.

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

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

'Useful for cost optimization and identifying inefficient prompts' implies a use case but names no when-not conditions and no alternatives. With get_llm_slow_traces and get_llm_usage as obvious siblings, the lack of routing guidance is a real gap.

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

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

With no annotations, the description carries the full burden. It discloses the metrics computed and that a JSON string is returned, and the 'Get ... statistics' framing implies a read-only analysis. However it says nothing about cost of the query, permissions, or behavior when start_time/end_time are omitted, which matters for a query tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with the purpose, then cleanly delimited Args/Returns blocks. The metric enumeration is slightly padded, but nothing is genuinely wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the Returns line need not document the response shape, and the description correctly focuses on purpose and input formats. It misses default time-window semantics and any note about how the result is scoped, which is a modest gap for a 4-parameter analytics tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: all four parameters are named with formats (ISO 8601 for the time bounds) and concrete model-name examples. The gap is that it never states what a null/default time bound means (e.g. all time).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get detailed performance statistics for a specific LLM model') and enumerates the metrics covered (latency percentiles, token usage, error rates, finish reasons). It is clearly distinguishable from list_llm_models, but it does not explicitly contrast itself with the closest sibling get_llm_usage.

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

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

There is no explicit when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as get_llm_usage or get_llm_slow_traces. Usage is only implied by the phrase 'for a specific LLM model.'

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

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 that results are sorted by duration and capped at a limit, which implies a read-only operation, but says nothing about permissions, rate limits, or whether traces are truncated. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded one-line purpose followed by use case and parameter list; the Args/Returns structure is scannable. The parameter block is somewhat long but each entry is terse and earns its place given 0% schema coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained in depth, and the description still notes the top-N-descending result shape. Combined with full parameter coverage and a mutation-free profile, an agent has enough to call this correctly; only sibling routing is left wanting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate — and it does, documenting all 7 parameters with formats and examples (ISO 8601 for time, 'gpt-4' / 'gpt-4-0613' for the model params, default 10 for limit). It adds meaning the bare schema lacks, though it omits any clarification of the request vs. response model distinction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Find slowest LLM traces by duration' — an agent immediately knows this returns traces ranked by latency. It distinguishes itself from get_llm_expensive_traces by emphasizing duration/latency rather than cost, though it never names that sibling explicitly to make the differentiation airtight.

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

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

'Useful for performance optimization and identifying latency bottlenecks' implies the when-to-use context, but gives no explicit exclusions or alternatives. With siblings like get_llm_expensive_traces and find_errors in the same family, the agent must infer the routing itself.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses aggregation behavior, breakdown dimensions, and that limit controls traces analyzed, which helps. However, it does not state read-only safety, permissions, pagination, or other operational constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is front-loaded with purpose, then structured into Args and Returns. It is efficient overall, though the Returns line is somewhat redundant given that an output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given seven optional filters and no annotations, the description covers the core operation and parameter meanings. It remains incomplete for agent routing because it lacks when-to-use guidance versus siblings and does not clarify optionality/defaults beyond limit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It documents all seven parameters with meanings, including ISO 8601 time formats, filter semantics, and the default limit of 1000. This adds substantial value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Get aggregated LLM usage metrics (token counts) for a time period,' and adds breakdowns by model and service. It does not explicitly distinguish itself from similar siblings like get_llm_model_stats, 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.

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

Provides no when-to-use guidance, no prerequisites, and no alternatives. It implies the tool is for usage metrics, but an agent must infer when to choose it over sibling tools such as get_llm_model_stats or get_llm_expensive_traces.

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

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

No annotations are provided, so the description carries the burden, and it does disclose the payload shape (all spans with attributes, parsed OpenTelemetry data for LLM operations). It omits any read-only framing, error behavior for an unknown/expired trace ID, or size/truncation characteristics, which matters for a tool that returns an entire trace.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The core purpose is front-loaded in the first sentence and the rest is compact. The Args/Returns boilerplate duplicates what the schema and output schema already convey, costing a little efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so explaining return values is redundant but harmless, and the description's core claim (full trace with spans and parsed OTel data) is adequate. It leaves gaps around failure modes and the read-only/non-destructive nature that an agent would want before invoking a whole-trace retrieval.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only restates the parameter as 'Trace identifier', adding no format, origin, or example information beyond the schema. With one parameter on which lookup success depends, this is under-specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb + resource ('Get complete trace details') and the retrieval key ('by trace ID'), which cleanly separates it from the search-oriented sibling search_traces. It never names a sibling explicitly, so it stops 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.

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 search_traces or search_spans_tool, and no prerequisite or exclusion conditions are stated. The 'by trace ID' phrasing implies a lookup use case, but the agent must infer that from the name and schema alone.

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

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 usefully discloses the trace-scanning behavior via the limit parameter ('Maximum traces to analyze for model discovery') and describes the return shape (count, request_count, first_seen, last_seen), but says nothing about permissions, read-only status, or whether the trace scan is expensive/rate-limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loads the purpose before the Args/Returns blocks and uses clean sections. The second sentence ('Discovers what models are deployed and tracks their usage patterns') largely restates the first, a minor redundancy, but overall the text is well-sized and earns its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be re-explained, yet the description still summarizes them concisely. All five params are documented despite 0% schema coverage. The only real gap is behavioral context (no annotations, no permission or sibling-routing guidance), which keeps it short of a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does: each of the five parameters gets a meaning, ISO 8601 format guidance with an example, a provider example list (openai, anthropic, cohere), and the limit default. Format and filtering semantics are clear even though it does not explain null/default behavior for the optional filters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list LLM models) plus scope ("being used with usage statistics") and adds the intent "discovers what models are deployed and tracks their usage patterns." However, it never distinguishes itself from the near-identical sibling get_llm_model_stats, so an agent cannot route between them from the description alone.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternative tools. With siblings like get_llm_model_stats and get_llm_usage in the same family, the absence of any disambiguation leaves selection to guesswork; only the implicit 'discovery' framing hints at context.

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

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

With no annotations, the description carries the full behavioral burden but only states the output format. It does not disclose whether the operation is read-only, whether it has side effects, permissions required, or performance characteristics beyond the limit parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is well-structured, front-loading the purpose, then listing args and returns. It is appropriately sized, though the Returns section is somewhat redundant given the output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (5 optional params, output schema exists), the description covers purpose, parameters, and return format adequately. The main omission is usage guidance, but the core information needed to invoke the tool is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides meaningful details for each parameter, including ISO 8601 examples for start_time and end_time, filter semantics for service_name and gen_ai_system, and the default and purpose of limit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('List all LLM tools being used') and explains the identifying mechanism ('traceloop.span.kind == tool'). It clearly distinguishes this from sibling tools like list_llm_models or search_traces by focusing on tool/function calls made by LLM applications.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as list_llm_models or get_llm_usage. The purpose implies usage, but no conditions or exclusions are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden; it discloses the return type ('JSON string with list of services') but says nothing about ordering, pagination, authorization requirements, or failure behavior. For a no-argument read-only lister the risk is low, but the disclosure is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short lines with the purpose front-loaded and no filler. The 'Returns' block is mildly redundant given an output schema exists, which keeps it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters, an output schema present, and a trivial read operation, the definition covers what an agent needs to invoke it. The only real omission is guidance on when to reach for this tool versus the trace- and span-oriented siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric this is the baseline 4. There are no arguments whose semantics the description would need to explain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List all available services') and scopes it to the OpenTelemetry backend, which is enough to separate it from sibling tools that operate on traces, spans, and LLM models. It does not explicitly name a sibling it differs from, 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.

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

There is no explicit when-to-use or when-not-to-use statement and no named alternative, but the tool is a zero-argument discovery lister whose purpose implies the usage (enumerate services before filtering traces by service). Adequate but the definition never tells the agent to call this first or what to do with the result.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the limit range (1-1000, default 100) and the return format ('JSON string with span summaries'), but says nothing about pagination, ordering, or permission/auth requirements for a 13-parameter query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded summary and the args list is well-organized and justified by 13 undocumented parameters, though the Returns and Example blocks add modest length beyond the essentials.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values needn't be spelled out, and the description covers all parameters plus the sibling comparison. It is nearly complete for a read-only search tool, with pagination/ordering behavior the main omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: every one of the 13 parameters is documented with meaning, format (ISO 8601, dotted notation), examples ('gpt-4-0613', openai/anthropic), and the nested filter object's field/operator/value/value_type structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Search for individual OpenTelemetry spans') and explicitly differentiates from the sibling search_traces by explaining it returns individual spans rather than grouped traces.

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

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

Names the alternative (search_traces) and the condition that selects this tool instead, plus a concrete use case (finding spans with traceloop.span.kind == tool). An agent can route correctly without opening either schema.

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

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 implies a read-only search and documents the limit default (100) and range (1-1000), but says nothing about ordering, pagination, or result shape beyond 'JSON string with search results'. Adequate but thin for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Front-loaded with purpose, then a structured Args block and concrete examples. It is long, but given the 0% schema coverage the per-parameter documentation is earned rather than redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is unnecessary, and the description covers all 13 params including the nested filter semantics. The remaining gap is the lack of sibling differentiation and pagination/ordering behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: every one of the 13 parameters is documented in the Args block, and the complex 'filters' object is fully spelled out with field/operator/value/values/value_type and worked examples. Slightly marked down only because 'tags' is left vague.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (search OpenTelemetry traces) and adds a useful scope note about simple vs. generic filter modes. It does not, however, distinguish itself from near-siblings like search_spans_tool or find_errors, so an agent must infer the boundary.

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

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

Gives parameter-level guidance ('use filters for advanced queries') but no tool-level guidance about when to prefer this over find_errors, get_trace, or the LLM-specific trace helpers. Usage is implied by the filter list rather than stated.

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