Skip to main content
Glama
deenesjakoruzh
kfy123bot

EDA Tools MCP Server

by kfy123bot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Servidor MCP de herramientas EDA

Implementación del artículo: MCP4EDA: LLM-Powered Model Context Protocol RTL-to-GDSII Automation with Backend Aware Synthesis Optimization

Un servidor completo de Model Context Protocol (MCP) que proporciona integración de herramientas de Automatización de Diseño Electrónico (EDA) para asistentes de IA como Claude Desktop y Cursor IDE. Este servidor permite a la IA realizar síntesis de Verilog, simulación, flujos de diseño ASIC y análisis de formas de onda a través de una interfaz unificada.

Demo

https://github.com/user-attachments/assets/65d8027e-7366-49b5-8f11-0430c1d1d3d6

Demostración del servidor EDA MCP mostrando síntesis de Verilog, simulación y flujo de diseño ASIC

Related MCP server: Xcelium MCP Server

Características

  • Síntesis de Verilog: Sintetiza código Verilog usando Yosys para varios objetivos FPGA (genérico, ice40, xilinx)

  • Simulación de Verilog: Simula diseños usando Icarus Verilog con ejecución automatizada de bancos de pruebas (testbenches)

  • Visualización de formas de onda: Inicia GTKWave para la visualización de archivos VCD y análisis de señales

  • Flujo de diseño ASIC: Flujo completo de RTL a GDSII usando OpenLane con integración de Docker

  • Visualización de diseño (Layout): Abre archivos GDSII en KLayout para inspección de diseño físico

  • Análisis de informes: Lee y analiza informes de OpenLane para métricas PPA y evaluación de la calidad del diseño

Requisitos previos

Antes de usar este servidor MCP, necesitas instalar las siguientes herramientas EDA:

1. Yosys (Síntesis de Verilog)

macOS (Homebrew):

brew install yosys

Ubuntu/Debian:

sudo apt-get update
sudo apt-get install yosys

Desde el código fuente:

# Install prerequisites
sudo apt-get install build-essential clang bison flex \
    libreadline-dev gawk tcl-dev libffi-dev git \
    graphviz xdot pkg-config python3 libboost-system-dev \
    libboost-python-dev libboost-filesystem-dev zlib1g-dev

# Clone and build
git clone https://github.com/YosysHQ/yosys.git
cd yosys
make -j$(nproc)
sudo make install

Alternativa - OSS CAD Suite (Recomendado): Descarga la cadena de herramientas completa desde: https://github.com/YosysHQ/oss-cad-suite-build/releases

2. Icarus Verilog (Simulación)

macOS (Homebrew):

brew install icarus-verilog

Ubuntu/Debian:

sudo apt-get install iverilog

Windows: Descarga el instalador desde: https://bleyer.org/icarus/

3. GTKWave (Visualizador de formas de onda)

Descargas directas (Recomendado):

  • Windows: Descargar desde SourceForge

  • macOS: Descargar desde SourceForge o usa Homebrew: brew install --cask gtkwave

  • Linux: Descargar desde SourceForge o usa el gestor de paquetes: sudo apt-get install gtkwave

Métodos de instalación alternativos:

# macOS (Homebrew)
brew install --cask gtkwave

# Ubuntu/Debian
sudo apt-get install gtkwave

# Build from source (all platforms)
git clone https://github.com/gtkwave/gtkwave.git
cd gtkwave
meson setup build && cd build && meson install

4. Docker Desktop (Recomendado para OpenLane)

Descargas directas:

Instalación:

  1. Descarga e instala Docker Desktop desde el sitio web oficial

  2. Inicia Docker Desktop y asegúrate de que esté ejecutándose

  3. Verifica la instalación: docker run hello-world

Nota: Docker Desktop incluye Docker Engine, Docker CLI y Docker Compose en un solo paquete.

5. OpenLane (Flujo de diseño ASIC)

Método de instalación simple (Recomendado):

# Install OpenLane via pip
pip install openlane

# Pull the Docker image
docker pull efabless/openlane:latest

# Verify installation
docker run hello-world

Ejemplo de uso:

# Create project directory
mkdir -p ~/openlane-projects/my-design
cd ~/openlane-projects/my-design

# Create Verilog file (counter example)
cat > counter.v << 'EOF'
module counter (
    input wire clk,
    input wire rst,
    output reg [7:0] count
);
    always @(posedge clk or posedge rst) begin
        if (rst)
            count <= 8'b0;
        else
            count <= count + 1;
    end
