Skip to main content
Glama
Sign In
wtf-wave

wtf-wave

by xtrollyj00
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

open

Switch the active waveform trace or workspace so decoding and search tools target the chosen VCD, FST, or GHW file.

Instructions

Choose the trace the other tools work on: trace opens a waveform (VCD, FST or GHW file) in a new workspace; session goes back to one of your workspaces (sessions); neither re-reads the current one's file, after the simulation ran again, keeping its rows. Answers with info, which lists the interfaces to decode.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "open"
  }
}

Input Schema

NameRequiredDescriptionDefault
traceNoPath of a VCD, FST or GHW file, best absolute: a new workspace on it.
sessionNoThe id of one of this server's workspaces, from `sessions`: make it current again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.4.0
    • addedInput schema / properties / session
      Added value: +{
+  "description": "The id of one of this server's workspaces, from `sessions`: make it current again.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedInput schema / properties / trace / description
      Previous value: -"Path of a VCD, FST or GHW file, best absolute."New value: +"Path of a VCD, FST or GHW file, best absolute: a new workspace on it."
    • changedInput schema / properties / trace / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • removedInput schema / required
      Removed value: -[
-  "trace"
-]
  2. First observedv0.3.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false but destructiveHint=false and idempotentHint=false, which is thin on its own for a state-changing tool. The description supplies the missing context: opening a trace creates a new workspace, switching to a session makes it current, and neither re-reads the file after a simulation re-run so existing rows are retained. It also discloses the response payload ('Answers with `info`...'). It does not say what happens to the previously current workspace or whether a second open on the same file creates a duplicate workspace.

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?

A single compact passage with the overall purpose front-loaded before the two mode branches, so the agent reads the important part first. Semicolon-chained clauses and backticked identifiers make it dense, but every clause (formats, new workspace, restore current, no re-read, returns `info`) carries information.

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?

For a two-parameter tool with no output schema, the description covers both parameters' effects and the return value, which is substantial. However, both parameters are optional and the definition never says what happens if neither is supplied or if both are given at once — a meaningful ambiguity for an agent calling it. The missing-argument semantics is the main completeness gap.

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% and both property descriptions already state the file formats, the 'best absolute' hint, and the 'new workspace' / 'make it current again' outcomes, so the description largely restates structured data. What it does add is the shared caveat that applies to both parameters (the file is not re-read), which the schema does not express. Baseline 3 is appropriate given the schema does the heavy lifting.

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

Purpose4/5

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

The description leads with a specific verb+resource: 'Choose the trace the other tools work on', then splits the tool into its two modes (open a waveform file vs. restore one of the server's workspaces). Named siblings `sessions` and `info` anchor it in the catalog. It is clear what the tool does, though the generic name 'open' means the description carries more of that burden than a self-explanatory name would.

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?

It explicitly tells the agent which parameter corresponds to which situation: a VCD/FST/GHW file path creates a new workspace, while a workspace id from `sessions` makes an existing one current again. That is real mode-selection guidance. It stops short of saying when to use this tool versus other state-affecting siblings such as `workspace` or `view`, so no exclusions are given.

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