waver-mcp is a read-only MCP server that measures and analyzes waveform files (FST/VCD), returning self-describing text results and PNG plots.
waver_open — Inspect a waveform file: format, writer, timescale, duration, and signal counts.
waver_search — Find and list signals by case-insensitive substring, with full names and type tags.
waver_values — List the values/changes a signal had over a time window.
waver_value_at — Get the value of one or more signals at a specific time.
waver_analyze — Compute clock frequency/period/duty, pulse widths, X/Z time, real min/max/mean, and value distributions.
waver_latency — Measure edge-to-edge timing between two signals (min/max/mean/p50/stddev and sample pairs).
waver_find — Find when a signal equals a given value (including strings, enums, hex, and X/Z buses) with held intervals.
waver_plot — Generate PNG waveform plots with one lane per signal, X/Z shading, and decimation for large files.
Times are human-readable (e.g. "10ns") or file ticks; windows are [start, end); signals support case-insensitive unique suffixes.
Read-only, stateless, headless: every tool takes the file path and only decodes queried signals; configurable via env vars (WAVE_MCP_*).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@waver-mcp plot the clk signal from 10ns to 20ns as PNG"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that measures waveform files (FST and VCD) — not just reads them.
Where other waveform MCPs hand the LLM raw change tables and leave it to
count cycles and do arithmetic, waver-mcp answers the question directly:
clock period / duty / frequency, X/Z time, A→B latency statistics,
"when was the signal equal to V" (including strings, enums and X/Z buses),
and PNG plots the model can actually see. Times are addressed as "10ns",
not as indices into a time table.
Read-only, headless, stateless: every tool takes the waveform file path, there is no "current file". Built on pywellen (the Rust wellen reader), so only the signals you actually query are decoded from the file.
waver_analyze — "what's the frequency of this clock?":
file: /path/to/all_types.fst
signal: tb_wave.clk (matched 'clk')
window: [0ns, 995ns)
changes: 200
clock:
duty: 49.75% high, 50.25% low
high pulse: 5ns
low pulse: 5ns
period: 10ns (median of 99 cycles, min 10ns, max 10ns)
frequency: 100MHzwaver_find — "when is the FSM in RUN?":
file: /path/to/all_types.fst
signal: tb_wave.state (matched 'state')
value: "run"
matches: 33 (showing 5)
5ns held for 10ns
35ns held for 10ns
65ns held for 10ns
95ns held for 10ns
125ns held for 10ns
truncated after 5 — narrow with start='...' or raise limitwaver_latency — "how long from the clock edge to the state change?":
file: /path/to/all_types.fst
a: tb_wave.clk (20 edges)
b: tb_wave.state (11 edges)
window: [0ns, 100ns)
pairs: 20 (each a edge -> first b edge at/after it)
min: 0ns
max: 5ns
mean: 2.25ns
p50: 0ns
stddev: 2.49nsOutput is deliberately self-describing for LLMs: file/signal/window
headers, truncation notices that say the next step, and errors that steer
to the right sibling tool. waver_plot additionally returns the PNG as
MCP image content, so vision clients see the waveform inline.
Related MCP server: wavekit-mcp
All waver_*, all read-only:
Tool | Answers |
| What is in this file? (format, writer, timescale, duration, signal counts). Call it first for a new file. |
| Which signals are there? (full names with |
| What values did this signal have in this window? (change list + entering value) |
| What was X at time T? (batch: several signals, one call) |
| How fast / how long / how much? (period, duty, pulse widths, X/Z time, real min/max/mean, top-10 value distribution) |
| How long from A's edge to B's edge? (min/max/mean/p50/stddev + first/last pairs) |
| When was the signal equal to V? (held intervals with durations; strings/enums case-insensitive, |
| Show me. (PNG, one lane per signal, X/Z spans shaded, decimated to ~10k points/trace) |
Zero-install via uvx — builds an
isolated environment from git (no PyPI release yet; once published, plain
uvx waver-mcp works):
uvx --from "git+https://github.com/ru551n/waver-mcp.git" waver-mcp
# shorthand (single entry point, so uvx infers the command):
uvx "git+https://github.com/ru551n/waver-mcp.git"MCP client configuration (stdio; works with any MCP client):
{
"mcpServers": {
"waver": {
"command": "uvx",
"args": ["--from", "git+https://github.com/ru551n/waver-mcp.git", "waver-mcp"]
}
}
}To run from a checkout instead:
{
"mcpServers": {
"waver": {
"command": "uv",
"args": ["run", "--directory", "/path/to/waver-mcp", "waver-mcp"]
}
}
}Or install the tool persistently instead:
uv tool install "waver-mcp @ git+https://github.com/ru551n/waver-mcp.git"then use "command": "waver-mcp" in the client config.
Var | Meaning | Default |
| default | 1000 |
| LRU of open waveform files | 4 |
| default signal-list size for | 100 |
The original WAVE_* names (e.g. WAVE_MAX_ROWS) are still accepted as
a deprecated fallback; WAVE_MCP_* wins when both are set.
Times — "10ns", "1.5us", "2ms" (fs / ps / ns / us / µs / ms / s,
case-insensitive), or a bare integer in the file's time ticks (see the
timescale reported by waver_open). Windows are [start, end); omit
end to run to the end of the file or the signal's last change.
Signal names — case-insensitive full names, or unique dot-separated
suffixes: clk matches tb.dut.clk (and the result says so). Matching
is component-aligned, so clk does not match tb.clk_buf.
Values — decimal or 0x… for ints (≥ 32-bit signals are shown in
hex), case-insensitive strings/enums, "x" / "z" for an all-X /
all-Z logic vector.
The measurement layer is vectorized (numpy over each signal's packed
change list); signals are decoded on first use and cached per open file.
On the repo's ~400k-change bench fixture (tools/bench.py):
Operation | Time |
Cold open | ~5 ms |
Warm | ~0.5 ms |
Warm | ~4 ms |
| ~140 ms |
CI enforces budgets on Linux (cold open < 100 ms, warm values < 20 ms,
warm analyze < 50 ms) via the opt-in perf-gate tests
(pytest -m perf).
skills/waver-mcp/SKILL.md teaches an agent
when and how to use the server: the question-framed tool table, workflows
(including the VUnit failure escalation — vunit_get_test_log →
vunit_get_test_waveform → waver_open → waver_find /
waver_analyze → waver_plot), and an explicit use / don't-use policy
(waver-mcp is read-only: it cannot run or re-run simulations).
Python >= 3.10 (CPython; pywellen has no Windows wheels, so Windows is not supported)
FST and VCD waveform files (FST e.g. from nvc -r --wave=out.fst, VCD e.g.
from ghdl -r --stop-on-failure --wave=wave.vcd or recorded by
vunit-mcp with waveform_format;
the reader auto-detects the format)
uv sync
uv run ruff format .
uv run ruff check .
uv run mypy src
uv run pytest -q # perf-gate tests are opt-in
uv run pytest -q -m perf # perf budgets on the ~400k-change fixture
uv run python tools/bench.py tests/fixtures/bench.fst clkTest fixtures (FST files + VHDL sources) live in tests/fixtures/.
MIT — see LICENSE.
How fast, how long, how much is this signal?
Answers "what's the period / frequency / duty cycle of ?", "how much time is in X/Z?", "what's the min/max/mean of this real?", "which values does take and how often?". This is the statistics tool: it summarizes a window instead of listing changes. Times are human-readable ('10ns') or integer ticks; the window is [start, end) — omit end to run to the signal's last change. For a raw change list use waver_values; for edge-to-edge timing between two signals use waver_latency.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| file | Yes | ||
| start | No | 0 | |
| signal | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
When was the signal equal to this value?
Answers "when did become ?", "when is the bus in X?",
"when does the FSM enter ?". Int signals take decimal or hex
('0x1f'); string/enum signals match case-insensitively; on logic
vectors 'x' or 'z' matches an all-X/all-Z bus. Returns each interval
the value is held, with its duration, from start onwards. For a
single time point use waver_value_at; for statistics use
waver_analyze.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| limit | No | ||
| start | No | 0 | |
| value | Yes | ||
| signal | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
How long from A's edge to B's edge?
Answers "what's the propagation delay from to ?", "how long after 's rising edge does rise?". For every edge of A in [start, end) it finds the first edge of B at or after that moment and reports min/max/mean/p50/stddev over all such pairs, plus the first and last pairs. edge='rise' needs both signals to be binary (0/1); use edge='any' for any change. Times are human-readable or ticks. For one signal's own timing use waver_analyze.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| end | No | ||
| edge | No | rise | |
| file | Yes | ||
| start | No | 0 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
What is in this waveform file?
Answers "what's in this FST? how long did the simulation run? what's the timescale?". Call it first for any file you have not inspected yet; the timescale and duration it reports frame every window you pass to the other waver_* tools. Use waver_search to list the individual signals.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Show me the waveforms: a PNG plot of these signals in this window.
Answers "show me <signal(s)> around time A" / "what does the bus look like here?". One lane per signal: binary signals step between 0 and 1, small numeric signals draw as a line, and wide buses plus string/enum signals show their held values as text labels with X/Z spans shaded. Times are human-readable ('10ns', '1.5us') or integer file ticks; the window is [start, end) — omit end to run to the end of the file. Dense signals are decimated to ~10000 points so large files stay fast. Returns the plot as an image plus a text summary; the PNG is also written to a temp file whose path is in the summary. For statistics use waver_analyze; for exact values use waver_values.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| file | Yes | ||
| start | No | 0 | |
| signals | Yes |
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.
Which signals are in this waveform file?
Answers "what signals does this FST contain? is there a signal named
X?". Pass a case-insensitive substring of pattern to narrow the list
on large designs. The names shown are what you pass to waver_values,
waver_analyze, waver_latency, waver_find and waver_plot — full names
or unique suffixes. Header-only: nothing is decoded, so this is fast
even on big files.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| limit | No | ||
| pattern | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
What were these signals at this exact time?
Answers "what was at 10ns?" (batch: pass several signals in one call). Returns the value held at that instant (the last change at or before the time). Time is human-readable ('10ns') or integer file ticks. If the time is past the end of the file, the last recorded value is returned and flagged. For a whole window of changes, use waver_values.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| time | Yes | ||
| signals | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
What values did this signal have in this time window?
Answers "what did do between A and B?". Times are human-readable ('10ns', '1.5us') or integer file ticks; the window is [start, end) — omit end to run to the signal's last change. Wide (>= 32 bit) values are shown in hex; X/Z samples and enum/ string values are kept as-is. For statistics instead of a change list, use waver_analyze; for one time point, waver_value_at.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| file | Yes | ||
| start | No | 0 | |
| signal | Yes | ||
| max_changes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Each tool targets a clearly distinct operation: open inspects file metadata, search lists signals, values returns change lists, value_at samples a single instant, analyze computes statistics, latency measures edge-to-edge delays, find locates value-held intervals, and plot renders visual waveforms. The descriptions cross-reference each other, making selection unambiguous.
All tools share the waver_ prefix and use lowercase snake_case with a descriptive suffix. Even though suffixes mix verbs (open, search, analyze, find, plot) and nouns (values, value_at, latency), the pattern is predictable and uniformly applied, creating a cohesive naming scheme.
Eight tools is well-scoped for a waveform inspection server: each tool covers a distinct mode of interaction with waveform data, from metadata discovery to detailed querying and visualization. There is no redundancy and no sense that tools were added without purpose.
The surface covers the full waveform analysis workflow: open the file, find signals, query values over time or at instants, compute statistics, measure delays, locate specific values, and generate plots. No significant gaps are apparent for the stated domain of FST file inspection and analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only x402-paid trend-intent MCP tools for JSON and CSV signals.
Read-only XRP Ledger MCP tools with proof-annotation envelopes and signed daily snapshots.
Read-only F1 game laps, telemetry, setups, leaderboard benchmarks, and progress.
Query Allen-Bradley and Siemens PLC projects, live tag values, and analyses in plain English.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ru551n/waver-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
