visualizer-mcp — это сервер Model Context Protocol (MCP), который подключает ИИ-ассистентов к Siemens Questa Visualizer через TCP-интерфейс Visualizer Command Channel (VCC). Он позволяет Claude Code управлять симуляцией в реальном времени с помощью естественного языка: открывать временные диаграммы, запускать проект, проверять значения сигналов и искать историю сигналов во времени. Visualizer поставляется со всеми версиями Questa, кроме OEM-версий(?).
Инструмент | Назначение | Примечания |
Python 3.10+ | Запуск MCP-сервера | |
uv | Установка сервера через | |
Siemens Visualizer | GUI симуляции, которым управляет сервер |
|
Claude Code | ИИ-ассистент, выполняющий вызовы инструментов |
Примечание: другие LLM также должны работать, но я использую Claude Code (по подписке).
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Проверьте регистрацию:
claude mcp listРабочая директория. По умолчанию сервер ищет файл подключения Visualizer (
.Visualizer/vccserver.cfg) относительно своей рабочей директории, которая является директорией, из которой вы запустилиclaude. Запускайте и Visualizer, и Claude Code из одной и той же директории симуляции, и дополнительная настройка не потребуется. Если они различаются, установитеVCC_WORK_DIR— см. Переменные окружения.
Claude Code ──stdio──► visualizer-mcp ──TCP──► Visualizer GUI
(LLM host) (MCP) (this server) (VCC) (Siemens EDA)Claude Code запускает visualizer-mcp как дочерний процесс через stdio (стандартный транспорт MCP). Сервер поддерживает одно постоянное TCP-соединение с сервером Visualizer Command Channel (VCC), который запускается автоматически внутри каждого сеанса Visualizer.
Последовательность подключения:
При первом вызове инструмента сервер считывает $VCC_WORK_DIR/.Visualizer/vccserver.cfg. Visualizer записывает этот файл при запуске; он содержит хост и порт VCC в формате port@hostname.
Сервер открывает TCP-сокет, отправляет vccRegisterClient и подписывается на уведомления vDesignStateChange, vTimeChange и vHierarchyChange.
Каждый вызов инструмента кодирует команду Tcl в кадр VCC (10-байтовый заголовок + тело, ограниченное фигурными скобками), отправляет его через сокет и ожидает соответствующий кадр ответа. Кадры сопоставляются с вызывающими объектами по инкрементному номеру сообщения.
Асинхронные уведомления о сигналах (например, изменения времени, изменения состояния проекта) поступают как нежелательные кадры типа s и сохраняются в кольцевом буфере на 256 записей, доступном через vcc_recent_signals.
Если Visualizer закрывается и сокет разрывается, сервер переподключается (или автоматически запускает Visualizer) при следующем вызове инструмента.
Каждая команда Tcl Visualizer, описанная в Visualizer Debug Environment Command Reference Manual — run, step, wave add, examine, force, env и сотни других — доступна через «черный ход» vcc_eval.
Все инструменты возвращают {"ok": true, "result": "..."} в случае успеха или {"ok": false, "error": "..."} в случае ошибки.
Инструмент | Описание |
| Подключение к Visualizer (автозапуск при необходимости). Идемпотентно. |
| Отчет о наличии файла конфигурации, хосте/порте и состоянии подключения. Не подключается. |
| Отправка любой команды Tcl дословно — здесь доступен полный набор команд Visualizer. |
| Продвижение симуляции: |
| Пошаговое выполнение симулятора на N дельта-циклов. |
| Возврат текущего состояния выполнения симулятора. |
| Возврат текущего времени симуляции. |
| Добавление одного или нескольких сигналов в окно временных диаграмм по иерархическому пути. |
| Принудительная установка значения сигнала, опционально в определенное время симуляции. |
| Чтение значения сигнала в текущее или указанное время симуляции. |
| Сканирование сигнала в диапазоне времени; опционально поиск конкретного значения. |
| Возврат самых последних асинхронных уведомлений о сигналах от Visualizer. |
Переменная | По умолчанию | Описание |
| CWD сервера | Директория, чей |
| (не задано) | Явный путь к файлу конфигурации; переопределяет поиск |
|
| Имя, отправляемое с |
|
| Бинарный файл, используемый при автозапуске Visualizer. |
|
| Секунды ожидания файла конфигурации после запуска Visualizer. |
|
| Тайм-аут для каждой команды в секундах. |
Чтобы установить переменную окружения при регистрации сервера:
# Linux
claude mcp add visualizer \
-e VCC_WORK_DIR=/path/to/sim \
-- uvx --from git+https://github.com/htminuslab/visualizer-mcp visualizer-mcp
# Windows
claude mcp add visualizer `
-e "VCC_WORK_DIR=C:\path\to\sim" `
-- uvx --from git+https://github.com/htminuslab/visualizer-mcp visualizer-mcpДиректория vhdl_example/ содержит 32-битный невосстанавливающий целочисленный делитель (div.vhd) и тестовый стенд (div_tb.vhd). Тестовый стенд проверяет как беззнаковое, так и знаковое деление для нескольких пар операндов. Это пошаговое руководство показывает, как использовать Claude Code для компиляции, симуляции и исследования проекта.
Откройте терминал/командную строку, перейдите в vhdl_example/ и запустите Visualizer с помощью:
cd vhdl_example
visualizer -do run.dorun.do компилирует исходные коды VHDL, оптимизирует проект до div_tb_vopt и загружает его в симулятор с помощью vsim -visualizer. Появится графический интерфейс Visualizer с симуляцией, приостановленной на времени 0.
Откройте новый терминал в той же директории vhdl_example/ и запустите Claude Code:
cd vhdl_example
claudeВнутри Claude Code введите следующую команду, чтобы подтвердить, что MCP-сервер подключен:
/mcpВы должны увидеть visualizer в списке подключенных серверов. Вы также можете спросить Claude напрямую:
Доступны ли инструменты Visualizer MCP?
Claude подтвердит и перечислит доступные инструменты.
В окне транскрипта Visualizer должно быть указано подключение сервера 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-MCPСпросите Claude:
Открой окно временных диаграмм и добавь все сигналы тестового стенда из div_tb
Claude вызывает:
vcc_eval("view wave")
vcc_wave_add(["sim.div_tb.*"])Все сигналы тестового стенда верхнего уровня (clk_s, reset_s, dividend_s, divisor_s, quotient_s, remainder_s, start_s, busy_s) появятся в окне временных диаграмм Visualizer.
Спросите Claude:
Запусти симуляцию на 8 микросекунд
Claude вызывает:
vcc_run("8 us")Симуляция продвигается до 8 мкс. Временные диаграммы обновляются в графическом интерфейсе Visualizer, показывая все операции деления, выполненные тестовым стендом.
Спросите Claude:
Равнялся ли remainder_s когда-нибудь 23 во время симуляции?
Claude отвечает:
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 0sВы можете продолжить исследование, спросив Claude:
в момент времени 4651 нс можешь ли ты подтвердить, что значения quotient_s и remainder_s верны для заданных входных значений dividend_s и divider_s?
Claude отвечает:
● 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 8sУправление Visualizer из командной строки Claude Code происходит медленно и не очень эффективно (с точки зрения затрат), так как простые команды потребляют токены. Очевидно, проще запустить файл .do или qrun. Однако цель этой демонстрации — показать, что возможно, и позволить LLM управлять симуляцией и проверять результаты — это очень интересно.
Большая часть этого кода была создана Claude Code 4.6
У Siemens есть гораздо более мощный MCP-сервер для Questa/Visualizer под названием Questa Agentic Toolkit.
Подробности см. в файле LICENSE для этой демонстрации.
Все логотипы, товарные знаки и графические изображения, используемые здесь, являются собственностью их соответствующих владельцев.
Ensure Visualizer is running and the VCC socket is open. Idempotent.
Returns an error with instructions if Visualizer is not running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses idempotency and error behavior (returns error with instructions if Visualizer not running). This is sufficient behavioral context for a connection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, zero wasted words. The critical information (purpose, idempotency, error behavior) is front-loaded. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema (not shown but indicated), the description covers all essential aspects: what it does, side effects (idempotent), and error handling. Complete for a simple connection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description does not need to add parameter meaning. It simply states the tool takes no arguments, which aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: ensuring Visualizer is running and the VCC socket is open. It uses a specific verb ('Ensure') and resource ('Visualizer' and 'VCC socket'). However, it does not explicitly distinguish from sibling tools like vcc_eval or vcc_run, which are likely dependent on prior connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: before other VCC operations, and returns an error with instructions if Visualizer is not running. However, it lacks explicit guidance on when not to use (e.g., if already connected) or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send any Tcl command to Visualizer's command interpreter.
This is the escape hatch — every Visualizer Tcl command (run, step, wave add, force, examine, env, ...) can be sent through this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tcl | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose important behavioral traits such as potential side effects, error handling, execution guarantees, or the format of the output (despite an output schema existing). The claim 'send any Tcl command' lacks nuance about safety or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and uses the second sentence to reinforce the breadth of use. Every part contributes meaning without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (an arbitrary command executor) and the presence of sibling tools, the description lacks critical details: parameter semantics for timeout_s, behavioral implications, and guidance on when to use this vs. specialized tools. The existence of an output schema reduces some burden, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value for the 'tcl' parameter by explaining it accepts any Visualizer Tcl command and listing examples. However, it does not mention the 'timeout_s' parameter at all. With 0% schema description coverage, the description partially compensates but leaves one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends any Tcl command to Visualizer's command interpreter and provides specific examples (run, step, wave add, etc.), distinguishing it from the more specific sibling tools by calling it an 'escape hatch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it can be used for any Visualizer Tcl command, implying it's a fallback. However, it does not explicitly say when to prefer specific sibling tools over this one, nor does it mention any prerequisites or limitations. The guidance is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Examine the value of a signal, optionally at a specific simulation time.
signal: dot-separated hierarchical path with "sim." prefix e.g. sim.testbench.u1.my_signal time: simulation time e.g. "400 ns" (omit for current time) radix: decimal (default), binary, hexadecimal, unsigned, octal
The returned value may include a size/radix annotation e.g. "4'd3" (4-bit vector, decimal value 3). If Visualizer is not configured to annotate, the plain value is returned e.g. "3". Signal must be last in the examine command; this tool enforces that.
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | ||
| time | No | ||
| radix | No | decimal |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses return value format (size/radix annotation vs plain), and a behavioral constraint (signal must be last, enforced). This is good transparency for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (10 lines), well-structured with a purpose sentence followed by parameter details in bullet-like format. No fluff, every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, output schema exists but description explains return value), the description is complete. It covers parameter formats, return behavior, and a usage constraint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully: explains signal path format (dot-separated with 'sim.' prefix), time examples ('400 ns'), and radix options. This adds critical meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool examines a signal value with optional time and radix. It uses specific verb 'Examine' and resource 'signal value', and the context of sibling tools (e.g., vcc_force, vcc_eval) makes its distinct purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed parameter usage: signal format, time semantics (omit for current time), radix options. It also notes a special constraint ('Signal must be last…'). While it doesn't explicitly compare to siblings, the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force signal to value (e.g. force sim.top.rst 1 0; force sim.top.clk 0 50ns).
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | ||
| value | Yes | ||
| time | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose that forcing overrides normal simulation behavior, whether it is temporary, or any side effects like destroying prior state. The term 'force' implies mutation but lacks detail on impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus example with no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers the core action but omits context on signal path conventions, time format rigor, and interaction with other simulation states. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds meaning via example: signal is a path, value is a value like 0/1, time is optional and appears in units like '0' or '50ns'. However, the format of time is not explicitly documented, and the schema properties lack descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Force `signal` to `value`' with an example, making the verb and resource explicit. It distinguishes from siblings like vcc_examine (read) and vcc_eval, as forcing is a distinct write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like vcc_eval or vcc_connect. The description does not mention when not to use it or provide context for prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current simulation time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation (returning a value). For a simple getter with no parameters, this is adequate and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the return value format (e.g., units of time). However, an output schema exists which may provide this. Given the tool's simplicity, it is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and 100% schema coverage. The description adds no parameter detail, but baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return the current simulation time.' clearly states the action (return) and the resource (simulation time). It is specific and distinguishes from sibling tools like vcc_force or vcc_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives, or any prerequisites. The description only states what it does, not when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent async signal notifications received from Visualizer (e.g. vTimeChange, vDesignStateChange). Newest last.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does indicate the type of notifications (async) and ordering, but does not disclose potential side effects, rate limits, or behavior when no signals are available. Some context is given, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the purpose and include an illustrative example. Every word adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with one parameter and an output schema, but the description still omits practical details like parameter semantics and common error scenarios. It is minimally complete but could better cover usage context without overcomplicating.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'limit' parameter with no description (0% coverage). The tool description does not mention the parameter or its effect, leaving the agent to guess. Although the name 'limit' is somewhat intuitive, the description should clarify how it controls the number of returned notifications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent async signal notifications from Visualizer, with concrete examples (vTimeChange, vDesignStateChange) and specifies ordering (newest last). This is specific and distinguishes it from sibling tools that handle other simulation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like vcc_scan_signal (for current values) or vcc_get_time. The description lacks any 'when to use' or 'when not to use' information, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advance simulation. time may be "100ns", "-all", or None for default.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description explains the parameter constraint but does not disclose side effects, permissions, or return value. The presence of an output schema is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words, front-loading the action and parameter guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter; covers the essential behavior but omits output details and explicit sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining that 'time' can be a string like '100ns', '-all', or None, adding meaning beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Advance simulation' uses a specific verb ('Advance') and resource ('simulation'), clearly distinguishing it from sibling tools like vcc_connect, vcc_eval, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit examples for the 'time' parameter ('100ns', '-all', None), but does not directly contrast with similar tools like vcc_step or vcc_run_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report runStatus (current simulator state).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description must fully disclose behavior. It only states 'Report runStatus' with no mention of side effects, idempotency, or whether it affects simulator state. This is inadequate for a tool that modifies no state but still needs transparency about its read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 5 words, but it borders on under-specification. While it is front-loaded, it does not earn its place by providing sufficient detail; it omits crucial context about the return format or use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description should explain the semantics of 'runStatus' to help the agent interpret results. It fails to do so, and the presence of sibling vcc_status creates ambiguity about what this tool returns versus that one. The description is too brief for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the baseline score is 4 per guidelines. The description adds the meaning 'current simulator state' beyond the empty schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the current simulator state ('runStatus'). It uses a specific verb and resource, and the name implies a query operation, which distinguishes it from siblings like vcc_run (run simulation) and vcc_step (step simulation). However, it could be more explicit about what 'runStatus' specifically contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as vcc_status or vcc_eval. The agent has to infer usage from the name alone, which is insufficient for choosing correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a signal across a time range; optionally search for a specific value.
Returns all sampled values across the range as a Tcl list. If find_value is given, also reports whether the signal ever held that value (handles both plain "3" and annotated forms like "4'd3"). When find_value is given and no time range is specified, the scan starts from time 0 to cover the full simulation.
signal: dot-separated hierarchical path with "sim." prefix e.g. sim.testbench.u1.my_signal find_value: value to search for e.g. "6" (optional) from_time: range start e.g. "0 ns" (defaults to "0" when find_value given) to_time: range end e.g. "1 us" (omit to scan to simulation end) radix: decimal (default), binary, hexadecimal, unsigned, octal
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | ||
| find_value | No | ||
| from_time | No | ||
| to_time | No | ||
| radix | No | decimal |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It transparently describes return values (Tcl list), the search logic, handling of annotated values, and default time ranges. It does not explicitly state it is read-only, but the scanning nature implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary followed by detailed parameter explanations. Every sentence adds value, and there is no redundancy or unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema provided, the description covers all aspects: purpose, parameter behaviors, return format, and special cases. It is complete and leaves no obvious gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: signal format, find_value optionality, from_time/to_time default behaviors, and radix options. It adds meaning beyond the schema, such as the default radix and the behavior when to_time is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a signal across a time range and optionally searches for a value. It provides a specific verb and resource, distinguishing it from siblings like vcc_examine (which examines a single signal) and vcc_force (which forces a value).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behaviors (e.g., from_time defaults to 0 when find_value is given) and signal format requirements. However, it does not explicitly state when to use this tool versus alternatives like vcc_examine or vcc_get_time, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report VCC server reachability, host/port, and registration status.
Does NOT auto-launch. Use vcc_connect (or any other tool) to trigger
an auto-launch if Visualizer is not running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral property (no auto-launch) and indicates read-only reporting. With no annotations, description covers main trait; could mention if any side effects exist but none expected for a status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, and a separate line for non-auto-launch guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is complete for a 0-param status tool with output schema. Key behavior (no auto-launch) and purpose are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4. Description adds no parameter info, but none needed; schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it reports server reachability, host/port, and registration status. This specific verb+resource distinguishes it from sibling tools like vcc_connect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Does NOT auto-launch' and directs to use vcc_connect for auto-launch, providing clear when-to-use and when-not-to-use with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single-step the simulation count times.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the burden of disclosing behavioral traits. It does not mention side effects, error conditions, or the impact of stepping multiple times in a single call. The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly stating the action and parameter. It is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description is insufficient for an agent to use it correctly. It does not mention what happens after stepping (e.g., simulation advances), whether the simulation must be paused, or how to interpret the output (output schema exists but is not described).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its single parameter 'count'. The description does not elaborate on what 'count' means (e.g., number of simulation steps) or any constraints like non-negative values. The default value is noted in the schema but not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (single-step) and the resource (simulation) with the parameter 'count' indicating how many times. This distinguishes it from sibling tools like vcc_run (which runs continuously) and vcc_force (which manipulates signals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., simulation must be running) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one or more signals to the wave window. Use dot-separated paths with "sim." prefix, e.g. ["sim.top.clk", "sim.top.dut.state", "sim.div_tb.*"]
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description covers path format but lacks details on side effects, error handling, or additive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded action and example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core functionality and signal specification. Output schema exists to document return value, so no further detail needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description explains the format of array elements (dot-separated, 'sim.' prefix), adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it adds signals to the wave window, with specific syntax. Distinguishes from sibling tools like vcc_force.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage pattern and examples, but does not explicitly state when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0vcc_connectvcc_evalvcc_examinevcc_forcevcc_get_timevcc_recent_signalsvcc_runvcc_run_statusvcc_scan_signalvcc_statusvcc_stepvcc_wave_addMost tools have clear distinct purposes (connect, examine, run, step, etc.), but vcc_status and vcc_connect overlap in reporting connection status, and vcc_eval is an escape hatch that could replicate other tools. Minor ambiguity.
All tools share the vcc_ prefix, but the second part mixes verb_noun (connect, examine, run), noun_verb (wave_add), adjective_noun (recent_signals), and lone noun (status). Inconsistent structure.
12 tools cover essential simulation control, signal inspection, wave management, and connection setup. Well-scoped for a visualizer MCP server.
Core functions are covered, but some operations (e.g., removing waves, setting radix per signal) are missing and must be done via vcc_eval. Minor gaps that can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
Control your Tesla from your AI assistant - climate, charging, access, and security.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/htminuslab/visualizer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