endmodule
EOF

# Create configuration file
cat > config.json << 'EOF'
{
    "DESIGN_NAME": "counter",
    "VERILOG_FILES": ["counter.v"],
    "CLOCK_PORT": "clk",
    "CLOCK_PERIOD": 10.0
}
EOF

# Run the RTL-to-GDSII flow
python3 -m openlane --dockerized config.json

Beneficios clave:

  • La bandera --dockerized maneja todas las dependencias de herramientas automáticamente a través de Docker

6. KLayout (Visualizador de diseño)

Descargas directas (Recomendado):

Instalación alternativa:

# macOS (Homebrew)
brew install --cask klayout

# Ubuntu/Debian
sudo apt install klayout

Instalación

1. Clonar y compilar el servidor MCP

git clone https://github.com/NellyW8/mcp-EDA
cd mcp-EDA
npm install
npm run build
npx tsc

2. Estructura del proyecto

mcp-EDA/
├── src/
│   └── index.ts          # Main server code
├── build/
│   └── index.js          # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.md

Configuración

Integración de Docker Desktop MCP

Este método utiliza la extensión MCP integrada de Docker Desktop para la experiencia de configuración más sencilla.

Requisitos previos

  • Docker Desktop 4.39.0+ instalado y ejecutándose

  • Claude Desktop instalado

Pasos de configuración

  1. Instalar la extensión de Docker Desktop:

    • Inicia Docker Desktop

    • Ve a "Extensions" en el menú de la izquierda

    • Busca "AI Tools" o "Docker MCP Toolkit"

    • Instala la extensión "Labs: AI Tools for Devs"

  2. Configurar la conexión Docker MCP:

    • Abre la extensión instalada "Labs: AI Tools for Devs"

    • Haz clic en el icono de engranaje en la esquina superior derecha

    • Selecciona la pestaña "MCP Clients"

    • Haz clic en "Connect" para "Claude Desktop" o "Cursor IDE"

    Esto configura automáticamente Claude Desktop y Cursor IDE con:

    {
  "mcpServers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "alpine/socat",
        "STDIO",
        "TCP:host.docker.internal:8811"
      ]
    }
  }
}

Configuración de Cursor IDE

  1. Añade tu servidor EDA MCP:

    • Localiza tu archivo de configuración de Claude Desktop, Settings > Developer > Edit Config:

      • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

      • Windows: %APPDATA%\Claude\claude_desktop_config.json

    • Añade tu servidor EDA a la configuración existente:

    {
  "mcpServers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "alpine/socat",
        "STDIO",
        "TCP:host.docker.internal:8811"
      ]
    },
    "eda-mcp": {
      "command": "node",
      "args": [
        "/absolute/path/to/your/eda-mcp-server/build/index.js"
      ],
      "env": {
        "PATH": "/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin",
        "HOME": "/your/home/directory"
      }
    }
  }
}

  2. Reinicia Claude Desktop y verifica que ambos servidores se estén ejecutando en Settings > Developer.

Configuración de Cursor IDE

  1. Abrir la configuración de Cursor:

    • Presiona Ctrl + Shift + P (Windows/Linux) o Cmd + Shift + P (macOS)

    • Busca "Cursor Settings"

    • Navega a "MCP" en la barra lateral

  2. Añadir servidor MCP: Haz clic en "Add new MCP server" y configura:

     {
  "mcpServers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "alpine/socat",
        "STDIO",
        "TCP:host.docker.internal:8811"
      ]
    },
    "eda-mcp": {
      "command": "node",
      "args": [
        "/absolute/path/to/your/eda-mcp-server/build/index.js"
      ],
      "env": {
        "PATH": "/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin",
        "HOME": "/your/home/directory"
      }
    }
  }
}

  3. Habilitar herramientas MCP:

    • Ve a Cursor Settings → MCP

    • Habilita el servidor "eda-mcp"

    • Deberías ver que el estado del servidor cambia a "Connected"

Ejemplos de uso

1. Síntesis de Verilog

Ask Claude: "Can you synthesize this counter module for an ice40 FPGA?"

module counter(
    input clk,
    input rst,
    output [7:0] count
);
    reg [7:0] count_reg;
    assign count = count_reg;
    
    always @(posedge clk or posedge rst) begin
        if (rst)
            count_reg <= 8'b0;
        else
            count_reg <= count_reg + 1;
    end
endmodule

2. Simulación de Verilog

Ask Claude: "Please simulate this adder with a testbench"

