pyslang-mcp

pyslang-mcp is a local Model Context Protocol server that gives AI agents compiler-backed, read-only context for Verilog and SystemVerilog projects.

It wraps pyslang so an MCP client can ask questions against parsed and elaborated HDL instead of plain text:

• What modules, interfaces, and packages are in this filelist?
• What diagnostics does the compiler frontend report?
• What is the instance hierarchy below this top?
• Where is this symbol declared or referenced?
• Did my include paths, defines, and nested .f files resolve as expected?

This is not a simulator, synthesizer, waveform viewer, linter replacement, or RTL refactoring tool. It is a small semantic analysis service for local HDL checkouts.

That read-only boundary is intentional. It keeps the server side-effect free, reduces the blast radius in IP-protected workspaces, and makes it safer to use in local and CI environments.

It was decided to keep pyslang-mcp read-only. The LLM handles the actual RTL coding, while pyslang-mcp serves as the compile/elab-backed reader, checker, and explainer for code that already exists. In other words, the model drafts the RTL and the MCP server verifies what the compiler frontend sees.

[!NOTE] The project is currently early-stage and published on PyPI and the MCP Registry for local stdio use.

Why ASIC And EDA Engineers Might Care

Most AI coding tools are good at searching text. HDL usually needs more than that.

In real projects, useful answers often depend on filelists, packages, includes, defines, generate blocks, and hierarchy. pyslang-mcp gives an agent a compact compiler-backed view of that structure, while keeping the server read-only and scoped to a project root you provide.

Good fits:

• triaging parse and semantic diagnostics before asking an agent to reason about RTL
• checking what a .f file expands to
• listing design units in a block or small IP
• finding a declaration without chasing comments and stale grep hits
• getting hierarchy and port-connection context for review/debug prompts
• giving workflow agents HDL context without handing them an EDA runtime

Quickstart

Install the package:

pip install pyslang-mcp

Run the local stdio server:

pyslang-mcp

For contributor setup, clone the repo and install it in editable mode:

git clone https://github.com/ariklapid/pyslang-mcp.git
cd pyslang-mcp
python -m venv .venv
./.venv/bin/pip install -e '.[dev]'

Run the checkout stdio server:

./.venv/bin/python -m pyslang_mcp

The installed console script works too:

./.venv/bin/pyslang-mcp

Run tests:

./.venv/bin/pytest

MCP Client Config

Use local stdio. The MCP client should launch the server on the same machine, VM, or dev container that can see your RTL checkout.

{
  "mcpServers": {
    "pyslang-mcp": {
      "command": "pyslang-mcp",
      "args": []
    }
  }
}

For editable checkout installs, point the command at the checkout virtual environment instead:

{
  "mcpServers": {
    "pyslang-mcp": {
      "command": "/absolute/path/to/pyslang-mcp/.venv/bin/python",
      "args": ["-m", "pyslang_mcp"]
    }
  }
}

Tool calls must provide a project_root. Source paths, filelists, and include directories may be absolute or relative, but they must stay under that root.

Minimal Tool Payloads

Analyze explicit files:

{
  "project_root": "/path/to/rtl-project",
  "files": ["rtl/pkg.sv", "rtl/top.sv"],
  "include_dirs": ["include"],
  "defines": {
    "WIDTH": "32"
  },
  "top_modules": ["top"]
}

Analyze a filelist:

{
  "project_root": "/path/to/rtl-project",
  "filelist": "compile/project.f"
}

Find a symbol:

{
  "project_root": "/path/to/rtl-project",
  "filelist": "compile/project.f",
  "query": "payload",
  "match_mode": "exact",
  "include_references": true
}

Tools

Typical flow:

1. Start with pyslang_parse_filelist or pyslang_parse_files.
2. Run pyslang_get_diagnostics.
3. Use pyslang_list_design_units to see what the compiler frontend found.
4. Use pyslang_describe_design_unit, pyslang_get_hierarchy, or pyslang_find_symbol for the actual review/debug question.

Verilog/SystemVerilog Analysis And Debugging Flow

1. Use pyslang_summarize_diagnostics_by_code to separate repeated frontend warnings from unresolved dependency errors.
2. Use pyslang_find_member to locate local names such as response__vld.
3. Use pyslang_get_assignments to inspect visible continuous or procedural drivers and loads.
4. Use pyslang_get_instance_connections for one instance's port binding context.
5. Use pyslang_trace_connectivity for bounded structural paths through assignments and instance port bindings.

Connectivity tracing is structural frontend evidence. It is not simulation, formal proof, CDC/RDC signoff, timing signoff, or a complete netlist-level driver/load database.

Filelist Support

The current parser intentionally supports a practical subset used by many RTL flows:

• source file entries
• nested filelists with -f and -F
• include directories with +incdir+..., -I dir, and -Idir
• defines with +define+..., -D NAME, and -DNAME

Unsupported filelist tokens are reported in the tool output instead of being silently ignored.

Example Agent Prompts

Use this server when compiler-backed context matters:

• "Parse compile/project.f with +define+DEBUG and group diagnostics by source file."
• "List every design unit in this project and identify the likely top modules."
• "From top, show the instance hierarchy down to depth 4."
• "Describe module axi_dma_top: ports, child instances, and declared names."
• "Find the declaration and references for payload_valid."
• "Confirm whether legacy_widget is instantiated anywhere the elaborator sees it."
• "Show the resolved files, include dirs, defines, and unsupported entries from this filelist."

For single-line questions, comments, naming searches, or partial/incomplete source sets, regular rg, editor search, or direct file reading is usually faster and clearer.

Guardrails

• Read-only MCP tools. No RTL edits, formatting, simulation, or synthesis.
• Strict project-root scoping. Paths outside project_root are rejected.
• Compact JSON responses with truncation metadata for large result sets.
• Process-local cache keyed by project config and tracked file mtimes.
• pyslang_preprocess_files is summary-oriented. It returns preprocessing metadata and source excerpts, not a guaranteed full standalone preprocessed stream.
• streamable-http remains experimental. The internal MaaS path wraps it with a bearer token for single-server use, but it is not a complete production hosted security boundary by itself.

Remote MaaS Direction

Remote MaaS is planned as two separate tracks, not as one generic hosted mode:

• Plan A: public OSS MaaS. A convenience/demo service for public open-source HDL repositories. This is not suitable for proprietary or confidential RTL.
• Plan B: internal MaaS. A self-hosted deployment pattern for companies to run inside their own network, close to internal repositories, auth, logging, and security controls.

Start with the internal MaaS quickstart for a single internal server. See REMOTE_DEPLOYMENT.md for the full Plan A / Plan B split.

Docker Compose is the recommended bring-up path because it avoids Python setup issues and mounts the RTL checkout read-only. Docker is not required; the quickstart also includes a native Python path for corporate servers where containers are not available.

HDL Example Corpus

The repo includes generated HDL examples under examples/hdl:

• clean reference projects from single modules to small IP-style examples
• intentionally buggy variants labeled easy, medium, and hard
• local validation hooks for both pyslang and verilator --lint-only

Run the full corpus validator:

./.venv/bin/python scripts/validate_hdl_examples.py

Run the CI smoke subset:

./.venv/bin/python scripts/validate_hdl_examples.py --smoke-only

Using With Broader RTL Skills