The visualizer-mcp server connects AI assistants to Siemens Questa Visualizer, enabling natural-language control of EDA simulations via a TCP/MCP interface.
Connect & monitor — Establish or verify a connection to a Visualizer session, with auto-launch support (vcc_connect, vcc_status).
Run simulations — Advance simulation by a specified time (e.g., "100ns", "8 us", "-all") or check the current run state (vcc_run, vcc_run_status).
Step through — Single-step the simulator by one or more delta cycles (vcc_step).
Query time — Retrieve the current simulation time (vcc_get_time).
Waveform management — Add signals to the wave window using hierarchical paths (e.g., sim.div_tb.*) (vcc_wave_add).
Force signal values — Override a signal's value at the current or a specified simulation time (vcc_force).
Examine signals — Read a signal's value with support for multiple radix formats (decimal, binary, hex, octal) (vcc_examine).
Scan & search history — Scan a signal across a time range and search for a specific value (vcc_scan_signal).
Monitor async notifications — Retrieve recent asynchronous events from Visualizer (e.g., time/design state changes) from a ring buffer (vcc_recent_signals).
Execute arbitrary Tcl — Send any Tcl command directly to Visualizer's interpreter as a full escape hatch (vcc_eval).
Allows AI assistants to control a Siemens Questa Visualizer simulation: opening waveforms, running the design, examining signal values, and searching signal histories across time.
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., "@visualizer-mcp open waveform for clk and reset"
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.
visualizer-mcp is a Model Context Protocol (MCP) server that connects AI assistants to Siemens Questa Visualizer through the Visualizer Command Channel (VCC) TCP interface. It lets Claude Code control a live simulation in natural language: opening waveforms, running the design, examining signal values, and searching signal histories across time. Visualizer is supplied with all Questa versions except OEM versions(?).
Controlling Visualizer from a Claude code prompt is slow and not very (cost) effective as simple commands will consume $$$ tokens. It is obviously easier to run a .do or qrun file locally. However, the reason for the demo is to show what is possible, letting the LLM control the simulation and checking the results opens up some interesting capabilities!
Tool | Purpose | Notes |
Python 3.10+ | Runs the MCP server | |
uv | Installs the server via | |
git | Used (?) by claude to install the mcp server | |
Siemens Visualizer | The simulation GUI that the server controls |
|
Claude Code | The AI assistant that issues tool calls |
Note other LLM's should work as well but I am using Claude code (subscription).
Related MCP server: Verilator MCP Server
# 1. Install uv (skip if already installed)
curl -LsSf https://astral.sh/uv/install.sh | sh
source $HOME/.local/bin/env # reload PATH
# 2. Register visualizer-mcp with Claude Code
claude mcp add visualizer -- \
uvx --from git+https://github.com/htminuslab/visualizer-mcp visualizer-mcp# 1. Install uv (skip if already installed)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
# 2. Register visualizer-mcp with Claude Code
claude mcp add visualizer -- `
uvx --from git+https://github.com/htminuslab/visualizer-mcp visualizer-mcpVerify the registration:
claude mcp listWorking directory. By default the server looks for Visualizer's connection file (
.Visualizer/vccserver.cfg) relative to its own working directory, which is the directory from which you launchedclaude. Launch both Visualizer and Claude Code from the same simulation directory and no further configuration is needed. If they differ, setVCC_WORK_DIR— see Environment variables.
To add the Visualizer mcp server to LM Studio simply add the server to the mcp.json file which you can find on the Developers page:
Notice the "env" section where I set the VCC_WORK_DIR to a local directory. This is the directory where you start Visualizer from and which contains .visualizer/vccserver.cfg file. An easier way might be to force Visualizer to write the .visualizer/vccserver.cfg to a fixed location. This can be done using (see user guide for all the options including fixing the Tcp port):
visualizer -vccfile <directory_path> -do myscript.doTo add the Visualizer mcp server to VScode so that CoPilot can use it add the server to the local .vscode/mcp.json file:
Note that the VSCode uses "env":{} is empty as the project root directory is the default for the .visualizer/vccserver.cfg file so there is no need to set the VCC_WORK_DIR environmental variable.
To add the Visualizer mcp server to the VSCode continue plugin (if you are running a local LLM) create a visualizer.yaml file under .continue\mcpServers as shown below:
Claude Code ──stdio──► visualizer-mcp ──TCP──► Visualizer GUI
(LLM host) (MCP) (this server) (VCC) (Siemens EDA)Claude Code launches visualizer-mcp as a child process over stdio (the standard MCP transport). The server keeps one persistent TCP connection to the Visualizer Command Channel (VCC) server, which starts automatically inside every Visualizer session.
Connection sequence:
On the first tool call the server reads $VCC_WORK_DIR/.Visualizer/vccserver.cfg. Visualizer writes this file at startup; it contains the VCC host and port in the form port@hostname.
The server opens a TCP socket, sends vccRegisterClient, and subscribes to vDesignStateChange, vTimeChange, and vHierarchyChange notifications.
Each tool call encodes a Tcl command into a VCC frame (10-byte header + brace-delimited body), sends it over the socket, and waits for the matching reply frame. Frames are matched to callers by an incrementing message number.
Async signal notifications (e.g. time changes, design state changes) arrive as unsolicited s-type frames and are stored in a 256-entry ring buffer, readable via vcc_recent_signals.
If Visualizer closes and the socket drops, the server reconnects (or auto-launches Visualizer) on the next tool call.
Every Visualizer Tcl command described in the Visualizer Debug Environment Command Reference Manual — run, step, wave add, examine, force, env, and hundreds more — is available through the vcc_eval escape hatch.
All tools return {"ok": true, "result": "..."} on success or {"ok": false, "error": "..."} on failure.
Tool | Description |
| Connect to Visualizer (auto-launch if needed). Idempotent. |
| Report cfg file presence, host/port, and connection state. Does not connect. |
| Send any Tcl command verbatim — the full Visualizer command set is accessible here. |
| Advance simulation: |
| Single-step the simulator N delta cycles. |
| Return the current simulator run state. |
| Return the current simulation time. |
| Add one or more signals to the wave window by hierarchical path. |
| Force a signal to a value, optionally at a specific simulation time. |
| Read a signal's value at the current or a specified simulation time. |
| Scan a signal across a time range; optionally search for a specific value. |
| Return the most recent async signal notifications from Visualizer. |
Variable | Default | Description |
| server CWD | Directory whose |
| (unset) | Explicit path to the cfg file; overrides |
|
| Name sent with |
|
| Binary used when auto-launching Visualizer. |
|
| Seconds to wait for the cfg file after spawning Visualizer. |
|
| Per-command timeout in seconds. |
To set an environment variable when registering the server:
# Linux
claude mcp add visualizer \
-e VCC_WORK_DIR=/path/to/sim \
-- uvx --from git+https://github.com/htminuslab/visualizer-mcp visualizer-mcp
# Windows
claude mcp add visualizer `
-e "VCC_WORK_DIR=C:\path\to\sim" `
-- uvx --from git+https://github.com/htminuslab/visualizer-mcp visualizer-mcp The vhdl_example/ directory contains a 32-bit non-restoring integer divider (div.vhd) and a testbench (div_tb.vhd). The basic directed test testbench exercises both unsigned and signed division across a few operand pairs. This walk-through shows how to use Claude Code to compile, simulate, and interrogate the design.
Open a terminal/CMD prompt, change to vhdl_example/, and start Visualizer with:
cd vhdl_example
visualizer -do run.dorun.do compiles the VHDL sources, optimises the design to div_tb_vopt and loads it into the simulator with vsim -visualizer. The Visualizer GUI appears with the simulation paused at time 0.
Open a new terminal in the same vhdl_example/ directory and start Claude Code:
cd vhdl_example
claudeInside Claude Code, type the following command to confirm the MCP server is connected:
/mcpYou should see visualizer listed as a connected server. You can also ask Claude directly:
Are the Visualizer MCP tools available?
Claude will confirm and list the available tools.
The Visualizer transcript window should list the VCC server connection:
# Loading std.standard
# Loading std.textio(body)
# Loading ieee.std_logic_1164(body)
# Loading ieee.numeric_std(body)
# Loading work.div_tb(rtl)#1
# 18:09:53: Loading design data...
# 18:09:53: Loaded design units
# 18:09:53: Loaded design hierarchy
# 1
# VCC server established connection with remote client: Claude-MCPAsk Claude:
Open the wave window and add all testbench signals from div_tb
Claude calls:
vcc_eval("view wave")
vcc_wave_add(["sim.div_tb.*"])All top-level testbench signals (clk_s, reset_s, dividend_s, divisor_s, quotient_s, remainder_s, start_s, busy_s) appear in the Visualizer wave window.
Ask Claude:
Run the simulation for 8 microseconds
Claude calls:
vcc_run("8 us")The simulation advances to 8 µs. The waveforms update in the Visualizer GUI, showing all the division operations carried out by the testbench.
Ask Claude:
Did remainder_s ever equal 23 during the simulation?
Claude responds with:
Called visualizer 16 times (ctrl+o to expand)
● Yes — remainder_s did equal 23 at some point during the simulation. Let me find the exact timestamp.
Called visualizer (ctrl+o to expand)
● Yes, remainder_s equaled 23 during the simulation. It held that value continuously from 3890 ns to 5580 ns
(about 1.69 µs), which corresponds to one of the division results being held stable while busy_s was
asserted. The value then changed as the next operation completed.
✻ Churned for 1m 0sYou can continue the investigation by asking Claude:
at time 4651 ns can you confirm the value of quotient_s and remainder_s are correct for the given input values on dividend_s and divider_s?
Claude responds with:
● At 4651 ns the signal values are:
┌─────────────┬────────────┐
│ Signal │ Value │
├─────────────┼────────────┤
│ dividend_s │ 23 │
├─────────────┼────────────┤
│ divisor_s │ 46 │
├─────────────┼────────────┤
│ divsigned_s │ 1 (signed) │
├─────────────┼────────────┤
│ quotient_s │ 0 │
├─────────────┼────────────┤
│ remainder_s │ 23 │
└─────────────┴────────────┘
Verification: 23 ÷ 46 = 0 remainder 23
Check: (46 × 0) + 23 = 23 ✓
Both outputs are correct. Since the dividend (23) is smaller than the divisor (46), the quotient is 0 and
the full dividend value is returned as the remainder.
✻ Baked for 8sThe next step is to ask Claude to create a proper testbench using either an exiting framework like UVVM/OS-VVM/CocoTB or a custom self-checking one. Ask it to add comments/documentation, to lint the code, to change the testbench to SV/SystemC, etc........
The LLM sometimes changes the signal name, for example, if I ask a local LLM (gemma-4-e4b) to add all testbench signals it generates a vcc_wave_add commands with the argument:
Arguments: {"signals":["sim.top.div_tb.*"]}which is incorrect as there is no top level. If I then ask it to not add "top" to the signal names it generates:
Arguments: {"signals":["sim.*div_tb.*"]}which is also incorrect as visualizer can not process wildcard characters for the top level (*div_tb). Unfortunately the result indicates that all is OK but no signals were added.
Note that this does not happen if you use Claude code, only a small LLM (e.g. 6GB Qwen) seems to have this issue. If you want to use a local LLM you have to be more specific, for example in the demo designs case you have to say "add all sim.div_tb signals to the waveform window" which then generate the correct argument for the mcp server:
Arguments: {"signals":["sim.div_tb.*"]}Make sure that Visualizer is running before you try to issue a command.
If your LLM can not control Visualizer ask the LLM to issue a "connect" command followed by a "status" command.
The status command will list the path to vccserver.cfg
Most of this code was created by Claude Code sonnet 4.6
See the LICENSE file for details for this demo.
All logos, trademarks and graphics used herein are the property of their respective owners.
Ensure Visualizer is running and the VCC socket is open. Idempotent.
Returns an error with instructions if Visualizer is not running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses idempotency and error behavior (returns error with instructions if Visualizer not running). This is sufficient behavioral context for a connection tool.
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?
Two concise sentences, zero wasted words. The critical information (purpose, idempotency, error behavior) is front-loaded. Excellent structure.
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 no parameters and the presence of an output schema (not shown but indicated), the description covers all essential aspects: what it does, side effects (idempotent), and error handling. Complete for a simple connection 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?
The input schema has zero parameters, so baseline is 4. The description does not need to add parameter meaning. It simply states the tool takes no arguments, which aligns with the 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 clearly states the tool's purpose: ensuring Visualizer is running and the VCC socket is open. It uses a specific verb ('Ensure') and resource ('Visualizer' and 'VCC socket'). However, it does not explicitly distinguish from sibling tools like vcc_eval or vcc_run, which are likely dependent on prior connection.
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 implies usage context: before other VCC operations, and returns an error with instructions if Visualizer is not running. However, it lacks explicit guidance on when not to use (e.g., if already connected) or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send any Tcl command to Visualizer's command interpreter.
This is the escape hatch — every Visualizer Tcl command (run, step, wave add, force, examine, env, ...) can be sent through this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tcl | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose important behavioral traits such as potential side effects, error handling, execution guarantees, or the format of the output (despite an output schema existing). The claim 'send any Tcl command' lacks nuance about safety or state changes.
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 two sentences long, front-loads the core purpose, and uses the second sentence to reinforce the breadth of use. Every part contributes meaning without unnecessary 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?
Given the tool's complexity (an arbitrary command executor) and the presence of sibling tools, the description lacks critical details: parameter semantics for timeout_s, behavioral implications, and guidance on when to use this vs. specialized tools. The existence of an output schema reduces some burden, but gaps remain.
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 description adds value for the 'tcl' parameter by explaining it accepts any Visualizer Tcl command and listing examples. However, it does not mention the 'timeout_s' parameter at all. With 0% schema description coverage, the description partially compensates but leaves one parameter undocumented.
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 clearly states the tool sends any Tcl command to Visualizer's command interpreter and provides specific examples (run, step, wave add, etc.), distinguishing it from the more specific sibling tools by calling it an 'escape hatch'.
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 says it can be used for any Visualizer Tcl command, implying it's a fallback. However, it does not explicitly say when to prefer specific sibling tools over this one, nor does it mention any prerequisites or limitations. The guidance is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Examine the value of a signal, optionally at a specific simulation time.
signal: dot-separated hierarchical path with "sim." prefix e.g. sim.testbench.u1.my_signal time: simulation time e.g. "400 ns" (omit for current time) radix: decimal (default), binary, hexadecimal, unsigned, octal
The returned value may include a size/radix annotation e.g. "4'd3" (4-bit vector, decimal value 3). If Visualizer is not configured to annotate, the plain value is returned e.g. "3". Signal must be last in the examine command; this tool enforces that.
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | ||
| time | No | ||
| radix | No | decimal |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses return value format (size/radix annotation vs plain), and a behavioral constraint (signal must be last, enforced). This is good transparency for a read tool.
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?
Description is concise (10 lines), well-structured with a purpose sentence followed by parameter details in bullet-like format. No fluff, every sentence is informative.
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 complexity (3 parameters, no annotations, output schema exists but description explains return value), the description is complete. It covers parameter formats, return behavior, and a usage constraint.
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 coverage is 0%, but the description compensates fully: explains signal path format (dot-separated with 'sim.' prefix), time examples ('400 ns'), and radix options. This adds critical meaning beyond the raw 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 clearly states the tool examines a signal value with optional time and radix. It uses specific verb 'Examine' and resource 'signal value', and the context of sibling tools (e.g., vcc_force, vcc_eval) makes its distinct purpose obvious.
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 provides detailed parameter usage: signal format, time semantics (omit for current time), radix options. It also notes a special constraint ('Signal must be last…'). While it doesn't explicitly compare to siblings, the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force signal to value (e.g. force sim.top.rst 1 0; force sim.top.clk 0 50ns).
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | ||
| value | Yes | ||
| time | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose that forcing overrides normal simulation behavior, whether it is temporary, or any side effects like destroying prior state. The term 'force' implies mutation but lacks detail on impact.
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?
Extremely concise: one sentence plus example with no redundant information. Every word earns its place.
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 tool's simplicity and presence of an output schema, the description covers the core action but omits context on signal path conventions, time format rigor, and interaction with other simulation states. Adequate but not thorough.
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 coverage, description adds meaning via example: signal is a path, value is a value like 0/1, time is optional and appears in units like '0' or '50ns'. However, the format of time is not explicitly documented, and the schema properties lack descriptions.
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 clearly states the action 'Force `signal` to `value`' with an example, making the verb and resource explicit. It distinguishes from siblings like vcc_examine (read) and vcc_eval, as forcing is a distinct write operation.
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?
No guidance on when to use this tool vs alternatives like vcc_eval or vcc_connect. The description does not mention when not to use it or provide context for prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current simulation time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation (returning a value). For a simple getter with no parameters, this is adequate and not misleading.
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 a single clear sentence with no unnecessary words. It is front-loaded and 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?
The description lacks details about the return value format (e.g., units of time). However, an output schema exists which may provide this. Given the tool's simplicity, it is partially complete.
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?
There are zero parameters and 100% schema coverage. The description adds no parameter detail, but baseline is 4 for zero-parameter tools.
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 'Return the current simulation time.' clearly states the action (return) and the resource (simulation time). It is specific and distinguishes from sibling tools like vcc_force or vcc_run.
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?
No information is provided about when to use this tool versus alternatives, or any prerequisites. The description only states what it does, not when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent async signal notifications received from Visualizer (e.g. vTimeChange, vDesignStateChange). Newest last.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does indicate the type of notifications (async) and ordering, but does not disclose potential side effects, rate limits, or behavior when no signals are available. Some context is given, but gaps remain.
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 extremely concise: two short sentences that front-load the purpose and include an illustrative example. Every word adds value, with no redundancy or unnecessary 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?
The tool has a simple interface with one parameter and an output schema, but the description still omits practical details like parameter semantics and common error scenarios. It is minimally complete but could better cover usage context without overcomplicating.
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 input schema has a single 'limit' parameter with no description (0% coverage). The tool description does not mention the parameter or its effect, leaving the agent to guess. Although the name 'limit' is somewhat intuitive, the description should clarify how it controls the number of returned notifications.
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 clearly states the tool returns recent async signal notifications from Visualizer, with concrete examples (vTimeChange, vDesignStateChange) and specifies ordering (newest last). This is specific and distinguishes it from sibling tools that handle other simulation operations.
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?
No guidance is provided on when to use this tool versus alternatives like vcc_scan_signal (for current values) or vcc_get_time. The description lacks any 'when to use' or 'when not to use' information, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advance simulation. time may be "100ns", "-all", or None for default.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description explains the parameter constraint but does not disclose side effects, permissions, or return value. The presence of an output schema is not addressed.
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?
Two concise sentences with no wasted words, front-loading the action and parameter guidance.
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?
Adequate for a simple tool with one parameter; covers the essential behavior but omits output details and explicit sibling differentiation.
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 fully compensates by explaining that 'time' can be a string like '100ns', '-all', or None, adding meaning beyond the schema's type definition.
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 'Advance simulation' uses a specific verb ('Advance') and resource ('simulation'), clearly distinguishing it from sibling tools like vcc_connect, vcc_eval, etc.
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?
Provides explicit examples for the 'time' parameter ('100ns', '-all', None), but does not directly contrast with similar tools like vcc_step or vcc_run_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report runStatus (current simulator state).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description must fully disclose behavior. It only states 'Report runStatus' with no mention of side effects, idempotency, or whether it affects simulator state. This is inadequate for a tool that modifies no state but still needs transparency about its read-only nature.
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 extremely concise at 5 words, but it borders on under-specification. While it is front-loaded, it does not earn its place by providing sufficient detail; it omits crucial context about the return format or use cases.
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 existence of an output schema, the description should explain the semantics of 'runStatus' to help the agent interpret results. It fails to do so, and the presence of sibling vcc_status creates ambiguity about what this tool returns versus that one. The description is too brief for a complete understanding.
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?
There are no parameters, and the baseline score is 4 per guidelines. The description adds the meaning 'current simulator state' beyond the empty schema, so it meets the baseline.
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 clearly states the tool reports the current simulator state ('runStatus'). It uses a specific verb and resource, and the name implies a query operation, which distinguishes it from siblings like vcc_run (run simulation) and vcc_step (step simulation). However, it could be more explicit about what 'runStatus' specifically contains.
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?
No guidance is provided on when to use this tool versus alternatives such as vcc_status or vcc_eval. The agent has to infer usage from the name alone, which is insufficient for choosing correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a signal across a time range; optionally search for a specific value.
Returns all sampled values across the range as a Tcl list. If find_value is given, also reports whether the signal ever held that value (handles both plain "3" and annotated forms like "4'd3"). When find_value is given and no time range is specified, the scan starts from time 0 to cover the full simulation.
signal: dot-separated hierarchical path with "sim." prefix e.g. sim.testbench.u1.my_signal find_value: value to search for e.g. "6" (optional) from_time: range start e.g. "0 ns" (defaults to "0" when find_value given) to_time: range end e.g. "1 us" (omit to scan to simulation end) radix: decimal (default), binary, hexadecimal, unsigned, octal
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | ||
| find_value | No | ||
| from_time | No | ||
| to_time | No | ||
| radix | No | decimal |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It transparently describes return values (Tcl list), the search logic, handling of annotated values, and default time ranges. It does not explicitly state it is read-only, but the scanning nature implies no 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 well-structured with a concise summary followed by detailed parameter explanations. Every sentence adds value, and there is no redundancy or unnecessary verbosity.
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?
Despite having 5 parameters and no output schema provided, the description covers all aspects: purpose, parameter behaviors, return format, and special cases. It is complete and leaves no obvious gaps for the agent to infer.
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 fully compensates by explaining each parameter: signal format, find_value optionality, from_time/to_time default behaviors, and radix options. It adds meaning beyond the schema, such as the default radix and the behavior when to_time is omitted.
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 clearly states the tool scans a signal across a time range and optionally searches for a value. It provides a specific verb and resource, distinguishing it from siblings like vcc_examine (which examines a single signal) and vcc_force (which forces a value).
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 explains default behaviors (e.g., from_time defaults to 0 when find_value is given) and signal format requirements. However, it does not explicitly state when to use this tool versus alternatives like vcc_examine or vcc_get_time, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report VCC server reachability, host/port, and registration status.
Does NOT auto-launch. Use vcc_connect (or any other tool) to trigger
an auto-launch if Visualizer is not running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral property (no auto-launch) and indicates read-only reporting. With no annotations, description covers main trait; could mention if any side effects exist but none expected for a status check.
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?
Two sentences, front-loaded with purpose, and a separate line for non-auto-launch guidance. Every sentence adds 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?
Description is complete for a 0-param status tool with output schema. Key behavior (no auto-launch) and purpose are clear.
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?
No parameters, so baseline 4. Description adds no parameter info, but none needed; schema coverage is 100%.
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 states it reports server reachability, host/port, and registration status. This specific verb+resource distinguishes it from sibling tools like vcc_connect.
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?
Explicitly says 'Does NOT auto-launch' and directs to use vcc_connect for auto-launch, providing clear when-to-use and when-not-to-use with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-step the simulation count times.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the burden of disclosing behavioral traits. It does not mention side effects, error conditions, or the impact of stepping multiple times in a single call. The description adds minimal value beyond the tool name.
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 a single sentence, directly stating the action and parameter. It is concise and front-loaded, with no wasted words.
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?
Despite the tool's simplicity, the description is insufficient for an agent to use it correctly. It does not mention what happens after stepping (e.g., simulation advances), whether the simulation must be paused, or how to interpret the output (output schema exists but is not described).
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 input schema has 0% description coverage for its single parameter 'count'. The description does not elaborate on what 'count' means (e.g., number of simulation steps) or any constraints like non-negative values. The default value is noted in the schema but not explained.
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 clearly states the action (single-step) and the resource (simulation) with the parameter 'count' indicating how many times. This distinguishes it from sibling tools like vcc_run (which runs continuously) and vcc_force (which manipulates signals).
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., simulation must be running) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one or more signals to the wave window. Use dot-separated paths with "sim." prefix, e.g. ["sim.top.clk", "sim.top.dut.state", "sim.div_tb.*"]
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description covers path format but lacks details on side effects, error handling, or additive behavior.
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?
Two concise sentences with front-loaded action and example. No wasted words.
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?
Covers the core functionality and signal specification. Output schema exists to document return value, so no further detail needed.
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?
Despite 0% schema coverage, description explains the format of array elements (dot-separated, 'sim.' prefix), adding significant meaning.
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?
Clearly states it adds signals to the wave window, with specific syntax. Distinguishes from sibling tools like vcc_force.
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?
Provides usage pattern and examples, but does not explicitly state when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0vcc_connectvcc_evalvcc_examinevcc_forcevcc_get_timevcc_recent_signalsvcc_runvcc_run_statusvcc_scan_signalvcc_statusvcc_stepvcc_wave_addMost tools have clear distinct purposes (connect, examine, run, step, etc.), but vcc_status and vcc_connect overlap in reporting connection status, and vcc_eval is an escape hatch that could replicate other tools. Minor ambiguity.
All tools share the vcc_ prefix, but the second part mixes verb_noun (connect, examine, run), noun_verb (wave_add), adjective_noun (recent_signals), and lone noun (status). Inconsistent structure.
12 tools cover essential simulation control, signal inspection, wave management, and connection setup. Well-scoped for a visualizer MCP server.
Core functions are covered, but some operations (e.g., removing waves, setting radix per signal) are missing and must be done via vcc_eval. Minor gaps that can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
Control your Tesla from your AI assistant - climate, charging, access, and security.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/htminuslab/visualizer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
