一个全面的模型上下文协议 (MCP) 服务器，为 Claude Desktop 和 Cursor IDE 等 AI 助手提供电子设计自动化 (EDA) 工具集成。该服务器使 AI 能够通过统一接口执行 Verilog 综合、仿真、ASIC 设计流程和波形分析。
https://github.com/user-attachments/assets/65d8027e-7366-49b5-8f11-0430c1d1d3d6
EDA MCP 服务器演示，展示了 Verilog 综合、仿真和 ASIC 设计流程
Related MCP server: Xcelium MCP Server
Verilog 综合：使用 Yosys 为各种 FPGA 目标（通用、ice40、xilinx）综合 Verilog 代码
Verilog 仿真：使用 Icarus Verilog 进行仿真，并自动执行测试平台 (testbench)
波形查看：启动 GTKWave 进行 VCD 文件可视化和信号分析
ASIC 设计流程：使用 OpenLane 和 Docker 集成实现完整的 RTL 到 GDSII 流程
布局查看：在 KLayout 中打开 GDSII 文件以进行物理设计检查
报告分析：读取并分析 OpenLane 报告，以获取 PPA 指标和设计质量评估
在使用此 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 配置文件，Settings > Developer > Edit Config:
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 并在 Settings > Developer 中验证两个服务器是否都在运行。
打开 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 Settings → 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 -v验证 Node.js 环境:
node --version
npm --version如有问题和疑问：
查看上面的故障排除部分
查看 MCP 服务器日志
手动测试各个工具
提交包含详细错误消息和环境信息的 issue
注意: 此 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.
