Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-rtl-review Review my Verilog module for reset polarity and width mismatches"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for AST-backed static RTL code review, semantic bug detection, and code review scoring.
mcp-rtl-review equips AI coding agents and IDEs (Cursor, Windsurf, GitHub Copilot / OpenAI Codex, Claude Code, Google Antigravity, OpenCode, Cline) with structured tools to perform semantic Verilog/SystemVerilog code reviews. It programmatically enforces the cognitive rubrics established in hw-agent-skills/skills/rtl-reviewer, parsing full typed ASTs to catch race conditions, improper assignment styles, inverted reset polarities, and bitwidth truncations.
mcp-rtl-reviewWithout | With |
| Analyzes full typed AST for deep semantic hardware bugs |
Misses blocking assignments ( | Flags |
Silent active-low reset polarity bugs survive to simulation | Detects |
Implicit bitwidth truncation requires reading manual compiler logs | Immediate |
Agent has no feedback on overall design quality | Computes a deterministic 0–100 RTL Quality Score |
Requires local installation of Verilator, Python, and C++ compilers | Zero host configuration (runs via isolated rootless Podman) |
// Tool Call: rtl_toolchain_info
{
"runtime": "podman",
"image": "localhost/zesun33/verilog",
"verilatorVersion": "Verilator 5.020 2024-01-01 rev (Debian 5.020-1)",
"rulesSupported": [
"SEQ_BLOCKING_ASSIGN",
"COMB_NONBLOCKING_ASSIGN",
"RESET_POLARITY_MISMATCH",
"WIDTH_MISMATCH",
"UNDRIVEN_NET",
"COMBINATIONAL_LOOP",
"UNUSED_SIGNAL"
]
}// Tool Call: rtl_review {"verilog_sources": ["clean_counter.v"], "top_module": "clean_counter"}
{
"passed": true,
"score": 100,
"totalViolations": 0,
"errors": 0,
"warnings": 0,
"info": 0,
"violations": [],
"metrics": {
"modulesAnalyzed": 1,
"alwaysBlocksAnalyzed": 1,
"sequentialBlocks": 1,
"combinationalBlocks": 0,
"linesAnalyzed": 16
},
"rulesChecked": ["SEQ_BLOCKING_ASSIGN", "COMB_NONBLOCKING_ASSIGN", "RESET_POLARITY_MISMATCH", "WIDTH_MISMATCH", "UNDRIVEN_NET", "COMBINATIONAL_LOOP", "UNUSED_SIGNAL"]
}// Tool Call: rtl_check_assignments {"verilog_sources": ["blocking_in_seq.v"], "top_module": "blocking_in_seq"}
{
"passed": false,
"totalViolations": 2,
"blockingInSeq": [
{
"file": "fixtures/blocking_in_seq.v",
"line": 11,
"variable": "count",
"message": "Blocking assignment '=' to 'count' inside sequential (clocked) block. This causes simulation race conditions.",
"fixSuggestion": "Replace '=' with non-blocking assignment '<=' to 'count'."
},
{
"file": "fixtures/blocking_in_seq.v",
"line": 13,
"variable": "count",
"message": "Blocking assignment '=' to 'count' inside sequential (clocked) block. This causes simulation race conditions.",
"fixSuggestion": "Replace '=' with non-blocking assignment '<=' to 'count'."
}
],
"nonBlockingInComb": []
}// Tool Call: rtl_review {"verilog_sources": ["reset_mismatch.v"], "top_module": "reset_mismatch"}
{
"passed": false,
"score": 85,
"errors": 1,
"warnings": 0,
"violations": [
{
"ruleId": "RESET_POLARITY_MISMATCH",
"severity": "error",
"file": "fixtures/reset_mismatch.v",
"line": 10,
"message": "Reset polarity inversion: sensitivity list declares active-low reset 'rst_n', but if condition checks active-high 'rst_n'.",
"fixSuggestion": "Change condition to 'if (!rst_n)' to match sensitivity list polarity."
}
]
}// Tool Call: rtl_check_widths {"verilog_sources": ["width_mismatch.v"], "top_module": "width_mismatch"}
{
"passed": false,
"totalMismatches": 1,
"widthMismatches": [
{
"file": "fixtures/width_mismatch.v",
"line": 9,
"expectedWidth": 4,
"actualWidth": 8,
"message": "Operator ASSIGN expects 4 bits on the Assign RHS, but Assign RHS's VARREF 'in_b' generates 8 bits.",
"fixSuggestion": "Verify signal widths and explicitly slice or sign-extend operands to avoid unintended truncation."
}
]
}Related MCP server: mcp-zen-of-languages
Tool | Parameters | Engine | Description |
|
| Verilator XML AST + Diagnostics | Full AST-backed static RTL review evaluating assignment discipline, reset polarity, bitwidths, and undriven nets, returning a 0–100 Quality Score. |
|
| AST Assignment Visitor | Audits source files specifically for assignment discipline violations ( |
|
| Verilator Semantic Lint | Performs bitwidth analysis to identify implicit truncation and unintended extension bugs. |
|
| Probe | Returns container/host runtime and version information for the Verilator AST parser and supported rule catalog. |
To register mcp-rtl-review with your AI IDE or agent, add it to your configuration file (e.g., .cursor/mcp.json, claude_desktop_config.json, or Windsurf settings):
{
"mcpServers": {
"rtl-review": {
"command": "node",
"args": ["/path/to/mcp-rtl-review/dist/index.js"],
"env": {
"MCP_RTL_REVIEW_RUNTIME": "podman",
"MCP_RTL_REVIEW_IMAGE": "localhost/zesun33/verilog"
}
}
}
}Works seamlessly across all modern AI coding environments:
Cursor: Configure in .cursor/mcp.json.
Windsurf: Configure in ~/.codeium/windsurf/mcp_config.json.
GitHub Copilot / OpenAI Codex: Configure via Copilot MCP settings or Codex tool proxy.
Claude Code: Configure via claude mcp add rtl-review node /path/to/dist/index.js.
Google Antigravity: Load as workspace MCP server in antigravity.json.
OpenCode & Cline: Direct stdio JSON-RPC connection.
Strict 6-gate verification suite matching the portfolio engineering standard:
# Full verification (all 6 gates)
./scripts/verify.sh
# Target specific gates
./scripts/verify.sh --gate 1 # Spec lock & package integrity
./scripts/verify.sh --gate 2 # Static build (TypeScript)
./scripts/verify.sh --gate 3 # Unit tests (AST parser & rule engine)
./scripts/verify.sh --gate 4 # Live Podman container integration tests
./scripts/verify.sh --gate 5 # Stdio JSON-RPC contract check
./scripts/verify.sh --gate 6 # Documentation validationApache-2.0 © 2026 Md Zesun Ahmed Mia
Audits Verilog/SystemVerilog source files specifically for assignment discipline violations: blocking '=' in sequential clocked blocks, or non-blocking '<=' in combinational blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Optional working directory where source files reside. | |
| top_module | No | Top module name for AST hierarchy analysis. | |
| verilog_sources | Yes | List of Verilog/SystemVerilog source files to audit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral disclosure. It implies a read-only audit by using 'Audits' and specifies the exact violation categories, but it does not state whether files are modified, what side effects occur, or how violations are reported.
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 sentence that front-loads the action and resource, then immediately specifies the exact checks performed. Every word is necessary, with no fluff or redundancy.
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?
The tool has no output schema, so the description should ideally clarify what an audit result looks like. It explains what is audited but not how violations are returned (e.g., exit code, report, or structured list). It is adequate for a simple static-analysis tool but leaves a notable gap.
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% coverage of all parameters, so the description adds no additional parameter meaning. The baseline of 3 is appropriate because the schema already documents the three parameters adequately.
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 states a specific verb ('Audits') and a specific resource ('Verilog/SystemVerilog source files'), and further narrows the scope to 'assignment discipline violations.' It clearly explains what the tool does, though it does not explicitly distinguish itself from sibling tools like rtl_check_widths.
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 phrase 'specifically for assignment discipline violations' gives clear context for when to use this tool over more general or width-focused checks. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs semantic bitwidth analysis on Verilog/SystemVerilog designs, detecting implicit truncation and bit expansion mismatches.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Optional working directory where source files reside. | |
| top_module | No | Top module name for hierarchy analysis. | |
| verilog_sources | Yes | List of Verilog/SystemVerilog source files to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden. It does disclose the core behavior (analyzing bitwidths and detecting mismatch types), which is useful. However, it does not state whether the tool is read-only, what kind of report it produces, whether it requires compilation/elaboration, or how it handles multiple files and hierarchy.
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 the primary action ('Performs semantic bitwidth analysis') and then specifies the concrete behavior. Every word contributes; there is no fluff or repetition of the tool name.
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?
With no output schema and no annotations, the description needs to explain what the agent can expect from invoking this tool. It does not mention return values, formatting of diagnostics, exit behavior, or prerequisites such as a working toolchain or required top-module specification. The one-line description is not sufficient for a tool with hierarchical analysis dependencies.
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 input schema fully documents all three parameters (cwd, top_module, verilog_sources). The description adds no parameter-level meaning beyond that, but the baseline of 3 is appropriate because the schema already carries the load.
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 uses a specific verb ('Performs semantic bitwidth analysis') and names a concrete resource (Verilog/SystemVerilog designs) and defines the exact detection scope (implicit truncation and bit expansion mismatches). This clearly distinguishes it from sibling tools like rtl_check_assignments or rtl_review, which target different analysis concerns.
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 gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or conditions that would route an agent to a sibling tool, leaving the selection entirely to inference from the name and one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs full AST-backed static RTL review and semantic code audit on Verilog/SystemVerilog designs, evaluating assignment discipline, reset polarity, bitwidths, undriven nets, and computing a 0–100 quality score with actionable fix suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Optional working directory where source files reside. | |
| ruleset | No | Rule severity enforcement level (default: standard). | |
| top_module | No | Top module name for AST hierarchy analysis. | |
| include_info | No | Whether to include info-level violations (e.g. unused signals). | |
| verilog_sources | Yes | List of Verilog/SystemVerilog source files to review. |
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 does describe the analysis approach (AST-backed, static, semantic audit) and the deliverable (0–100 score with fix suggestions), which is useful. However, it does not mention potential limitations, behavior on parse errors, or confirm the tool is read-only/non-destructive, which an agent typically benefits from knowing.
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 sentence that front-loads the tool's main purpose and enumerates the key evaluation areas and output. It is dense but not bloated; every major element earns its place, though the long list of checks makes it slightly heavy to parse at a glance.
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 moderately complex tool with five parameters and no output schema, the description covers the core functionality and the general nature of the output. It lacks details on how ruleset severity levels affect the review, interpretation of the quality score, or any prerequisites for source files, leaving some operational context unexplored.
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 input schema already documents all five parameters with descriptions. The tool description adds no parameter-specific meaning beyond what the schema provides, which meets the baseline for full schema coverage but does not elevate it.
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 performs a comprehensive AST-backed static RTL review and semantic audit on Verilog/SystemVerilog designs, listing specific checks (assignment discipline, reset polarity, bitwidths, undriven nets) and an output quality score. This distinguishes it from the narrower sibling tools rtl_check_assignments and rtl_check_widths, which focus on individual aspects.
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 this is the full, consolidated review tool, but it does not explicitly state when to prefer it over the sibling tools or when a targeted check would be more appropriate. There is no direct comparison or exclusion guidance, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns active container/host runtime and version information for the Verilator AST parser and supported rule list.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Optional workspace directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must convey the behavioral profile. 'Returns... information' strongly implies a read-only operation, but it does not disclose side effects, return format, or how the optional cwd affects the result.
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 sentence with the key verb front-loaded and no filler. It loses a point because it densely bundles multiple concepts—container/host runtime, version info, parser, and rule list—into one clause, reducing immediate readability.
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 simple read-only info tool with full schema coverage on its one optional parameter, the description gives the basic scope. However, the absence of an output schema and any detail about return shape or cwd behavior leaves moderate gaps for an agent deciding whether and how to invoke it.
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 documents the single optional cwd parameter with 100% coverage, so the schema carries the parameter documentation burden. The description adds no additional semantics about how cwd influences the toolchain info, keeping this at the baseline.
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 identifies a clear verb and resource: it returns container/host runtime, version information, and the supported rule list. It is also distinguishable from the review/check siblings by its informational nature, though the phrase 'active container/host runtime' is somewhat ambiguous.
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 tool's purpose implies it should be used when an agent needs toolchain/version/rule-list information rather than performing an RTL review or check. However, it does not explicitly state when to use it vs. siblings or when not to use it.
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. Dates show when Glama detected each change.
v0.1.0rtl_check_assignmentsrtl_check_widthsrtl_reviewrtl_toolchain_infoThe full review tool overlaps with the two targeted check tools, but each has a clearly scoped purpose: comprehensive audit versus specific assignment or width checks. The toolchain info tool is entirely distinct. Some ambiguity exists about when to run the full review versus individual checks, but descriptions mitigate it well.
All tools share the rtl_ prefix, but the naming pattern is mixed: two use verb_noun (rtl_check_assignments, rtl_check_widths), while rtl_review is verb-only and rtl_toolchain_info is noun_noun. The inconsistency is noticeable but still readable and predictable given the shared prefix.
Four tools is well-scoped for a focused RTL review server: one comprehensive review, two targeted checks, and one metadata query. Each tool has a clear purpose and the count feels neither thin nor bloated.
The full review tool provides broad static-analysis coverage including assignments, reset polarity, widths, and undriven nets, while the targeted check tools allow narrower queries. The toolchain info tool supplies environment and rule-compatibility context. No obvious missing operations are apparent for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zesun33/mcp-rtl-review'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