// Design
module adder(
    input [3:0] a,
    input [3:0] b,
    output [4:0] sum
);
    assign sum = a + b;
endmodule

// Testbench will be generated automatically or you can provide one

3. Flujo de diseño ASIC

Ask Claude: "Run the complete ASIC flow for this design with a 10ns clock period"

module simple_cpu(
    input clk,
    input rst,
    input [7:0] data_in,
    output [7:0] data_out
);
    // Your RTL design here
endmodule

Qué obtienes tras finalizar:

  • runs/RUN_*/final/gds/design.gds - Diseño GDSII final

  • runs/RUN_*/openlane.log - Registro de ejecución completo

  • runs/RUN_*/reports/ - Informes de análisis de temporización, área y potencia

  • Todos los resultados intermedios (archivos DEF, netlists, etc.)

4. Análisis de formas de onda

Ask Claude: "View the waveforms from the simulation with project ID: abc123"

Solución de problemas

Problemas comunes

  1. Servidor MCP no detectado:

    • Verifica la ruta absoluta en la configuración

    • Comprueba que Node.js esté instalado y accesible

    • Reinicia Claude Desktop/Cursor después de los cambios de configuración

  2. Errores de permisos de Docker:

    sudo groupadd docker
sudo usermod -aG docker $USER
sudo reboot

  3. Errores de herramienta no encontrada:

    • Verifica que las herramientas estén instaladas: yosys --version, iverilog -V, gtkwave --version

    • Comprueba la variable de entorno PATH en la configuración de MCP

    • En macOS, asegúrate de que las rutas de Homebrew estén incluidas: /opt/homebrew/bin

  4. Tiempo de espera (Timeout) de OpenLane:

    • El servidor tiene un tiempo de espera de 10 minutos para los flujos de OpenLane

    • Para diseños complejos, considera simplificar o ejecutar múltiples iteraciones

  5. Problemas de GUI de GTKWave/KLayout:

    • En macOS: GTKWave/KLayout pueden necesitar aprobación manual en la configuración de Seguridad y Privacidad

    • En Linux: Asegúrate de que el reenvío X11 funcione si usas sistemas remotos

    • En Windows: Asegúrate de que las aplicaciones GUI puedan iniciarse desde la línea de comandos

Depuración

  1. Comprobar los registros del servidor MCP:

    • Claude Desktop: ~/Library/Logs/Claude/mcp*.log (macOS)

    • Cursor: Comprueba el panel de configuración de MCP para ver mensajes de error

  2. Probar herramientas manualmente:

    yosys -help
iverilog -help
docker run hello-world
gtkwave --version
klayout -v

  3. Verificar el entorno de Node.js:

    node --version
npm --version

Soporte

Para problemas y preguntas:

  • Consulta la sección de solución de problemas anterior

  • Revisa los registros del servidor MCP

  • Prueba las herramientas individuales manualmente

  • Abre un issue con mensajes de error detallados e información del entorno

Nota: Este servidor MCP requiere la instalación local de herramientas EDA. El servidor actúa como un puente entre los asistentes de IA y tu cadena de herramientas EDA local, permitiendo flujos de trabajo de diseño de hardware sofisticados a través de la interacción en lenguaje natural.

Citar

