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

The readOnlyHint annotation already marks this as safe, and the description adds meaningful behavioral context: the window is [start, end), omitting end runs to the signal's last change, times accept human-readable strings or integer ticks, and the tool produces a summary rather than a list of changes. None of this contradicts 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?

The description is front-loaded with a memorable question, then moves from purpose to window semantics to alternatives. Each sentence adds information and the inline examples compress a lot of meaning without bloating the text.

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 an output schema present, the return-value details are already covered. The description supplies everything else needed to call the tool correctly: what it computes, how the window works, accepted time formats, and which sibling tools to choose instead. There are no material gaps for an agent selecting or invoking this 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 carries the burden. It fully explains the start/end semantics including inclusivity, the time formats, and the meaning of signal via repeated '<signal>' examples. The only gap is that the required 'file' parameter is never directly mentioned, though it is fairly inferable from the waveform-analysis context.

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: it summarizes a signal window with statistics, and enumerates concrete questions it answers (period, frequency, duty cycle, min/max/mean, value distribution). It also explicitly differentiates itself from waver_values and waver_latency, so an agent can tell it apart from siblings without opening schemas.

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?

It clearly explains when to use this tool ('summarizes a window instead of listing changes') and names alternatives with their conditions: use waver_values for a raw change list and waver_latency for edge-to-edge timing. This gives an agent actionable selection criteria rather than leaving inference to chance.

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=true, and the description adds useful behavioral detail: case-insensitive string matching, all-X/all-Z bus matching, and interval/duration output from start onwards. It does not disclose that `limit` can cap the returned intervals, so it is not fully transparent.

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 compact and front-loaded with concrete question examples, then adds necessary type-matching rules and routing guidance. There is no filler or redundant restatement of the schema.

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 an output schema present, return values do not need to be spelled out, and readOnly annotation covers safety. The main missing context is `limit` semantics and a bit more clarity around `file`, but an agent can still reasonably determine how to invoke the 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. It thoroughly explains `value` and partially `start` and `signal`, but `file` is not described and `limit` is never mentioned despite defaulting to 100 and affecting how many intervals are returned. This is a meaningful gap.

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 operation: find intervals where a signal equals a given value, and immediately gives concrete question forms. It also distinguishes the tool from waver_value_at, making its purpose easy to separate from siblings.

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?

It explicitly names alternatives: waver_value_at for a single time point and waver_analyze for statistics. It also gives practical matching rules for ints, strings/enums, and logic vectors, so an agent knows when and how the tool applies.

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?

Beyond the readOnlyHint annotation, it discloses the half-open [start, end) range, the pairing rule (first B edge at or after each A edge), and the exact statistics returned (min/max/mean/p50/stddev plus first/last pairs). It also warns about the binary-signal requirement for rising-edge mode, an otherwise unstated failure condition.

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?

Five short sentences deliver the metric, algorithm, output statistics, edge-mode caveat, time format, and sibling alternative without wasted words. The definition is front-loaded with the core question and then adds necessary detail.

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 an output schema present, the description covers the remaining needed guidance: selection criteria, algorithm, statistical outputs, constraints, and when to use an alternative. The unstated file semantics are a minor shared convention and do not block correct invocation.

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 supply meaning for a, b, edge, start, and end; it does, including time formats and edge-mode constraints. However, the file parameter is left implicit and the meaning of null end is not stated, so it does not fully compensate for all six 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 opening question and restatement define the exact metric: propagation delay from an edge of signal A to the corresponding edge of signal B. It also distinguishes itself from waver_analyze by explicitly noting that the sibling is for one signal's own timing.

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?

It lists the natural-language queries this tool answers and explicitly routes single-signal timing questions to waver_analyze. It also gives conditional guidance for edge='rise' (binary signals only) vs edge='any' (any change), telling the agent when each mode is appropriate.

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 mark this as read-only. The description adds sequencing and contextual behavior: it is a first-step inspection call whose reported timescale/duration affect subsequent waver_* windows. It does not fully detail state/error behavior, but the read-only annotation lowers the burden.

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 short and front-loaded with the core purpose, followed by usage guidance and a sibling pointer. The opening rhetorical question is slightly redundant with the next sentence, but the overall structure is efficient.

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 simple one-parameter read-only tool with an output schema, the description is largely complete: it covers what the tool does, when to invoke it, and how it relates to sibling tools. It leaves out explicit file-format constraints, though this is a minor 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?

The single required 'file' parameter has 0% schema description coverage, so the description must compensate. It adds that the file is a waveform file and gives FST as an example, but it does not clarify path expectations, accepted formats beyond FST, or how the parameter relates to the reported duration/timescale.

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?

Description clearly identifies waver_open as the tool that opens/inspects an unexamined waveform file and reports contents, simulation duration, and timescale. It also distinguishes itself from waver_search, which lists individual signals, so an agent can tell it apart without inspecting schemas.

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?

