visualizer-mcp es un servidor del Protocolo de Contexto de Modelo (MCP) que conecta asistentes de IA a Siemens Questa Visualizer a través de la interfaz TCP del Canal de Comandos de Visualizer (VCC). Permite que Claude Code controle una simulación en vivo mediante lenguaje natural: abrir formas de onda, ejecutar el diseño, examinar valores de señales y buscar historiales de señales a lo largo del tiempo. Visualizer se suministra con todas las versiones de Questa excepto las versiones OEM(?).
Herramienta | Propósito | Notas |
Python 3.10+ | Ejecuta el servidor MCP | |
uv | Instala el servidor mediante | |
Siemens Visualizer | La GUI de simulación que controla el servidor |
|
Claude Code | El asistente de IA que realiza las llamadas a herramientas |
Nota: otros LLM deberían funcionar también, pero estoy usando Claude Code (suscripción).
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-mcpVerifique el registro:
claude mcp listDirectorio de trabajo. Por defecto, el servidor busca el archivo de conexión de Visualizer (
.Visualizer/vccserver.cfg) en relación con su propio directorio de trabajo, que es el directorio desde el cual lanzóclaude. Inicie tanto Visualizer como Claude Code desde el mismo directorio de simulación y no se necesitará ninguna configuración adicional. Si difieren, establezcaVCC_WORK_DIR— vea Variables de entorno.
Claude Code ──stdio──► visualizer-mcp ──TCP──► Visualizer GUI
(LLM host) (MCP) (this server) (VCC) (Siemens EDA)Claude Code lanza visualizer-mcp como un proceso hijo a través de stdio (el transporte MCP estándar). El servidor mantiene una conexión TCP persistente con el servidor del Canal de Comandos de Visualizer (VCC), que se inicia automáticamente dentro de cada sesión de Visualizer.
Secuencia de conexión:
En la primera llamada a la herramienta, el servidor lee $VCC_WORK_DIR/.Visualizer/vccserver.cfg. Visualizer escribe este archivo al iniciarse; contiene el host y puerto VCC en el formato port@hostname.
El servidor abre un socket TCP, envía vccRegisterClient y se suscribe a las notificaciones vDesignStateChange, vTimeChange y vHierarchyChange.
Cada llamada a la herramienta codifica un comando Tcl en una trama VCC (encabezado de 10 bytes + cuerpo delimitado por llaves), lo envía a través del socket y espera la trama de respuesta correspondiente. Las tramas se emparejan con los llamadores mediante un número de mensaje incremental.
Las notificaciones de señales asíncronas (p. ej., cambios de tiempo, cambios de estado del diseño) llegan como tramas de tipo s no solicitadas y se almacenan en un búfer circular de 256 entradas, legible a través de vcc_recent_signals.
Si Visualizer se cierra y el socket se cae, el servidor se reconecta (o inicia automáticamente Visualizer) en la siguiente llamada a la herramienta.
Cada comando Tcl de Visualizer descrito en el Manual de referencia de comandos del entorno de depuración de Visualizer — run, step, wave add, examine, force, env y cientos más — está disponible a través de la puerta de escape vcc_eval.
Todas las herramientas devuelven {"ok": true, "result": "..."} en caso de éxito o {"ok": false, "error": "..."} en caso de error.
Herramienta | Descripción |
| Conectar a Visualizer (inicia automáticamente si es necesario). Idempotente. |
| Informa de la presencia del archivo cfg, host/puerto y estado de la conexión. No conecta. |
| Envía cualquier comando Tcl literalmente: el conjunto completo de comandos de Visualizer es accesible aquí. |
| Avanza la simulación: |
| Ejecuta el simulador paso a paso N ciclos delta. |
| Devuelve el estado de ejecución actual del simulador. |
| Devuelve el tiempo de simulación actual. |
| Añade una o más señales a la ventana de ondas mediante ruta jerárquica. |
| Fuerza una señal a un valor, opcionalmente en un tiempo de simulación específico. |
| Lee el valor de una señal en el tiempo de simulación actual o especificado. |
| Escanea una señal en un rango de tiempo; opcionalmente busca un valor específico. |
| Devuelve las notificaciones de señales asíncronas más recientes de Visualizer. |
Variable | Predeterminado | Descripción |
| CWD del servidor | Directorio cuyo |
| (sin establecer) | Ruta explícita al archivo cfg; anula la búsqueda de |
|
| Nombre enviado con |
|
| Binario utilizado al iniciar automáticamente Visualizer. |
|
| Segundos a esperar por el archivo cfg después de generar Visualizer. |
|
| Tiempo de espera por comando en segundos. |
Para establecer una variable de entorno al registrar el servidor:
# 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-mcpEl directorio vhdl_example/ contiene un divisor de enteros sin restauración de 32 bits (div.vhd) y un banco de pruebas (div_tb.vhd). El banco de pruebas ejercita la división tanto sin signo como con signo a través de varios pares de operandos. Este recorrido muestra cómo usar Claude Code para compilar, simular e interrogar el diseño.
Abra una terminal/símbolo del sistema, cambie a vhdl_example/ e inicie Visualizer con:
cd vhdl_example
visualizer -do run.dorun.do compila las fuentes VHDL, optimiza el diseño a div_tb_vopt y lo carga en el simulador con vsim -visualizer. La GUI de Visualizer aparece con la simulación pausada en el tiempo 0.
Abra una nueva terminal en el mismo directorio vhdl_example/ e inicie Claude Code:
cd vhdl_example
claudeDentro de Claude Code, escriba el siguiente comando para confirmar que el servidor MCP está conectado:
/mcpDebería ver visualizer listado como un servidor conectado. También puede preguntar directamente a Claude:
¿Están disponibles las herramientas MCP de Visualizer?
Claude confirmará y listará las herramientas disponibles.
La ventana de transcripción de Visualizer debería listar la conexión del servidor VCC:
# 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-MCPPregunte a Claude:
Abre la ventana de ondas y añade todas las señales del banco de pruebas desde div_tb
Claude llama a:
vcc_eval("view wave")
vcc_wave_add(["sim.div_tb.*"])Todas las señales del banco de pruebas de nivel superior (clk_s, reset_s, dividend_s, divisor_s, quotient_s, remainder_s, start_s, busy_s) aparecen en la ventana de ondas de Visualizer.
Pregunte a Claude:
Ejecuta la simulación durante 8 microsegundos
Claude llama a:
vcc_run("8 us")La simulación avanza a 8 µs. Las formas de onda se actualizan en la GUI de Visualizer, mostrando todas las operaciones de división realizadas por el banco de pruebas.
Pregunte a Claude:
¿Alguna vez remainder_s fue igual a 23 durante la simulación?
Claude responde con:
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 0sPuede continuar la investigación preguntando a Claude:
en el tiempo 4651 ns, ¿puedes confirmar si el valor de quotient_s y remainder_s son correctos para los valores de entrada dados en dividend_s y divider_s?
Claude responde con:
● 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 8sControlar Visualizer desde un prompt de Claude Code es lento y no muy efectivo (en términos de costo), ya que los comandos simples consumirán tokens. Obviamente es más fácil ejecutar un archivo .do o qrun. Sin embargo, la razón de la demostración es mostrar lo que es posible; dejar que el LLM controle la simulación y verificar los resultados es muy interesante.
La mayor parte de este código fue creado por Claude Code 4.6
Siemens tiene un servidor MCP de Questa/Visualizer mucho más capaz llamado Questa Agentic Toolkit.
Consulte el archivo LICENSE para obtener detalles sobre esta demostración.
Todos los logotipos, marcas comerciales y gráficos utilizados en este documento son propiedad de sus respectivos dueños.
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.
