Skip to main content
Glama
siliconsmith-mcp

siliconsmith-mcp

by RFingAdam

inspect_waves

Read-only

Show how selected signals changed in a retained wave file, with time-range and row-limit filters, to debug simulation results.

Instructions

Show how signals changed in a wave file that run_tests kept (run it with waves=True; the result gives the path, build/waves//tb.fst; a gate-level run, gl=True, keeps its own in build/waves/icarus-gl/tb.fst, where the signal names are those of the sky130 netlist). signals are names like 'uo_out' or 'user_project.uo_out' (a suffix of the full hierarchical name; the match nearest the top wins). start_ns and end_ns limit the time range. The table has one row per time where a requested signal changed: hex for buses, 0/1 for bits, x/z kept. At most max_rows rows come back (default 50, hard limit 1000); a note says how many more there are. details.rows has every returned row as strings.

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": {
      "project": "<project>",
      "path": "<path>",
      "signals": "<signals>"
    },
    "name": "inspect_waves"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
end_nsNo
projectYes
signalsYes
max_rowsNo
start_nsNo

Output Schema

NameRequiredDescriptionDefault
okYes
detailsNo
summaryYes
artifactsNo
next_hintsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly/destructive=false, and the description adds substantial behavior beyond that: the exact artifact path conventions, the signal-name matching rule (suffix match, nearest the top wins), the row cap default of 50 with a hard limit of 1000 plus a truncation note, and the cell formatting (hex for buses, 0/1 for bits, x/z preserved). This is exactly the context a read-only tool needs.

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

Conciseness4/5

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

Front-loads the core purpose in the first clause and keeps every later sentence informational (paths, matching, limits, output shape). It is dense and parenthetical-heavy, reading as one long block, but no sentence is filler.

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

Completeness5/5

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

Despite an output schema existing, the description still explains the returned table shape and that details.rows carries all returned rows as strings, and it covers the gate-level naming caveat an agent would otherwise get wrong. For a six-parameter inspection tool, nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 0%, so the description carries the burden, and it defines five of six parameters with real semantics: path (build/waves/<simulator>/tb.fst), signals (suffix-of-hierarchical-name matching with tie-breaking), start_ns/end_ns (time range limiting), and max_rows (default and hard cap). Only 'project' is left unstated, a minor but real gap.

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

Purpose5/5

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

States a specific action (show how signals changed) on a specific resource (a waveform file kept by run_tests), and immediately ties itself to the producing sibling (run_tests with waves=True). The gate-level variant is called out separately, so an agent can tell exactly which artifact this inspects.

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

Usage Guidelines4/5

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

Gives a clear precondition — a prior run_tests invocation with waves=True (or gl=True) must have produced the file — which effectively tells the agent when this tool is applicable. It stops short of naming an alternative tool or an explicit 'do not use when' case, so it is strong but not a full routing statement.

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