Claude Desktop 및 Cursor IDE와 같은 AI 어시스턴트를 위한 전자 설계 자동화(EDA) 도구 통합을 제공하는 포괄적인 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 통해 AI는 통합 인터페이스를 통해 Verilog 합성, 시뮬레이션, ASIC 설계 흐름 및 파형 분석을 수행할 수 있습니다.
https://github.com/user-attachments/assets/65d8027e-7366-49b5-8f11-0430c1d1d3d6
Verilog 합성, 시뮬레이션 및 ASIC 설계 흐름을 보여주는 EDA MCP 서버 데모
Related MCP server: Xcelium MCP Server
Verilog 합성: 다양한 FPGA 타겟(generic, ice40, xilinx)에 대해 Yosys를 사용하여 Verilog 코드 합성
Verilog 시뮬레이션: 자동화된 테스트벤치 실행과 함께 Icarus Verilog를 사용하여 설계 시뮬레이션
파형 보기: VCD 파일 시각화 및 신호 분석을 위해 GTKWave 실행
ASIC 설계 흐름: Docker 통합을 사용하여 OpenLane을 통한 완전한 RTL-to-GDSII 흐름
레이아웃 보기: 물리적 설계 검사를 위해 KLayout에서 GDSII 파일 열기
보고서 분석: PPA 지표 및 설계 품질 평가를 위해 OpenLane 보고서 읽기 및 분석
이 MCP 서버를 사용하기 전에 다음 EDA 도구를 설치해야 합니다:
macOS (Homebrew):
brew install yosysUbuntu/Debian:
sudo apt-get update
sudo apt-get install yosys소스에서 빌드:
# 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대안 - OSS CAD Suite (권장): 다음에서 전체 툴체인 다운로드: https://github.com/YosysHQ/oss-cad-suite-build/releases
macOS (Homebrew):
brew install icarus-verilogUbuntu/Debian:
sudo apt-get install iverilogWindows: 다음에서 설치 프로그램 다운로드: https://bleyer.org/icarus/
직접 다운로드 (권장):
Windows: SourceForge에서 다운로드
macOS: SourceForge에서 다운로드하거나 Homebrew 사용: brew install --cask gtkwave
Linux: SourceForge에서 다운로드하거나 패키지 관리자 사용: sudo apt-get install gtkwave
대안 설치 방법:
# 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직접 다운로드:
Windows: Windows용 Docker Desktop 다운로드
macOS: Mac용 Docker Desktop 다운로드 또는 brew install --cask docker
Linux: Linux용 Docker Desktop 다운로드
설치:
공식 웹사이트에서 Docker Desktop을 다운로드하여 설치합니다.
Docker Desktop을 실행하고 정상 작동하는지 확인합니다.
설치 확인: docker run hello-world
참고: Docker Desktop은 Docker Engine, Docker CLI 및 Docker Compose를 하나의 패키지로 포함합니다.
간편 설치 방법 (권장):
# Install OpenLane via pip
pip install openlane
# Pull the Docker image
docker pull efabless/openlane:latest
# Verify installation
docker run hello-world사용 예시:
# 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주요 이점:
--dockerized 플래그는 Docker를 통해 모든 도구 종속성을 자동으로 처리합니다.
직접 다운로드 (권장):
Windows: Windows용 KLayout 다운로드
macOS: macOS용 KLayout 다운로드 또는 brew install --cask klayout
Linux: Linux용 KLayout 다운로드 또는 sudo apt install klayout
대안 설치:
# macOS (Homebrew)
brew install --cask klayout
# Ubuntu/Debian
sudo apt install klayoutgit clone https://github.com/NellyW8/mcp-EDA
cd mcp-EDA
npm install
npm run build
npx tsc mcp-EDA/
├── src/
│ └── index.ts # Main server code
├── build/
│ └── index.js # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.md이 방법은 가장 쉬운 설정을 위해 Docker Desktop의 내장 MCP 확장을 사용합니다.
Docker Desktop 4.39.0 이상 설치 및 실행 중
Claude Desktop 설치됨
Docker Desktop 확장 설치:
Docker Desktop 실행
왼쪽 메뉴에서 "Extensions"로 이동
"AI Tools" 또는 "Docker MCP Toolkit" 검색
"Labs: AI Tools for Devs" 확장 설치
Docker MCP 연결 구성:
설치된 "Labs: AI Tools for Devs" 확장 열기
오른쪽 상단의 톱니바퀴 아이콘 클릭
"MCP Clients" 탭 선택
"Claude Desktop" 또는 "Cursor IDE"에 대해 "Connect" 클릭
이 작업은 Claude Desktop과 Cursor IDE를 자동으로 구성합니다:
{
"mcpServers": {
"MCP_DOCKER": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"alpine/socat",
"STDIO",
"TCP:host.docker.internal:8811"
]
}
}
}EDA MCP 서버 추가:
Claude Desktop 구성 파일 찾기, 설정 > 개발자 > 구성 편집:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
기존 구성에 EDA 서버 추가:
{
"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"
}
}
}
}Claude Desktop 재시작 후 설정 > 개발자에서 두 서버가 실행 중인지 확인합니다.
Cursor 설정 열기:
Ctrl + Shift + P (Windows/Linux) 또는 Cmd + Shift + P (macOS) 누르기
"Cursor Settings" 검색
사이드바에서 "MCP"로 이동
MCP 서버 추가: "Add new MCP server"를 클릭하고 구성합니다:
{
"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"
}
}
}
}MCP 도구 활성화:
Cursor 설정 → MCP로 이동
"eda-mcp" 서버 활성화
서버 상태가 "Connected"로 변경되는 것을 확인해야 합니다.
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
endmoduleAsk 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 oneAsk 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완료 후 얻는 결과물:
runs/RUN_*/final/gds/design.gds - 최종 GDSII 레이아웃
runs/RUN_*/openlane.log - 전체 실행 로그
runs/RUN_*/reports/ - 타이밍, 면적, 전력 분석 보고서
모든 중간 결과물 (DEF 파일, 넷리스트 등)
Ask Claude: "View the waveforms from the simulation with project ID: abc123"MCP 서버가 감지되지 않음:
구성의 절대 경로 확인
Node.js가 설치되어 있고 액세스 가능한지 확인
구성 변경 후 Claude Desktop/Cursor 재시작
Docker 권한 오류:
sudo groupadd docker
sudo usermod -aG docker $USER
sudo reboot도구를 찾을 수 없음 오류:
도구 설치 확인: yosys --version, iverilog -V, gtkwave --version
MCP 구성에서 PATH 환경 변수 확인
macOS의 경우 Homebrew 경로가 포함되어 있는지 확인: /opt/homebrew/bin
OpenLane 시간 초과:
서버는 OpenLane 흐름에 대해 10분 시간 제한이 있습니다.
복잡한 설계의 경우 단순화하거나 여러 번 반복 실행하는 것을 고려하십시오.
GTKWave/KLayout GUI 문제:
macOS: GTKWave/KLayout은 보안 및 개인정보 보호 설정에서 수동 승인이 필요할 수 있습니다.
Linux: 원격 시스템을 사용하는 경우 X11 포워딩이 작동하는지 확인하십시오.
Windows: GUI 애플리케이션이 명령줄에서 실행될 수 있는지 확인하십시오.
MCP 서버 로그 확인:
Claude Desktop: ~/Library/Logs/Claude/mcp*.log (macOS)
Cursor: MCP 설정 패널에서 오류 메시지 확인
도구 수동 테스트:
yosys -help
iverilog -help
docker run hello-world
gtkwave --version
klayout -vNode.js 환경 확인:
node --version
npm --version문제 및 질문:
위의 문제 해결 섹션 확인
MCP 서버 로그 검토
개별 도구 수동 테스트
자세한 오류 메시지 및 환경 정보를 포함하여 이슈 제기
참고: 이 MCP 서버는 EDA 도구의 로컬 설치가 필요합니다. 이 서버는 AI 어시스턴트와 로컬 EDA 툴체인 간의 가교 역할을 하여 자연어 상호 작용을 통해 정교한 하드웨어 설계 워크플로우를 가능하게 합니다.
@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},
}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.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID from OpenLane run | |
| report_type | No | Specific report category to read (synthesis, placement, routing, final, etc.). Leave empty to read all reports. |
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.
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.
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.
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.
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.
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 complete ASIC design flow using OpenLane (RTL to GDSII). This process can take up to 10 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| verilog_code | Yes | The Verilog RTL code for ASIC implementation | |
| design_name | Yes | Name of the design (will be used for module and files) | |
| clock_port | No | Name of the clock port | clk |
| clock_period | No | Clock period in nanoseconds | |
| open_in_klayout | No | Automatically open result in KLayout |
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.
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.
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.
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.
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.
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 Verilog code using Icarus Verilog
| Name | Required | Description | Default |
|---|---|---|---|
| verilog_code | Yes | The Verilog design code | |
| testbench_code | Yes | The testbench code |
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.
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.
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.
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.
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.
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 Verilog code using Yosys for various FPGA targets
| Name | Required | Description | Default |
|---|---|---|---|
| verilog_code | Yes | The Verilog source code to synthesize | |
| top_module | Yes | Name of the top-level module | |
| target | No | Target technology (generic, ice40, xilinx, intel) | generic |
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.
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.
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.
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.
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.
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.
Open GDSII file in KLayout viewer
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID from OpenLane run | |
| gds_file | No | Specific GDS filename (optional, auto-detected if not provided) |
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.
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.
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.
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.
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.
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.
Open VCD waveform file in GTKWave viewer
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID from simulation (required) | |
| vcd_file | No | VCD filename (default: output.vcd) | output.vcd |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0read_openlane_reportsrun_openlanesimulate_verilogsynthesize_verilogview_gdsview_waveformScored across 6 tools
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.
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.
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.
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.
Give your AI agents the tools to build, manage, and run automation workflows.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
