Implementierung des Papers: MCP4EDA: LLM-Powered Model Context Protocol RTL-to-GDSII Automation with Backend Aware Synthesis Optimization
Ein umfassender Model Context Protocol (MCP)-Server, der die Integration von Electronic Design Automation (EDA)-Tools für KI-Assistenten wie Claude Desktop und Cursor IDE bereitstellt. Dieser Server ermöglicht es der KI, Verilog-Synthese, Simulation, ASIC-Design-Flows und Wellenformanalysen über eine einheitliche Schnittstelle durchzuführen.
https://github.com/user-attachments/assets/65d8027e-7366-49b5-8f11-0430c1d1d3d6
EDA MCP Server-Demonstration mit Verilog-Synthese, Simulation und ASIC-Design-Flow
Related MCP server: Xcelium MCP Server
Verilog-Synthese: Synthetisieren von Verilog-Code mit Yosys für verschiedene FPGA-Ziele (generic, ice40, xilinx)
Verilog-Simulation: Simulation von Designs mit Icarus Verilog mit automatisierter Testbench-Ausführung
Wellenform-Anzeige: Starten von GTKWave zur VCD-Dateivisualisierung und Signalanalyse
ASIC-Design-Flow: Vollständiger RTL-to-GDSII-Flow mit OpenLane unter Verwendung von Docker-Integration
Layout-Anzeige: Öffnen von GDSII-Dateien in KLayout zur physischen Design-Inspektion
Berichtsanalyse: Lesen und Analysieren von OpenLane-Berichten für PPA-Metriken und Qualitätsbewertung des Designs
Bevor Sie diesen MCP-Server verwenden, müssen Sie die folgenden EDA-Tools installieren:
macOS (Homebrew):
brew install yosysUbuntu/Debian:
sudo apt-get update
sudo apt-get install yosysAus dem Quellcode:
# 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 installAlternative - OSS CAD Suite (Empfohlen): Laden Sie die vollständige Toolchain herunter von: https://github.com/YosysHQ/oss-cad-suite-build/releases
macOS (Homebrew):
brew install icarus-verilogUbuntu/Debian:
sudo apt-get install iverilogWindows: Laden Sie den Installer herunter von: https://bleyer.org/icarus/
Direkte Downloads (Empfohlen):
Windows: Download von SourceForge
macOS: Download von SourceForge oder verwenden Sie Homebrew: brew install --cask gtkwave
Linux: Download von SourceForge oder verwenden Sie den Paketmanager: sudo apt-get install gtkwave
Alternative Installationsmethoden:
# 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 installDirekte Downloads:
macOS: Docker Desktop für Mac herunterladen oder brew install --cask docker
Installation:
Laden Sie Docker Desktop von der offiziellen Website herunter und installieren Sie es
Starten Sie Docker Desktop und stellen Sie sicher, dass es läuft
Überprüfen Sie die Installation: docker run hello-world
Hinweis: Docker Desktop enthält Docker Engine, Docker CLI und Docker Compose in einem Paket.
Einfache Installationsmethode (Empfohlen):
# Install OpenLane via pip
pip install openlane
# Pull the Docker image
docker pull efabless/openlane:latest
# Verify installation
docker run hello-worldAnwendungsbeispiel:
# 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.jsonHauptvorteile:
Das --dockerized-Flag handhabt alle Tool-Abhängigkeiten automatisch über Docker
Direkte Downloads (Empfohlen):
Windows: KLayout für Windows herunterladen
macOS: KLayout für macOS herunterladen oder brew install --cask klayout
Linux: KLayout für Linux herunterladen oder sudo apt install klayout
Alternative Installation:
# 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.mdDiese Methode verwendet die integrierte MCP-Erweiterung von Docker Desktop für die einfachste Einrichtung.
Docker Desktop 4.39.0+ installiert und laufend
Claude Desktop installiert
Docker Desktop-Erweiterung installieren:
Starten Sie Docker Desktop
Gehen Sie im linken Menü auf "Extensions"
Suchen Sie nach "AI Tools" oder "Docker MCP Toolkit"
Installieren Sie die Erweiterung "Labs: AI Tools for Devs"
Docker MCP-Verbindung konfigurieren:
Öffnen Sie die installierte Erweiterung "Labs: AI Tools for Devs"
Klicken Sie auf das Zahnradsymbol in der oberen rechten Ecke
Wählen Sie den Tab "MCP Clients"
Klicken Sie auf "Connect" für "Claude Desktop" oder "Cursor IDE"
Dies konfiguriert Claude Desktop und Cursor IDE automatisch mit:
{
"mcpServers": {
"MCP_DOCKER": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"alpine/socat",
"STDIO",
"TCP:host.docker.internal:8811"
]
}
}
}Fügen Sie Ihren EDA MCP-Server hinzu:
Suchen Sie Ihre Claude Desktop-Konfigurationsdatei, Einstellungen > Entwickler > Konfiguration bearbeiten:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Fügen Sie Ihren EDA-Server zur bestehenden Konfiguration hinzu:
{
"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"
}
}
}
}Starten Sie Claude Desktop neu und überprüfen Sie in Einstellungen > Entwickler, ob beide Server laufen.
Cursor-Einstellungen öffnen:
Drücken Sie Strg + Umschalt + P (Windows/Linux) oder Cmd + Umschalt + P (macOS)
Suchen Sie nach "Cursor Settings"
Navigieren Sie in der Seitenleiste zu "MCP"
MCP-Server hinzufügen: Klicken Sie auf "Add new MCP server" und konfigurieren Sie:
{
"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-Tools aktivieren:
Gehen Sie zu Cursor-Einstellungen → MCP
Aktivieren Sie den "eda-mcp"-Server
Der Serverstatus sollte sich auf "Connected" ändern
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
endmoduleWas Sie nach Abschluss erhalten:
runs/RUN_*/final/gds/design.gds - Finales GDSII-Layout
runs/RUN_*/openlane.log - Vollständiges Ausführungsprotokoll
runs/RUN_*/reports/ - Berichte zur Timing-, Flächen- und Leistungsanalyse
Alle Zwischenergebnisse (DEF-Dateien, Netzlisten, etc.)
Ask Claude: "View the waveforms from the simulation with project ID: abc123"MCP-Server nicht erkannt:
Überprüfen Sie den absoluten Pfad in der Konfiguration
Stellen Sie sicher, dass Node.js installiert und zugänglich ist
Starten Sie Claude Desktop/Cursor nach Konfigurationsänderungen neu
Docker-Berechtigungsfehler:
sudo groupadd docker
sudo usermod -aG docker $USER
sudo rebootFehler "Tool nicht gefunden":
Überprüfen Sie, ob die Tools installiert sind: yosys --version, iverilog -V, gtkwave --version
Überprüfen Sie die PATH-Umgebungsvariable in der MCP-Konfiguration
Stellen Sie unter macOS sicher, dass Homebrew-Pfade enthalten sind: /opt/homebrew/bin
OpenLane-Zeitüberschreitung:
Der Server hat eine 10-minütige Zeitüberschreitung für OpenLane-Flows
Erwägen Sie bei komplexen Designs eine Vereinfachung oder die Durchführung mehrerer Iterationen
GTKWave/KLayout GUI-Probleme:
Unter macOS: GTKWave/KLayout erfordern möglicherweise eine manuelle Genehmigung in den Sicherheits- & Datenschutzeinstellungen
Unter Linux: Stellen Sie sicher, dass X11-Weiterleitung funktioniert, wenn Sie Remote-Systeme verwenden
Unter Windows: Stellen Sie sicher, dass GUI-Anwendungen über die Befehlszeile gestartet werden können
MCP-Server-Protokolle prüfen:
Claude Desktop: ~/Library/Logs/Claude/mcp*.log (macOS)
Cursor: Überprüfen Sie das MCP-Einstellungsfenster auf Fehlermeldungen
Tools manuell testen:
yosys -help
iverilog -help
docker run hello-world
gtkwave --version
klayout -vNode.js-Umgebung überprüfen:
node --version
npm --versionBei Problemen und Fragen:
Überprüfen Sie den Abschnitt zur Fehlerbehebung oben
Überprüfen Sie die MCP-Server-Protokolle
Testen Sie einzelne Tools manuell
Eröffnen Sie ein Issue mit detaillierten Fehlermeldungen und Umgebungsinformationen
Hinweis: Dieser MCP-Server erfordert die lokale Installation von EDA-Tools. Der Server fungiert als Brücke zwischen KI-Assistenten und Ihrer lokalen EDA-Toolchain und ermöglicht anspruchsvolle Hardware-Design-Workflows durch Interaktion in natürlicher Sprache.
@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.