@misc{wang2025mcp4edallmpoweredmodelcontext,
      title={MCP4EDA: LLM-Powered Model Context Protocol RTL-to-GDSII Automation with Backend Aware Synthesis Optimization}, 
      author={Yiting Wang and Wanghao Ye and Yexiao He and Yiran Chen and Gang Qu and Ang Li},
      year={2025},
      eprint={2507.19570},
      archivePrefix={arXiv},
      primaryClass={cs.AR},
      url={https://arxiv.org/abs/2507.19570}, 
}

Available Tools

6 tools
read_openlane_reportsB

Read OpenLane report files for LLM analysis. Returns all reports or specific category for detailed analysis of PPA metrics, timing, routing quality, and other design results.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProject ID from OpenLane run
report_typeNoSpecific report category to read (synthesis, placement, routing, final, etc.). Leave empty to read all reports.

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool reads reports and returns data for analysis, but lacks details on permissions needed, rate limits, error handling, or whether it's read-only (implied by 'read' but not explicit). For a tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with two sentences that efficiently convey purpose and scope. It's front-loaded with the main function ('Read OpenLane report files for LLM analysis') and follows with additional context. No wasted words, though it could be slightly more structured for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 parameters with full schema coverage and no output schema, the description adequately covers the tool's purpose and general use. However, as a read operation with no annotations, it should ideally mention safety (e.g., read-only) or data format expectations. The lack of output schema means the description doesn't explain return values, which is a gap for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('project_id' and 'report_type') with clear descriptions. The description adds marginal value by mentioning 'specific category' and 'detailed analysis of PPA metrics, timing, routing quality', which aligns with the schema but doesn't provide additional syntax or format details beyond what's in the schema.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Read OpenLane report files for LLM analysis' specifies the verb (read) and resource (OpenLane report files). It distinguishes from siblings like 'run_openlane' or 'view_gds' by focusing on report analysis rather than execution or visualization. However, it doesn't explicitly differentiate from 'view_waveform' which might also involve reading data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('for LLM analysis' and 'detailed analysis of PPA metrics, timing, routing quality') but doesn't explicitly state when to use this tool versus alternatives like 'run_openlane' for execution or 'view_gds' for visualization. No exclusions or prerequisites are mentioned, leaving usage guidance at an implied level.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_openlaneA

Run complete ASIC design flow using OpenLane (RTL to GDSII). This process can take up to 10 minutes.

ParametersJSON Schema
NameRequiredDescriptionDefault
verilog_codeYesThe Verilog RTL code for ASIC implementation
design_nameYesName of the design (will be used for module and files)
clock_portNoName of the clock portclk
clock_periodNoClock period in nanoseconds
open_in_klayoutNoAutomatically open result in KLayout

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses the critical time constraint ('can take up to 10 minutes'), which is valuable behavioral context. However, it doesn't mention other traits like error handling, resource requirements, or output format, leaving significant gaps for a complex execution tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste: the first states purpose and scope, the second adds crucial behavioral context (time constraint). Every element earns its place, and information is front-loaded appropriately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 5-parameter tool with no annotations and no output schema, the description is incomplete. It covers purpose and time constraint but lacks information about what happens after execution, error conditions, or relationship to sibling tools like 'view_gds' for results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing full parameter documentation. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for high coverage without compensating value.

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

Purpose5/5

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

The description clearly states the specific action ('Run complete ASIC design flow') and resource ('using OpenLane'), with precise scope ('RTL to GDSII'). It effectively distinguishes from siblings like 'synthesize_verilog' (partial flow) and 'read_openlane_reports' (analysis only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for full ASIC implementation from RTL, but doesn't explicitly state when to choose this over alternatives like 'synthesize_verilog' for partial flow or 'simulate_verilog' for verification. No guidance on prerequisites or exclusions is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulate_verilogC

Simulate Verilog code using Icarus Verilog

ParametersJSON Schema
NameRequiredDescriptionDefault
verilog_codeYesThe Verilog design code
testbench_codeYesThe testbench code

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('simulate') but doesn't explain what the simulation does (e.g., runs tests, generates waveforms), potential side effects, error handling, or output format. This leaves critical behavioral traits unspecified for a tool that likely produces results or logs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It front-loads the core purpose and includes the tool implementation detail ('Icarus Verilog'), making it appropriately sized and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of simulation tools, no annotations, and no output schema, the description is incomplete. It doesn't cover what the simulation returns (e.g., success/failure, waveforms, logs), error conditions, or how it integrates with siblings like 'view_waveform'. This gap makes it insufficient for an agent to fully understand the tool's behavior and outputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters ('verilog_code' and 'testbench_code'). The description adds no additional parameter semantics beyond what the schema provides, such as code format expectations or examples. The baseline score of 3 reflects adequate schema coverage without extra value from the description.

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

Purpose4/5

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

The description clearly states the action ('simulate') and target ('Verilog code'), and specifies the tool used ('Icarus Verilog'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'synthesize_verilog' or 'view_waveform', which might be related operations in the same domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing both design and testbench code), compare to siblings like 'run_openlane' or 'view_waveform', or specify scenarios where simulation is appropriate over other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

synthesize_verilogC

Synthesize Verilog code using Yosys for various FPGA targets

ParametersJSON Schema
NameRequiredDescriptionDefault
verilog_codeYesThe Verilog source code to synthesize
top_moduleYesName of the top-level module
targetNoTarget technology (generic, ice40, xilinx, intel)generic

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but provides minimal behavioral context. It mentions the tool (Yosys) and target types, but doesn't disclose execution details like runtime, error handling, output format, or resource requirements, leaving significant gaps for a synthesis operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads key information (synthesize Verilog code). It avoids redundancy but could be more structured by separating tool details from target scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete for a synthesis tool. It lacks details on behavioral traits, output format, error conditions, and integration with sibling tools, failing to compensate for the missing structured information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional parameter semantics beyond implying synthesis for FPGA targets, which aligns with the target parameter but doesn't enhance understanding of verilog_code or top_module beyond the schema.

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

Purpose4/5

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

The description clearly states the action ('synthesize') and resource ('Verilog code'), specifying the tool (Yosys) and target scope (FPGA targets). It distinguishes from siblings like simulate_verilog or run_openlane by focusing on synthesis rather than simulation or full flows, though it doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. While the description implies synthesis for FPGA targets, it doesn't specify prerequisites, when not to use it, or compare it to siblings like simulate_verilog for verification or run_openlane for complete implementation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

view_gdsC

Open GDSII file in KLayout viewer

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProject ID from OpenLane run
gds_fileNoSpecific GDS filename (optional, auto-detected if not provided)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Open') but doesn't describe what happens (e.g., launches a viewer, requires GUI access, may be interactive, or returns status). It lacks details on permissions, side effects, or error handling for a tool that likely involves external applications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of opening a file in an external viewer (which may involve GUI dependencies, error states, or interactive behavior), the description is insufficient. With no annotations and no output schema, it doesn't address what the tool returns, how failures are handled, or any system requirements, leaving significant gaps for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters fully. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain the relationship between project_id and gds_file, or typical use cases for providing gds_file). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Open') and the resource ('GDSII file in KLayout viewer'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'view_waveform' which might also involve viewing operations in different contexts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing OpenLane project), exclusions, or comparisons to sibling tools like 'read_openlane_reports' or 'view_waveform'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

view_waveformB

Open VCD waveform file in GTKWave viewer

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProject ID from simulation (required)
vcd_fileNoVCD filename (default: output.vcd)output.vcd

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool opens a viewer (implying a UI action), but doesn't mention whether this launches an external application, requires GUI access, blocks execution, or has side effects. For a tool that likely interacts with external software, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function with zero wasted words. It's appropriately sized for a simple tool and front-loads the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (opening a waveform viewer), lack of annotations, and no output schema, the description is minimally adequate. It explains what the tool does but omits important behavioral context (e.g., how the viewer launches, what happens on success/failure). The schema covers parameters well, but overall completeness is limited.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters (project_id and vcd_file). The description adds no parameter-specific information beyond what's in the schema. This meets the baseline expectation when the schema does all the work.

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

Purpose4/5

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

The description clearly states the action ('Open') and the resource ('VCD waveform file in GTKWave viewer'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'view_gds' (which likely opens GDS files), but the specific file format (VCD) and viewer (GTKWave) provide inherent differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a simulation result), when not to use it, or how it relates to sibling tools like 'simulate_verilog' or 'view_gds'. The agent must infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedread_openlane_reports
    • First observedrun_openlane
    • First observedsimulate_verilog
    • First observedsynthesize_verilog
    • First observedview_gds
    • First observedview_waveform
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: reading reports, running a full design flow, simulating, synthesizing, viewing GDSII files, and viewing waveforms. The descriptions specify unique actions and tools (OpenLane, Icarus Verilog, Yosys, KLayout, GTKWave), making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., read_openlane_reports, run_openlane, simulate_verilog) with no deviations. The naming is uniform and predictable across the set, using snake_case throughout.

Tool Count5/5

With 6 tools, the count is well-scoped for an EDA server, covering key stages like simulation, synthesis, viewing, and analysis. Each tool earns its place by addressing a specific need in the ASIC/FPGA design workflow without being excessive or sparse.

Completeness4/5

The tool set covers major EDA operations: simulation, synthesis, viewing, and report analysis, with no dead ends. A minor gap exists in lacking explicit CRUD operations for design files (e.g., create/edit Verilog), but agents can work around this using the provided tools for core workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • EDA Tools MCP Server

    NellyW8
    F
    license
    A
    quality
    F
    maintenance
    A comprehensive Model Context Protocol server that connects AI assistants to Electronic Design Automation tools, enabling Verilog synthesis, simulation, ASIC design flows, and waveform analysis through natural language interaction.
    6
    111
    -

  • mcp-verilog

    zesun33
    A
    license
    A
    quality
    B
    maintenance
    Enables AI coding agents and IDEs to lint, compile, syntax-check, and simulate Verilog/SystemVerilog designs through structured, token-efficient MCP tools with isolated containerized toolchains.
    4
    32 npm
    Apache 2.0