Skip to main content
Glama
NellyW8

EDA Tools MCP Server

by NellyW8
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

EDA Tools MCP Server

Implementation of the paper: MCP4EDA: LLM-Powered Model Context Protocol RTL-to-GDSII Automation with Backend Aware Synthesis Optimization

A comprehensive Model Context Protocol (MCP) server that provides Electronic Design Automation (EDA) tools integration for AI assistants like Claude Desktop and Cursor IDE. This server enables AI to perform Verilog synthesis, simulation, ASIC design flows, and waveform analysis through a unified interface.

Demo

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

EDA MCP Server demonstration showing Verilog synthesis, simulation, and ASIC design flow

Related MCP server: EDA Tools MCP Server

Features

  • Verilog Synthesis: Synthesize Verilog code using Yosys for various FPGA targets (generic, ice40, xilinx)

  • Verilog Simulation: Simulate designs using Icarus Verilog with automated testbench execution

  • Waveform Viewing: Launch GTKWave for VCD file visualization and signal analysis

  • ASIC Design Flow: Complete RTL-to-GDSII flow using OpenLane with Docker integration

  • Layout Viewing: Open GDSII files in KLayout for physical design inspection

  • Report Analysis: Read and analyze OpenLane reports for PPA metrics and design quality assessment

Prerequisites

Before using this MCP server, you need to install the following EDA tools:

1. Yosys (Verilog Synthesis)

macOS (Homebrew):

brew install yosys

Ubuntu/Debian:

sudo apt-get update
sudo apt-get install yosys

From Source:

# 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

Alternative - OSS CAD Suite (Recommended): Download the complete toolchain from: https://github.com/YosysHQ/oss-cad-suite-build/releases

2. Icarus Verilog (Simulation)

macOS (Homebrew):

brew install icarus-verilog

Ubuntu/Debian:

sudo apt-get install iverilog

Windows: Download installer from: https://bleyer.org/icarus/

3. GTKWave (Waveform Viewer)

Direct Downloads (Recommended):

  • Windows: Download from SourceForge

  • macOS: Download from SourceForge or use Homebrew: brew install --cask gtkwave

  • Linux: Download from SourceForge or use package manager: sudo apt-get install gtkwave

Alternative Installation Methods:

# 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 (Recommended for OpenLane)

Direct Downloads:

Installation:

  1. Download and install Docker Desktop from the official website

  2. Launch Docker Desktop and ensure it's running

  3. Verify installation: docker run hello-world

Note: Docker Desktop includes Docker Engine, Docker CLI, and Docker Compose in one package.

5. OpenLane (ASIC Design Flow)

Simple Installation Method (Recommended):

# Install OpenLane via pip
pip install openlane

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

# Verify installation
docker run hello-world

Usage Example:

# 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

Key Benefits:

  • The --dockerized flag handles all tool dependencies automatically via Docker

6. KLayout (Layout Viewer)

Direct Downloads (Recommended):

Alternative Installation:

# macOS (Homebrew)
brew install --cask klayout

# Ubuntu/Debian
sudo apt install klayout

Installation

1. Clone and Build the MCP Server

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

2. Project Structure

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

Configuration

Docker Desktop MCP Integration

This method uses Docker Desktop's built-in MCP extension for the easiest setup experience.

Prerequisites

  • Docker Desktop 4.39.0+ installed and running

  • Claude Desktop installed

Setup Steps

  1. Install Docker Desktop Extension:

    • Launch Docker Desktop

    • Go to "Extensions" from the left menu

    • Search for "AI Tools" or "Docker MCP Toolkit"

    • Install "Labs: AI Tools for Devs" extension

  2. Configure Docker MCP Connection:

    • Open the installed "Labs: AI Tools for Devs" extension

    • Click the gear icon in the upper right corner

    • Select the "MCP Clients" tab

    • Click "Connect" for "Claude Desktop" or "Cursor IDE"

    This automatically configures Claude Desktop and Cursor IDE with:

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

