visualizer-mcp ist ein Model Context Protocol (MCP)-Server, der KI-Assistenten über die TCP-Schnittstelle des Visualizer Command Channel (VCC) mit Siemens Questa Visualizer verbindet. Er ermöglicht es Claude Code, eine Live-Simulation mittels natürlicher Sprache zu steuern: Wellenformen öffnen, das Design ausführen, Signalwerte untersuchen und Signalverläufe über die Zeit hinweg durchsuchen. Visualizer ist bei allen Questa-Versionen außer OEM-Versionen enthalten(?).
Werkzeug | Zweck | Hinweise |
Python 3.10+ | Führt den MCP-Server aus | |
uv | Installiert den Server via | |
Siemens Visualizer | Die Simulations-GUI, die der Server steuert |
|
Claude Code | Der KI-Assistent, der Tool-Aufrufe tätigt |
Hinweis: Andere LLMs sollten ebenfalls funktionieren, aber ich verwende Claude Code (Abonnement).
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-mcpÜberprüfen Sie die Registrierung:
claude mcp listArbeitsverzeichnis. Standardmäßig sucht der Server nach der Verbindungsdatei von Visualizer (
.Visualizer/vccserver.cfg) relativ zu seinem eigenen Arbeitsverzeichnis, welches das Verzeichnis ist, aus dem Sieclaudegestartet haben. Starten Sie sowohl Visualizer als auch Claude Code aus demselben Simulationsverzeichnis, dann ist keine weitere Konfiguration erforderlich. Falls sie sich unterscheiden, setzen SieVCC_WORK_DIR— siehe Umgebungsvariablen.
Claude Code ──stdio──► visualizer-mcp ──TCP──► Visualizer GUI
(LLM host) (MCP) (this server) (VCC) (Siemens EDA)Claude Code startet visualizer-mcp als untergeordneten Prozess über stdio (den Standard-MCP-Transport). Der Server hält eine dauerhafte TCP-Verbindung zum Visualizer Command Channel (VCC)-Server aufrecht, der automatisch innerhalb jeder Visualizer-Sitzung startet.
Verbindungssequenz:
Beim ersten Tool-Aufruf liest der Server $VCC_WORK_DIR/.Visualizer/vccserver.cfg. Visualizer schreibt diese Datei beim Start; sie enthält den VCC-Host und Port in der Form port@hostname.
Der Server öffnet einen TCP-Socket, sendet vccRegisterClient und abonniert Benachrichtigungen für vDesignStateChange, vTimeChange und vHierarchyChange.
Jeder Tool-Aufruf kodiert einen Tcl-Befehl in einen VCC-Frame (10-Byte-Header + in geschweiften Klammern eingeschlossener Body), sendet ihn über den Socket und wartet auf den passenden Antwort-Frame. Frames werden den Aufrufern über eine aufsteigende Nachrichtennummer zugeordnet.
Asynchrone Signalbenachrichtigungen (z. B. Zeitänderungen, Design-Zustandsänderungen) kommen als unaufgeforderte Frames vom Typ s an und werden in einem Ringpuffer mit 256 Einträgen gespeichert, der über vcc_recent_signals lesbar ist.
Wenn Visualizer geschlossen wird und der Socket abbricht, verbindet sich der Server beim nächsten Tool-Aufruf neu (oder startet Visualizer automatisch).
Jeder Visualizer-Tcl-Befehl, der im Visualizer Debug Environment Command Reference Manual beschrieben ist — run, step, wave add, examine, force, env und Hunderte mehr — ist über den vcc_eval-Ausgang verfügbar.
Alle Tools geben bei Erfolg {"ok": true, "result": "..."} oder bei Fehler {"ok": false, "error": "..."} zurück.
Tool | Beschreibung |
| Verbindung zu Visualizer herstellen (automatischer Start bei Bedarf). Idempotent. |
| Meldet das Vorhandensein der cfg-Datei, Host/Port und Verbindungsstatus. Verbindet nicht. |
| Sendet jeden Tcl-Befehl wortwörtlich — der vollständige Visualizer-Befehlssatz ist hier zugänglich. |
| Simulation vorantreiben: |
| Den Simulator um N Delta-Zyklen weiterschalten. |
| Gibt den aktuellen Laufstatus des Simulators zurück. |
| Gibt die aktuelle Simulationszeit zurück. |
| Fügt ein oder mehrere Signale über den hierarchischen Pfad zum Wellenfenster hinzu. |
| Erzwingt einen Wert für ein Signal, optional zu einer bestimmten Simulationszeit. |
| Liest den Wert eines Signals zur aktuellen oder einer angegebenen Simulationszeit. |
| Scannt ein Signal über einen Zeitbereich; optional Suche nach einem bestimmten Wert. |
| Gibt die neuesten asynchronen Signalbenachrichtigungen von Visualizer zurück. |
Variable | Standard | Beschreibung |
| Server CWD | Verzeichnis, dessen |
| (nicht gesetzt) | Expliziter Pfad zur cfg-Datei; überschreibt die |
|
| Name, der mit |
|
| Binärdatei, die beim automatischen Starten von Visualizer verwendet wird. |
|
| Sekunden, die nach dem Starten von Visualizer auf die cfg-Datei gewartet wird. |
|
| Timeout pro Befehl in Sekunden. |
Um eine Umgebungsvariable beim Registrieren des Servers zu setzen:
# 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-mcpDas Verzeichnis vhdl_example/ enthält einen 32-Bit-Nicht-Restaurierungs-Ganzzahldividierer (div.vhd) und einen Testbench (div_tb.vhd). Der Testbench führt sowohl vorzeichenlose als auch vorzeichenbehaftete Divisionen über mehrere Operandenpaare aus. Diese Anleitung zeigt, wie man Claude Code verwendet, um das Design zu kompilieren, zu simulieren und abzufragen.
Öffnen Sie ein Terminal/CMD-Fenster, wechseln Sie zu vhdl_example/ und starten Sie Visualizer mit:
cd vhdl_example
visualizer -do run.dorun.do kompiliert die VHDL-Quellen, optimiert das Design zu div_tb_vopt und lädt es mit vsim -visualizer in den Simulator. Die Visualizer-GUI erscheint mit der Simulation, die bei Zeit 0 pausiert ist.
Öffnen Sie ein neues Terminal im selben vhdl_example/-Verzeichnis und starten Sie Claude Code:
cd vhdl_example
claudeGeben Sie innerhalb von Claude Code den folgenden Befehl ein, um zu bestätigen, dass der MCP-Server verbunden ist:
/mcpSie sollten visualizer als verbundenen Server aufgelistet sehen. Sie können auch direkt Claude fragen:
Sind die Visualizer MCP-Tools verfügbar?
Claude wird dies bestätigen und die verfügbaren Tools auflisten.
Das Visualizer-Transkriptfenster sollte die VCC-Serververbindung auflisten:
# 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-MCPFragen Sie Claude:
Öffne das Wellenfenster und füge alle Testbench-Signale von div_tb hinzu
Claude ruft auf:
vcc_eval("view wave")
vcc_wave_add(["sim.div_tb.*"])Alle Top-Level-Testbench-Signale (clk_s, reset_s, dividend_s, divisor_s, quotient_s, remainder_s, start_s, busy_s) erscheinen im Visualizer-Wellenfenster.
Fragen Sie Claude:
Führe die Simulation für 8 Mikrosekunden aus
Claude ruft auf:
vcc_run("8 us")Die Simulation schreitet bis 8 µs voran. Die Wellenformen in der Visualizer-GUI werden aktualisiert und zeigen alle vom Testbench durchgeführten Divisionsoperationen.
Fragen Sie Claude:
War remainder_s während der Simulation jemals gleich 23?
Claude antwortet mit:
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 0sSie können die Untersuchung fortsetzen, indem Sie Claude fragen:
Kannst du bei Zeit 4651 ns bestätigen, dass der Wert von quotient_s und remainder_s für die gegebenen Eingangswerte von dividend_s und divider_s korrekt ist?
Claude antwortet mit:
● 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 8sDie Steuerung von Visualizer über eine Claude Code-Eingabeaufforderung ist langsam und nicht sehr (kosten-)effektiv, da einfache Befehle Token verbrauchen. Es ist offensichtlich einfacher, eine .do- oder qrun-Datei auszuführen. Der Grund für die Demo ist jedoch zu zeigen, was möglich ist; die LLM die Simulation steuern zu lassen und die Ergebnisse zu überprüfen, ist sehr interessant.
Der Großteil dieses Codes wurde von Claude Code 4.6 erstellt.
Siemens hat einen weitaus leistungsfähigeren Questa/Visualizer-MCP-Server namens Questa Agentic Toolkit.
Siehe die LICENSE-Datei für Details zu dieser Demo.
Alle hier verwendeten Logos, Marken und Grafiken sind Eigentum ihrer jeweiligen Inhaber.
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.
v0.1.0vcc_connectvcc_evalvcc_examinevcc_forcevcc_get_timevcc_recent_signalsvcc_runvcc_run_statusvcc_scan_signalvcc_statusvcc_stepvcc_wave_addScored across 12 tools
Most 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.
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
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.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
