Skip to main content
Glama
Sign In
wtf-wave

wtf-wave

by xtrollyj00
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

find

Read-only

Search VCD, FST, and GHW waveforms for cycle or edge times where a SystemVerilog expression holds; list matching times, show signal values, or count matches.

Instructions

When a search expression holds, as a table of times; show adds values, count_only counts. With @<clock> first, a match is a cycle whose ending edge samples it true (@clk x: the cycles x is high), reported at the cycle's start; without, where it becomes true (rose(x): x's edges). A bus: decode it (help decode).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "expr": "<expr>"
    },
    "name": "find"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoStop at this time (with `backward`, down to it); default the end.
exprYesA search expression as in SystemVerilog: `==` `!=` `<` `&&` `||` `!`; only `rose(x)` `fell(x)` `stable(x)` `past(x)` (SVA's, no `$`); `@<clock> ` first samples each cycle: `@top.clk valid && ready`, `rose(irq) && !past(busy)` (`help expressions`).
fromNoSearch after (or with `backward`, before) this time; default the start.
showNoSignals whose values to list on each match: a table of the transfers.
unitNoThe unit of the answer's times, `ns`, `us` (`help times`).
countNoHow many lines to list; default 20.
backwardNoSearch toward the start: the latest matches first.
count_onlyNoOnly count the matches; no list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.0
    • changedInput schema / properties / expr / description
      Previous value: -"A search expression, `@clk valid && ready` (`help expressions`)."New value: +"A search expression as in SystemVerilog: `==` `!=` `<` `&&` `||` `!`; only `rose(x)` `fell(x)`\n`stable(x)` `past(x)` (SVA's, no `$`); `@<clock> ` first samples each cycle:\n`@top.clk valid && ready`, `rose(irq) && !past(busy)` (`help expressions`)."
    • changedInput schema / properties / unit / description
      Previous value: -"As for `values`."New value: +"The unit of the answer's times, `ns`, `us` (`help times`)."
  2. First observedv0.3.0

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: with an `@<clock>` prefix a match is a cycle whose ending edge samples the expression true and is reported at the cycle start, whereas without it the match is reported where the expression becomes true. It says nothing about cost on large traces, result volume beyond the schema's count default, or error behavior.

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

Conciseness3/5

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

The description is short, but its density works against it: it opens with a conditional clause rather than a plain statement of what the tool does, and crams clock semantics, reporting timing, and bus handling into two sentences. No sentence is filler, yet the ordering and compression make it harder to parse than a longer but better-structured version would be.

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?

This is a complex eight-parameter waveform search with no output schema, so the description carries real weight; it covers expression semantics and match-time reporting but omits what a result row looks like when `show` is used, how the default 20-line listing behaves, and any notion of runtime cost on long traces. It is enough to attempt a correct call, but not enough to predict the response shape or scale limits.

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%, so each of the eight parameters is already documented, and the description largely restates `show` ("adds values") and `count_only` ("counts"). It does add meaning for `expr` by explaining the two matching regimes and the supported operator/function subset (`rose`, `fell`, `stable`, `past`), which goes beyond the schema. `from`, `to`, `backward`, `unit`, and `count` receive no additional context beyond the schema text.

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

Purpose3/5

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

The phrase "When a search expression holds, as a table of times" conveys that the tool evaluates an expression against a trace and returns matching times, but it is buried in telegraphic phrasing rather than a plain verb+resource statement. It distinguishes its own reporting modes (`show` adds values, `count_only` counts) but gives no signal about how it differs from siblings like `view`, `values`, or `signals`. An agent can guess the purpose, but only after parsing dense jargon.

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?

There is no explicit when-to-use or when-not-to-use guidance relative to alternatives; the agent is never told why it would call `find` instead of `view` or `values`. The only routing hint is a pointer to `help decode` when the searched signal is a bus, and to `help expressions` for syntax. That is a documentation pointer, not usage guidance.

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

Deploy Server

Other Tools