Cursor IDE Setup

  1. Add Your EDA MCP Server:

    • Locate your Claude Desktop config file, Settings > Developer > Edit Config:

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

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

    • Add your EDA server to the existing configuration:

    {
  "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. Restart Claude Desktop and verify both servers are running in Settings > Developer.

Cursor IDE Setup

  1. Open Cursor Settings:

    • Press Ctrl + Shift + P (Windows/Linux) or Cmd + Shift + P (macOS)

    • Search for "Cursor Settings"

    • Navigate to "MCP" in the sidebar

  2. Add MCP Server: Click "Add new MCP server" and configure:

     {
  "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. Enable MCP Tools:

    • Go to Cursor Settings → MCP

    • Enable the "eda-mcp" server

    • You should see the server status change to "Connected"

Usage Examples

1. Verilog Synthesis

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. Verilog Simulation

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. ASIC Design Flow

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

What you get after completion:

  • runs/RUN_*/final/gds/design.gds - Final GDSII layout

  • runs/RUN_*/openlane.log - Complete execution log

  • runs/RUN_*/reports/ - Timing, area, power analysis reports

  • All intermediate results (DEF files, netlists, etc.)

4. Waveform Analysis

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

Troubleshooting

Common Issues

  1. MCP Server Not Detected:

    • Verify the absolute path in configuration

    • Check that Node.js is installed and accessible

    • Restart Claude Desktop/Cursor after configuration changes

  2. Docker Permission Errors:

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

  3. Tool Not Found Errors:

    • Verify tools are installed: yosys --version, iverilog -V, gtkwave --version

    • Check PATH environment variable in MCP configuration

    • On macOS, ensure Homebrew paths are included: /opt/homebrew/bin

  4. OpenLane Timeout:

    • The server has a 10-minute timeout for OpenLane flows

    • For complex designs, consider simplifying or running multiple iterations

  5. GTKWave/KLayout GUI Issues:

    • On macOS: GTKWave/KLayout may need manual approval in Security & Privacy settings

    • On Linux: Ensure X11 forwarding is working if using remote systems

    • On Windows: Ensure GUI applications can launch from command line

Debugging

  1. Check MCP Server Logs:

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

    • Cursor: Check the MCP settings panel for error messages

  2. Test Tools Manually:

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

  3. Verify Node.js Environment:

    node --version
npm --version

Support

For issues and questions:

  • Check the troubleshooting section above

  • Review MCP server logs

  • Test individual tools manually

  • Open an issue with detailed error messages and environment information

Note: This MCP server requires local installation of EDA tools. The server acts as a bridge between AI assistants and your local EDA toolchain, enabling sophisticated hardware design workflows through natural language interaction.

Cite

@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. Dates show when Glama detected each change.

  1. 6 tool updates
    • First observedread_openlane_reports
    • First observedrun_openlane
    • First observedsimulate_verilog
    • First observedsynthesize_verilog
    • First observedview_gds
    • First observedview_waveform
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific EDA tasks: reading reports, running the full design flow, simulation, synthesis, viewing GDSII files, and viewing waveforms. There is no overlap in functionality, making tool selection unambiguous for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., read_openlane_reports, run_openlane, simulate_verilog). The naming is uniform and predictable across all six tools, enhancing usability and clarity.

Tool Count5/5

With 6 tools, the server is well-scoped for EDA workflows, covering key stages from simulation to GDSII viewing. Each tool earns its place without being excessive or insufficient for the domain's typical operations.

Completeness4/5

The toolset covers core EDA operations like simulation, synthesis, and viewing, but lacks explicit update or delete tools for managing design files or results. However, the provided tools support a complete workflow from RTL to analysis, with only minor gaps.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP for Vivado

    lzw12123
    F
    license
    C
    quality
    C
    maintenance
    An AI-centric MCP server that enables automated Xilinx Vivado workflows, including project management, synthesis, implementation, and timing analysis. It allows AI agents to drive hardware design processes while integrating directly with the official Vivado GUI for visual context.
    15
    4
    -

  • wavekit-mcp

    cxzzzz
    F
    license
    Not graded
    quality
    B
    maintenance
    An MCP server that provides AI assistants with a persistent, sandboxed Python environment for waveform analysis, enabling loading and manipulation of VCD/FST/FSDB files and temporal pattern matching.
    9
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NellyW8/MCP4EDA'

If you have feedback or need assistance with the MCP directory API, please join our Discord server