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

With readOnlyHint/idempotentHint already covering the safety profile, the description adds real behavioral context: failure on no matches, the per-trace span cap, and the semantics of truncated=true (early prefix). It stops short of naming the cap value or suggesting a follow-up when truncated, keeping it from a 5.

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?

Three tight sentences: what is returned, what failure looks like, then the truncation caveat. No filler and the core behavior is front-loaded.

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 single-parameter read tool with no output schema, the description covers return contents (spans plus service.name), the error case, and the truncation edge case. Minor gaps remain around the cap size and span ordering, but nothing critical to calling it correctly is missing.

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 100% and the single traceId parameter is fully documented in the schema (32-char lowercase hex). The description adds nothing beyond 'the given trace id', so the baseline 3 applies — the schema does all the work here.

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 uses a specific verb+resource ('Return every span belonging to the given trace id') and additionally states the enrichment ('each span's resource service.name'). This clearly separates it from query_traces or list_trace_services, though it never names those siblings explicitly.

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?

Usage is implied by the required traceId ('the given trace id'), and the error condition when no spans match is stated. However, there is no explicit guidance on when to prefer this over query_traces for trace lookup, nor any prerequisites mentioned.

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?

Annotations already cover readOnlyHint and idempotentHint, so the bar is lower, and the description still adds genuinely useful behavior: results are de-duplicated ('distinct') and deterministically ordered ('sorted alphabetically'). It omits edge-case behavior such as what happens with an empty window or whether the list is capped, keeping it short of a 5.

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 sentences, front-loaded with what is returned before the ordering detail. Every clause carries information; nothing is repeated from the schema or annotations.

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 two-parameter read-only listing tool with no output schema, the description effectively characterizes the return value (distinct service names, alphabetical) so an agent knows what it gets. Minor gaps around empty-result and list-size behavior are the only missing pieces.

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 100% and both parameters are fully documented (ISO-8601 UTC, to > from). The description only restates that the pair forms a UTC window, adding little beyond the schema, so the baseline 3 applies.

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 the exact resource ('distinct service.name values') and scopes it to log records inside a UTC window, which implicitly separates it from list_metric_services and list_trace_services. It doesn't explicitly name those siblings, so differentiation is inferable rather than stated.

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?

Usage is only implied: the window scoping suggests this is a discovery/enumeration tool to run before query_logs, but the description never says when to use it, when not to, or what alternative to pick. An agent must infer the discovery workflow from the return shape 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?

The readOnlyHint and idempotentHint annotations already establish the safety profile. The description adds useful return-value context by naming the point count, originating service, and key fields, but does not cover pagination, ordering, or scale considerations for enumerating all instruments.

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 tightly written sentences front-load the tool's purpose and then explain the key linkage to query_metric_points. Every sentence carries useful information without repetition.

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 zero-parameter listing tool without an output schema, the description does a good job explaining the returned fields and the key structure. It could be slightly more complete by mentioning pagination or whether the full store is always returned, but the core context 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?

This tool has zero input parameters, so there is no parameter semantics to explain. The baseline score for a parameterless tool applies.

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 that this tool returns every instrument in the store along with point count and originating service, giving a specific resource and return content. It connects to query_metric_points but does not explicitly distinguish itself from list_metric_services, so sibling differentiation is incomplete.

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 second sentence implies that the returned four-field key is used by query_metric_points, which gives some usage context. However, it does not explicitly say when to use this tool versus list_metric_services or query_metric_points, leaving the guidance implied rather than 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?

Annotations already declare readOnlyHint and idempotentHint, so safety and repeatability are covered. The description adds one useful behavioral detail beyond annotations: results are sorted alphabetically. It does not describe return shape, empty-result behavior, or any scoping/pagination behavior.

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 sentences, both front-loaded with the essential output description and ordering. No filler or repetition; every phrase contributes information.

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 zero-parameter, read-only list tool with annotations and no output schema, the description is nearly complete: it tells the agent exactly what values come back and how they are ordered. The only minor gap is that it relies on 'recorded instruments' rather than explicitly naming metrics.

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?

This tool takes zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the schema is empty as expected for a pure enumeration endpoint.

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 the resource precisely: distinct service.name values, with the source identified as 'recorded instruments' and the output ordering given. It is distinguishable from list_log_services and list_trace_services by its instrument/metric framing, though it never explicitly says 'metrics' and omits a leading verb.

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 when-to-use guidance, no prerequisite context, and no routing to alternatives such as list_log_services, list_trace_services, or query_metric_points. The intended use is only implied by the tool name and resource description.

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?

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds real behavioral context beyond that: results are distinct service.name values, the window is evaluated against each trace's earliest span, and output is alphabetically sorted.

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 sentences, zero waste. The core operation is front-loaded and the ordering guarantee follows as a short trailing clause.

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 no output schema, the description compensates by describing what comes back (distinct service.name values, alphabetically sorted). The only minor gap is that no sibling or pagination/edge-case guidance is included, but nothing essential to correct invocation is missing.

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 100%, so both params are documented and a 3 baseline applies. The description goes beyond that by clarifying that the from/to window filters on the earliest span timestamp rather than any span, which is meaningful semantic information not present in the 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+resource: distinct service.name values attached to traces, with the window defined by earliest span and an ordering guarantee. The word 'traces' implicitly distinguishes it from list_log_services and list_metric_services, though those siblings are never named explicitly.

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 scope statement ('traces whose earliest span falls inside the given UTC window') implies when the tool applies, but there is no explicit when-to-use or when-not guidance and no reference to query_traces or the sibling service-list tools as alternatives.

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?

Annotations already declare readOnly and idempotent, so the safety profile is covered. The description adds non-obvious behavior: results are ordered by timestamp descending and pagination is keyset-based via a 'nextCursor' token, which is genuinely useful beyond the annotations. It stops short of stating the concrete default/max limit values or any rate limits.

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 tight sentences with zero filler; the ordering guarantee is front-loaded before the pagination note. Every clause carries information an agent needs.

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 no output schema the description usefully names the 'nextCursor' field, which is the one return detail an agent must know to page. For a 7-parameter filtered query tool this is nearly sufficient, though a note on default page size or the existence of service/trace/severity filters would close the gap.

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 100%, so every parameter including cursor, limit and the severity filter is already documented in the schema. The description only echoes the cursor contract already present, adding no new per-parameter semantics. Baseline 3 applies.

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 log records') scoped to a UTC time window with an explicit ordering. The resource noun separates it from query_traces and query_metric_points, though it never names those siblings directly.

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?

Usage is implied: call this to enumerate log records in a window. It explains pagination mechanics but gives no explicit when-to-use versus query_traces or when to reach for list_log_services instead of filtering by service here.

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?

Annotations establish readOnly/idempotent, and the description adds genuinely non-obvious behavior: a server-side cap can truncate results, and truncated=true means the returned points are an early prefix rather than the full window. That is the key caveat an agent needs before drawing conclusions from partial data. It does not mention ordering or what a point object looks like, keeping it from a 5.

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?

Three sentences, front-loaded with what is returned and the identity key, then the prerequisite, then the truncation caveat. No filler or restatement of the tool name.

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 no output schema, the description still covers the essential return semantics (points plus a truncation flag) and the discovery prerequisite. Minor gap: it says nothing about point ordering or how to page past a truncated window, which an agent would need for complete coverage of a capped result set.

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 100% and each parameter already carries a description including enum-free kind values and the empty-string anonymous scope. The description adds only the framing that the four fields together form a key and that the window must be UTC — modest value on top of a fully documented schema, so the baseline 3 applies.

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 and resource: 'return the points of a single instrument time-series', with the exact composite key that identifies it. It is easily distinguished from list_metrics (discovery) and from the query_logs/query_traces siblings, which target different signal types.

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?

'Use list_metrics first to discover the four-field key' names the prerequisite discovery step and the sibling that supplies it. No explicit when-not-to-use guidance, but for a lookup tool gated on a composite key the sequencing instruction covers the main misuse risk.

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?

Annotations already cover the safety profile (readOnly, idempotent), and the description adds real behavior: deterministic ordering by start time descending and a keyset pagination contract. It still omits whether the window is inclusive/exclusive and that results are summaries rather than full spans, but it adds meaningful context beyond the annotations.

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 sentences, zero filler, with the core purpose and ordering front-loaded before the pagination detail. Every clause carries information an agent needs.

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?

There is no output schema, and the description partially compensates by naming the summary return type and the nextCursor field. Combined with the fully documented input schema, an agent has enough to call it correctly; only window-boundary semantics are left unstated.

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 100%, so baseline is 3, but the description adds value by pairing the input 'cursor' with a 'nextCursor' continuation token that exists only in the response, clarifying the pagination loop. It does not restate the limit defaults or service filter semantics, which the schema already handles.

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 trace summaries'), the scoping condition (UTC time window), and the sort order (start time descending). It is clearly distinct from get_trace (single trace) and list_trace_services, though no sibling is named explicitly.

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?

Usage is only implied: the tool is for browsing traces within a window. There is no explicit when-to-use/when-not-to-use guidance and no pointer to get_trace for full trace detail, which is the obvious companion. The pagination sentence does signal a follow-up call pattern.

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