States an explicit precondition: call it first for any file not yet inspected. It explains that the resulting timescale and duration frame every window passed to other waver_* tools, and points to waver_search as the alternative for listing signals.

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=true, and the description adds substantial behavioral detail: lane rendering for different signal types, X/Z shading, decimation to ~10000 points, and the fact that the PNG is written to a temp file whose path appears in the summary. This exceeds what annotations alone provide and helps an agent predict the tool's output format and side effects.

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 dense but every sentence carries useful information: intended use, rendering behavior, time format, decimation, return payload, and alternatives. It is well front-loaded with the core purpose and avoids filler.

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 absence of an output schema, the description explains the return value (image plus summary with temp-file path) and the decimation behavior. It covers the main parameter semantics, usage conditions, and sibling-tool differentiation well enough that an agent can correctly select and invoke the 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. It adds valuable meaning for start/end (human-readable or integer ticks, half-open interval) and signal rendering behavior. However, it does not explicitly describe the `file` parameter or the exact signal naming syntax, though these are partially inferable from context.

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 opens with a concrete verb and resource: it plots signals as a PNG in a specified window. It also answers natural-language queries and describes per-signal rendering rules, making the tool's function unambiguous and distinguishable from waver_analyze and waver_values.

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?

It explicitly states when to use the tool ('show me <signal(s)> around time A'), and gives alternatives for statistics and exact values ('For statistics use waver_analyze; for exact values use waver_values'). It also clarifies window semantics and the effect of omitting end, leaving no ambiguity about invocation conditions.

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?

Beyond the readOnlyHint annotation, the description reveals behavior that affects agent expectations: matching is case-insensitive, nothing is decoded, operation is fast even on large files, and returned names are full names or unique suffixes. This is exactly the kind of non-obvious behavioral context that annotations cannot convey.

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 tight and front-loaded: it opens with the core question, then adds matching behavior, output semantics, and performance in just a few sentences. Every sentence contributes useful information with no filler.

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 simple listing/search tool, the description covers the essential purpose, filtering behavior, output-name semantics, and performance characteristics. An output schema exists, so return-value details are not required here, and the tool has no nested parameters or complex prerequisites.

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?

With 0% schema description coverage, the description must compensate, and it does explain the `pattern` parameter well ('case-insensitive substring') and contextualizes `file` as a waveform/FST file. However, the `limit` parameter is never mentioned or described, leaving a clear gap for an agent trying to understand result truncation.

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 opens with a concrete question, 'Which signals are in this waveform file?' and then explicitly answers the two use cases: listing all signals and checking for a signal named X. It also clarifies that this tool returns signal names that are compatible with sibling value/analysis tools, making its distinct role clear.

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 gives clear context: use it for header-only signal listing, especially on large designs, and pass a pattern to narrow results. It does not explicitly name alternatives or state when not to use it, but the 'header-only' note implies that value decoding is outside this tool's scope.

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?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: it returns the last change at or before the time, accepts human-readable or tick times, and handles past-end time by returning the last recorded value with a flag. These boundary behaviors are genuinely useful and not inferable from the schema. No contradiction with 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?

The description opens with a clarifying question, then packs key usage details, parameter semantics, edge-case behavior, and the sibling alternative into a compact block. Every sentence adds information; there is no filler or redundancy.

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 read-only point-query tool with an output schema and readOnlyHint, the description covers the core semantics, time formats, edge-case behavior, and the relevant alternative. Nothing essential for selecting and invoking the tool is missing, and the output schema handles return-value details.

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?

With 0% schema description coverage, the description compensates by explaining 'time' in detail (human-readable vs integer file ticks) and clarifying that 'signals' supports multiple signals in one call. The 'file' parameter is not elaborated, but its meaning as the waveform file is reasonably inferable from the tool family context. Significant value added over 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?

The description gives a precise question form ('what was <signal> at 10ns?') and states the exact resource and behavior: returning the value held at that instant. It also differentiates itself from waver_values by explicitly saying waver_values covers a whole window of changes. This is a specific, non-tautological definition.

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?

It clearly identifies when to use this tool ('Answers what was <signal> at time X') and explicitly directs to waver_values for a whole window of changes, naming the alternative. Batch usage is also explained. This gives an agent actionable selection guidance beyond the tool name.

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 only convey read-only safety, so the description carries the burden of behavioral disclosure. It explains the half-open interval, optional end, human-readable time parsing, hex representation for wide values, and preservation of X/Z/enum/string values. This is rich, non-obvious behavior beyond the structured fields.

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 dense, well-organized, and front-loaded with the core purpose. The only flaw is minor redundancy: the opening question 'What values did this signal have...' is immediately restated as 'Answers "what did <signal> do between A and B?"'. All later sentences add distinct value.

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 output schema exists, return-format details are not required. The description covers the key invocation semantics: time parsing, interval bounds, optional end, value formatting edge cases, and routing to sibling tools. An agent has enough context to call the tool correctly, including sensible handling of defaults like start=0 and max_changes=1000.

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?

With 0% schema description coverage, the description compensates well for start and end: it defines accepted time formats, window inclusivity, and optional end. However, max_changes is not explained beyond its title, and file/signal are left to inference, though those are largely self-evident from the tool's purpose.

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 clear verb and resource: it retrieves signal values over a time window, answering 'what did <signal> do between A and B?'. It also distinguishes itself from siblings by pointing to waver_analyze for statistics and waver_value_at for a single time point.

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?

It explicitly names alternatives and the conditions that select them: 'For statistics instead of a change list, use waver_analyze; for one time point, waver_value_at.' It also gives concrete usage rules: time formats are human-readable or integer file ticks, the window is [start, end), and omitting end runs to the last change.

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