Which integrations are available for this server?

Allows for HDL synthesis targeting AMD and Xilinx FPGA architectures to provide resource utilization and statistics. Integrates with the GitHub API to search for and import open-source FPGA IP cores and hardware modules directly into the server's registry. Allows for HDL synthesis targeting Intel and Altera FPGA architectures to provide resource utilization and statistics. Enables the discovery and integration of RISC-V processor cores and related hardware modules from the IP core registry. Uses SPDX license identifiers to filter and validate the licensing of hardware IP cores imported from external repositories.

How do I use fpgaZeroMCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fpgaZeroMCP search for an I2C controller core on GitHub and import it into my project" 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.

de en es ja ko ru zh

fpgaZeroMCP

by bard0-design

Overview Schema Source Related Servers Discussions Admin

Local

fpgaZeroMCP

License: MIT Python MCP

An open-source Model Context Protocol server that gives AI assistants a complete FPGA toolchain — lint, simulate, synthesize, place-and-route, program the bitstream, and a live IP core registry backed by GitHub.

Ask your AI to search for cores, pull them in, lint HDL, synthesize a multi-file VHDL or Verilog project from disk, run a simulation, then flash the bitstream to your board — all without leaving your chat window.

Features

Multi-language: Verilog, SystemVerilog, and VHDL (via ghdl-yosys-plugin)
Three input modes: inline code string, multi-file files dict, or project_dir path on disk
Filelist support: files.f/sources.f with +incdir+, +define+, and nested -f directives
Board presets: 11 built-in boards (iCEBreaker, ULX3S, TinyFPGA BX, Tang Nano, etc.) — sets target/device/package/clock automatically
Constraint auto-detection: finds .pcf/.lpf/.pdc/.cst in your project directory
Bitstream programming: flash via iceprog (iCE40) or openFPGALoader (ECP5/Gowin/Nexus)
Simulation verdict parsing: PASS/FAIL/UVM pattern detection with VCD signal summary
Background builds: long-running synthesis/PnR with status polling and a strict EDA-only command allowlist
IP core registry: live search and import from GitHub with FuseSoC CAPI2 metadata
Health check: discover which OSS CAD Suite tools are installed and reachable

Related MCP server: fpgaZeroMCP

How it works

Your AI assistant  <-->  fpgaZeroMCP (stdio MCP server)  <-->  OSS tools
                                    |
                           cores/   registry on GitHub
                           (uart_tx, fifo + any imported)

The MCP server runs as a local subprocess. Your AI calls tools on it over JSON-RPC (stdio). The server shells out to Yosys, nextpnr, iverilog, Verilator, and others from OSS CAD Suite — and can pull open-source FPGA cores directly from GitHub.

Prerequisites

Requirement	Notes
Python 3.11+
OSS CAD Suite	Bundles iverilog, Yosys, nextpnr, Verilator, Verible, GHDL in one download
LiteX + litex-boards	Optional — only needed for LiteX tools

Add OSS CAD Suite to your PATH after installing. All tool wrappers degrade gracefully if a tool is missing.

GitHub API access

GitHub API requests are unauthenticated by default and subject to rate limits. Set a personal access token to increase limits:

# Linux/macOS
export GITHUB_TOKEN=ghp_...

# Windows (PowerShell)
$env:GITHUB_TOKEN = "ghp_..."

Installation

git clone https://github.com/lcapossio/fpgaZeroMCP
cd fpgaZeroMCP
pip install -e .

MCP Client Setup

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "fpgaZeroMCP": {
      "command": "python",
      "args": ["/path/to/fpgaZeroMCP/server.py"],
      "env": { "PYTHONPATH": "/path/to/fpgaZeroMCP" }
    }
  }
}

VS Code (GitHub Copilot)

Add to .vscode/mcp.json in your workspace:

{
  "servers": {
    "fpgaZeroMCP": {
      "type": "stdio",
      "command": "python",
      "args": ["/path/to/fpgaZeroMCP/server.py"],
      "env": { "PYTHONPATH": "/path/to/fpgaZeroMCP" }
    }
  }
}

Cursor / Windsurf

Add to your MCP settings (Settings → MCP Servers):

{
  "fpgaZeroMCP": {
    "command": "python",
    "args": ["/path/to/fpgaZeroMCP/server.py"],
    "env": { "PYTHONPATH": "/path/to/fpgaZeroMCP" }
  }
}

Example prompts

"Find me an I2C master core and import it."
"Synthesize the VHDL files in ~/projects/my_fpga and tell me the LUT count."
"PnR my project for the iCEBreaker board, then flash it."
"Run place-and-route with seed 42 to try for better timing."
"Lint this Verilog and fix any errors."
"Simulate this FIFO and tell me whether the testbench passed."
"Format this SystemVerilog file."
"Which OSS CAD Suite tools do I have installed?"

Tools

HDL quality

Tool	Description
`lint_hdl`	Syntax/error check via iverilog (V/SV) or GHDL (VHDL) — single file
`lint_project`	Lint multiple files together so cross-module references resolve
`get_diagnostics`	Structured per-line diagnostics — Verilator → verible fallback (V/SV), GHDL (VHDL)
`format_hdl`	Auto-format via verible-verilog-format (V/SV) or vsg (VHDL)

Design flow

Tool	Description
`simulate`	Compile and run testbenches — iverilog (V/SV) or GHDL (VHDL). Returns verdict + VCD summary
`synthesize`	Yosys synthesis with resource stats. Accepts `code`, `files`, or `project_dir`. Verilog, SV, VHDL
`place_and_route`	Yosys + nextpnr in one step. Board presets, constraint auto-detection, bitstream output
`program_fpga`	Flash a bitstream via `iceprog` or `openFPGALoader`
`list_boards`	Enumerate built-in board presets (target/device/package/clock)

IP core registry

Tool	Description
`list_ip_cores`	Browse the local registry, filter by category
`get_ip_core`	Fetch manifest and HDL source for a core
`generate_ip`	Get a parameterized instantiation snippet + source files
`search_github_cores`	Search GitHub for MIT-licensed FPGA IP repos
`import_github_core`	Download a GitHub repo into the local registry
`import_fusesoc_core`	Import a local FuseSoC CAPI2 `.core` file

LiteX

Tool	Description
`litex_build`	Run a LiteX board target with `--build`
`litex_soc`	Generate a LiteX SoC without building gateware
`litex_flow`	Run a LiteX board target with fully custom args

Build management

Tool	Description
`start_build`	Start a long-running command in the background (allowlisted EDA tools only)
`build_status`	Check progress — status, elapsed time, parsed phase/utilization/timing
`list_builds`	List all tracked builds (running and finished)
`cancel_build`	Kill a running background build
`cleanup_build_logs`	Delete old build logs by age and total size

Server / registry

Tool	Description
`check_tools`	Report which OSS CAD Suite tools are installed, with paths and versions
`reload_registry`	Re-scan core directories without restarting the server

IP Core Registry

Cores live in cores/<name>/ — a core.json manifest and one or more HDL files. The server auto-discovers them on startup and reloads after any import.

Two reference cores are included (uart_tx, fifo) to demonstrate the format. The registry is not meant to grow here — it is powered by GitHub.

Getting cores at runtime

# Find a RISC-V softcore
search_github_cores("riscv softcore", language="verilog")

# Pull it in
import_github_core("YosysHQ/picorv32")

# It is now in the local registry
get_ip_core("picorv32")
generate_ip("picorv32", {"COMPRESSED_ISA": 1})

The server automatically uses FuseSoC CAPI2 metadata (.core files) when found in the repo, giving richer parameter and port information. Only repos with an allowed license are accepted.

Contributing a core

Do not open PRs adding cores to this repo. Instead:

Publish your HDL repo on GitHub with the fpga topic and an MIT license
Optionally add a FuseSoC CAPI2 .core file for richer metadata
Anyone can then import_github_core("you/your-core") directly

This keeps the server lean and lets the community grow organically on GitHub.

Synthesis Targets

Target	Vendor / Family	Full OSS P&R
`ice40`	Lattice iCE40	yes — nextpnr-ice40
`ecp5`	Lattice ECP5	yes — nextpnr-ecp5
`nexus`	Lattice Nexus (CrossLink-NX, CertusPro-NX)	yes — nextpnr-nexus
`gowin`	Gowin	yes — nextpnr-gowin
`xilinx`	Xilinx / AMD	Synth only
`intel`	Intel / Altera	Synth only
`generic`	Technology-independent	Netlist only

Common device/package values for place_and_route:

Target	device	package
ice40	`hx1k` `hx8k` `up5k` `lp1k`	`tq144` `qn84` `sg48` `cm81`
ecp5	`25k` `45k` `85k`	`CABGA256` `CABGA381`
nexus	`LIFCL-40-9BG400C`	(embedded in device string)
gowin	`GW1N-UV4LQ144C6/I5`	(embedded in device string)

LiteX

LiteX is a Python SoC framework that can target many FPGA boards. fpgaZeroMCP exposes three dedicated LiteX tools and also accepts backend="litex" in synthesize and place_and_route.

# Dedicated tools
litex_build(board="arty", args=["--build"])
litex_soc(board="arty", args=["--no-compile"])
litex_flow(board="arty", args=["--build", "--output-dir", "build_arty"])

# As a backend in existing flow tools
synthesize(code="...", top_module="top", backend="litex", litex_board="arty")
place_and_route(code="...", top_module="top", target="ice40", device="hx1k",
                backend="litex", litex_board="arty", litex_args=["--build"])

Local Core Repositories

You can point the registry at your own local HDL directories in two ways:

Environment variable:

Linux/macOS (colon-separated):

export USERCORES_PATH=/home/you/my-cores:/home/you/work-cores

Windows (semicolon-separated, PowerShell):

$env:USERCORES_PATH = "C:\Users\you\my-cores;C:\Users\you\work-cores"

Config file (~/.fpgazero_mcp/config.json):

{
  "core_paths": [
    "/home/you/my-cores",
    "/home/you/work-cores"
  ]
}

All paths are scanned on startup alongside the built-in cores/ directory.

Allowed licenses

By default, import_github_core accepts repos with any of these SPDX licenses:

MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC, GPL-2.0, GPL-3.0, LGPL-2.1, LGPL-3.0

Override with the FPGAZERO_ALLOWED_LICENSES environment variable (comma-separated SPDX IDs):

# Linux/macOS
export FPGAZERO_ALLOWED_LICENSES=MIT
export FPGAZERO_ALLOWED_LICENSES=MIT,Apache-2.0

# Windows (PowerShell)
$env:FPGAZERO_ALLOWED_LICENSES = "MIT"
$env:FPGAZERO_ALLOWED_LICENSES = "MIT,Apache-2.0"

License IDs follow SPDX notation. The check is done at import time; search_github_cores returns results regardless of license so you can evaluate before importing.

Testing

pip install -e ".[dev]"
python -m pytest tests/ -v

Some tests require OSS CAD Suite tools on PATH. Tests that need missing tools are skipped automatically.

Environment Variables

Variable	Description
`GITHUB_TOKEN`	GitHub personal access token — raises API rate limits
`USERCORES_PATH`	Extra core search directories (OS path separator delimited)
`FPGAZERO_ALLOWED_LICENSES`	Comma-separated SPDX IDs for `import_github_core` (default: `MIT,BSD-2-Clause,BSD-3-Clause,Apache-2.0,ISC,GPL-2.0,GPL-3.0,LGPL-2.1,LGPL-3.0`)
`FPGAZERO_TMPDIR`	Override temporary workspace root directory
`FPGAZERO_ALLOWED_DIRS`	OS pathsep-separated list of extra directories that `project_dir` may read from (in addition to cwd and `$HOME`)

Standalone / Scripting

The Python API can be used directly without an MCP client:

from registry.resolver import CoreRegistry
from tools.lint import lint_hdl

reg = CoreRegistry()

# Import a core from GitHub
reg.import_github_core("ben-marshall/uart")

# Generate a parameterized instantiation
result = reg.generate_ip("uart", {"CLKS_PER_BIT": 868})
print(result["instantiation"])

# Lint some HDL
lint_hdl(open("my_design.v").read())

python example.py   # runs the built-in demo

core.json Schema

{
  "name": "my_core",
  "version": "1.0.0",
  "description": "...",
  "author": "you",
  "license": "MIT",
  "language": "verilog",
  "category": "communication",
  "tags": ["spi", "serial"],
  "parameters": {
    "DATA_WIDTH": { "type": "integer", "default": 8, "description": "..." }
  },
  "ports": {
    "clk": { "direction": "input", "width": 1, "description": "System clock" }
  },
  "files": ["my_core.v"]
}

Author

Leonardo Capossio (bard0) — hello@bard0.com

License

MIT — see LICENSE.

Available Tools

15 tools

format_hdlA

Format HDL source code and return the result. Verilog/SystemVerilog: uses verible-verilog-format. VHDL: uses vsg (pip install vsg). Returns the formatted code and whether it changed.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	HDL source code to format
`language`	No	HDL language variant	verilog

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns formatted code and a change indicator, and names the underlying formatters. However, since no annotations are provided, the description bears full burden; it does not explicitly state whether the tool modifies files or is read-only, nor does it cover potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: three sentences front-load the main action and provide key details without redundancy. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters having full schema coverage and no output schema, the description explains the return value and underlying tools. It could mention installation requirements or side effects but is sufficiently complete for a low-complexity tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers both parameters with descriptions (100% coverage). The description adds context about the formatters used per language but does not provide additional semantic details beyond the schema, warranting a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: formatting HDL source code and returning the result. It specifies the tools used for Verilog/SystemVerilog and VHDL, distinguishing it from sibling tools like lint_hdl and synthesize.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that the tool should be used to format HDL code but provides no explicit guidance on when to use it versus alternatives like lint_hdl for linting. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_ipB

Generate a parameterized instance of an IP core. Returns the HDL source files and a ready-to-paste Verilog instantiation snippet with the requested parameter values applied.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Core name, e.g. 'uart_tx' or 'fifo'
`parameters`	No	Parameter overrides, e.g. {"CLKS_PER_BIT": 434}
`instance_name`	No	Verilog instance name (default: <core_name>_inst)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions the return type (HDL files and snippet) but omits side effects, permission requirements, error handling, or whether the tool consumes external resources. Without annotations, this lack of safety and behavioral detail is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with action and output. Every sentence is informative and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and moderate complexity (3 params, one nested object), the description covers the basic purpose and return type but lacks details on expected structure of HDL files, error conditions, and dependencies. It is adequate but leaves gaps that could mislead an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal value ('with the requested parameter values applied') and does not elaborate on the 'parameters' object structure or validation rules beyond the schema. No additional semantic guidance is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Generate') and resource ('parameterized instance of an IP core'), clearly stating the output: 'HDL source files and a ready-to-paste Verilog instantiation snippet'. This distinguishes it from sibling tools like get_ip_core (which likely retrieves without generating) and list_ip_cores (which lists cores).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. With many sibling tools (e.g., get_ip_core, list_ip_cores, import_*), the description fails to mention scenarios where other tools would be more appropriate, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_diagnosticsB

Return structured lint diagnostics (line, column, severity, message) for HDL source. Verilog/SystemVerilog: uses Verilator (primary) with verible-verilog-lint as fallback. VHDL: uses GHDL. All tools are part of OSS CAD Suite.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	HDL source code
`language`	No	HDL language variant	verilog

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the toolchain (Verilator with fallback, GHDL) and mentions OSS CAD Suite, which is helpful. However, it lacks information on side effects, error behavior, required permissions, or performance implications. The read-only nature is implied but not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, no redundant information. The first sentence defines purpose and output structure, the second provides toolchain details. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description compensates by listing the output fields (line, column, severity, message). It also explains language-tool mapping. However, it does not address error cases or tool availability, but overall it is fairly complete for a diagnostic tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage with descriptions for both parameters. The description adds no additional parameter-level meaning beyond what the schema already conveys. Baseline score of 3 is appropriate as the description does not enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns structured lint diagnostics with specific fields (line, column, severity, message). It identifies the resource as 'HDL source' and distinguishes by specifying the toolchain per language. However, it does not explicitly differentiate from sibling tools like 'lint_hdl' or 'lint_project', leaving room for ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. It does not mention when not to use it, prerequisites, or context. The sibling list includes similar tools like 'lint_hdl', but the description offers no basis for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ip_coreB

Fetch the full manifest and HDL source files for a named IP core.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Core name, e.g. 'uart_tx' or 'fifo'

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully convey behavioral traits. It only states the action but does not disclose whether the tool is read-only, any required permissions, side effects, or output format. This is insufficient for a fetch operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the purpose. No extraneous words, every part adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema or annotations, the description is somewhat limited. It explains what the tool does but does not specify what is returned (e.g., raw files, metadata). For a simple fetch, it is minimally adequate but could provide more context about expected output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides a complete description for the only parameter 'name' (e.g., core name with examples). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') and identifies the resource ('full manifest and HDL source files') and the input ('named IP core'). It clearly distinguishes from siblings like 'list_ip_cores' and 'generate_ip'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool vs alternatives such as 'search_github_cores' or 'import_fusesoc_core'. The description does not mention prerequisites or when it is appropriate to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

import_fusesoc_coreA

Import a local FuseSoC CAPI2 .core file into the registry. HDL files referenced in the .core file must exist in the same directory. Useful when you already have FuseSoC cores checked out locally.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute or relative path to the .core file

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description provides one behavioral constraint: HDL files must exist in same directory. However, it does not disclose side effects, idempotency, or what 'registry' entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences directly stating purpose, requirement, and use case. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description provides sufficient context: purpose, prerequisite (HDL files in same dir), and use case. Minor gap: no explanation of registry impact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description is not required to add much. It merely restates the parameter's purpose without further detail, maintaining baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool imports a local FuseSoC CAPI2 .core file into the registry, specifying the file format and local nature, distinguishing it from sibling like import_github_core.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Useful when you already have FuseSoC cores checked out locally,' implying when to use and distinguishing from remote imports, though it doesn't explicitly list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

import_github_coreA

Download an MIT-licensed GitHub repository and add it to the local IP core registry. Automatically uses FuseSoC CAPI2 metadata (.core file) if one exists in the repo. After import, the core is immediately available via get_ip_core and generate_ip.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repo in 'owner/repo' format, e.g. 'ultraembedded/core_uart'
`subdir`	No	Subdirectory within the repo to scope HDL search (for monorepos)
`ref`	No	Branch, tag, or commit SHA (default: repo's default branch)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it downloads repos, automatically uses FuseSoC CAPI2 metadata, adds to a local registry, and makes the core immediately available via other tools. It mentions the MIT license constraint and post-import availability, which are not obvious from the schema. However, it lacks details on error handling, rate limits, or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by implementation details and post-import effects. Every sentence adds value (e.g., MIT license, FuseSoC metadata, availability via other tools) with zero waste, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a tool that downloads, processes, and registers repos) and no annotations or output schema, the description is mostly complete. It covers the purpose, behavior, and outcomes, but lacks details on error cases (e.g., what happens if the repo isn't MIT-licensed or lacks a .core file) and doesn't describe the return value, which is a gap since there's no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain parameter interactions or default behaviors like 'ref' defaulting to the repo's branch). Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Download an MIT-licensed GitHub repository and add it to the local IP core registry') and distinguishes it from siblings like 'import_fusesoc_core' (which likely imports from a different source) and 'search_github_cores' (which only searches). It explicitly mentions the verb+resource combination with the MIT license constraint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (to import GitHub repos with MIT licenses and FuseSoC metadata) and implies an alternative ('import_fusesoc_core' for non-GitHub sources). However, it doesn't explicitly state when NOT to use it (e.g., for non-MIT repos or without .core files) or compare it to 'search_github_cores' for discovery vs. import.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lint_hdlA

Lint HDL source code using iverilog (Verilog/SystemVerilog) or ghdl (VHDL). Returns warnings and errors so you can fix them before synthesis.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	HDL source code to lint
`language`	No	HDL language variant	verilog
`top_module`	No	Top-level module name (optional)

TDQS

A3.9/5.0

Behavior3/5

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 describes the tool's function (linting), tools used (iverilog/ghdl), and output (warnings/errors), but lacks details on error handling, performance, or side effects. It doesn't contradict annotations, but could benefit from more behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and concise with two sentences that efficiently convey purpose, method, and outcome. Every sentence earns its place without redundancy, making it easy for an AI agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 adequately covers the tool's purpose and basic behavior. However, for a tool with 3 parameters and no structured output information, it could be more complete by detailing output format or error cases, though it's sufficient for a linter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain 'top_module' usage or language-specific nuances). Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('lint HDL source code') and resources ('using iverilog or ghdl'), distinguishing it from siblings like format_hdl, simulate, or synthesize. It explicitly mentions the languages supported (Verilog/SystemVerilog/VHDL) and the outcome ('returns warnings and errors').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('so you can fix them before synthesis'), implying it's a pre-synthesis step. However, it doesn't explicitly state when not to use it or name alternatives among siblings like get_diagnostics or simulate, which might offer overlapping functionality.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_ip_coresA

List all available IP cores in the registry. Optionally filter by category.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category, e.g. 'communication' or 'memory'

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries burden—but only states listing operation. Does not disclose return format, pagination, rate limits, or side effects. Adequate for a simple query, but could add context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no filler. Essential information is front-loaded. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list tool with no output schema and no annotations. Missing details like return format or empty-state behavior, but contextually complete enough given simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with schema describing 'category' as filter. Description merely restates filtering without added detail. Baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb (list), resource (IP cores in registry), and optional filtering by category. Distinct from siblings like get_ip_core or search_github_cores due to registry scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for listing all cores or filtered by category, but provides no explicit guidance on when to use this vs. alternatives like get_ip_core or search_github_cores. No exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

litex_buildC

Run LiteX board target with --build. Returns logs and output directory.

ParametersJSON Schema

Name	Required	Description
`board`	Yes	LiteX board target
`args`	No	Extra LiteX CLI args
`output_dir`	No	Optional output directory
`timeout`	No	Timeout in seconds

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavior. It states it runs a build and returns logs and an output directory, but does not reveal side effects (e.g., file creation, duration), required permissions, or error handling. This is insufficient for a build tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loading the core action. However, it may be overly minimal; slightly more detail could enhance clarity without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, no output schema, no annotations), the description lacks completeness. It does not explain return format, timeout behavior, or effect of optional args. The tool's behavior is only partially described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 4 parameters are described in the input schema (100% coverage). The tool description adds no further semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Run) and resource (LiteX board target) with the specific flag --build. It also mentions outputs (logs and output directory). While it doesn't explicitly distinguish from siblings like litex_flow or start_build, the purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like litex_flow or start_build. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

litex_flowA

Run a generic LiteX board target with caller-provided args.

ParametersJSON Schema

Name	Required	Description
`board`	Yes	LiteX board target
`args`	No	Extra LiteX CLI args
`timeout`	No	Timeout in seconds

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavior. It does not mention if the tool is blocking, what side effects occur (e.g., writing to disk), permission requirements, or how output is handled. Minimal transparency beyond purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy. Every word adds meaning. Efficient for a generic tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 24 siblings and no output schema, the description is adequate for a simple runner but could mention typical use case (e.g., for prototyping or custom builds). Nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds 'caller-provided args' but does not explain how args interact with board target or provide examples. No extra semantic value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it runs a generic LiteX board target with caller-provided args. The verb 'Run' and resource 'LiteX board target' are specific, and it distinguishes from siblings like litex_build and litex_soc by being generic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for running arbitrary board targets with extra args, but does not specify when to use this tool over siblings like litex_build or simulate. No explicit alternative or exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

litex_socA

Generate LiteX SoC without building gateware. Returns logs and output directory.

ParametersJSON Schema

Name	Required	Description
`board`	Yes	LiteX board target
`args`	No	Extra LiteX CLI args
`output_dir`	No	Optional output directory
`timeout`	No	Timeout in seconds

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that gateware is not built and that logs and output directory are returned, but lacks details on side effects, permissions, or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single, front-loaded sentence that efficiently conveys the core action and return values. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters and no output schema, the description provides basic purpose and return type. However, it lacks context on prerequisites, file system effects, or error conditions, which would be helpful for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already documented. The description adds no additional meaning beyond the schema; it does not explain how parameters like 'board' or 'args' affect generation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool generates a LiteX SoC without building gateware, distinguishing it from sibling tools like litex_build which actually builds gateware. The verb 'generate' and resource 'LiteX SoC' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage when you want to generate a SoC without building gateware, but does not explicitly state when to use or when not to use. No alternatives are mentioned, leaving the agent to infer from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

place_and_routeA

Synthesize Verilog with Yosys then place-and-route with nextpnr in one step. If backend=litex, runs LiteX build and ignores Verilog inputs. Returns max frequency, critical path, resource utilization, and full logs. Supported targets: ice40, ecp5, nexus, gowin. Common device/package values: ice40: device=hx1k|hx8k|up5k|lp1k package=tq144|qn84|sg48|cm81 ecp5: device=25k|45k|85k package=CABGA256|CABGA381 nexus: device=LIFCL-40-9BG400C (package embedded in device string) gowin: device=GW1N-UV4LQ144C6/I5 (package embedded in device string)

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Verilog source code
`top_module`	Yes	Top-level module name
`target`	Yes	FPGA family
`device`	Yes	Device variant, e.g. 'hx1k', '25k', 'LIFCL-40-9BG400C'
`package`	No	Package, e.g. 'tq144', 'CABGA256' (not needed for nexus/gowin)
`constraints`	No	Optional pin constraints (PCF/LPF/PDC/CST text)
`timeout`	No	PnR timeout in seconds
`backend`	No	PnR backend	yosys
`litex_board`	No	LiteX board target (required if backend=litex)
`litex_args`	No	Extra LiteX CLI args (backend=litex)

TDQS

A4.1/5.0

Behavior4/5

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 effectively describes key behaviors: the two-step synthesis and place-and-route process, backend-specific handling (e.g., LiteX ignoring Verilog inputs), timeout parameter, and the return values (max frequency, critical path, etc.). It also lists supported targets and common device/package values, adding useful operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by backend details, return values, and target-specific notes. It is appropriately sized for a complex tool with 10 parameters, though the device/package list is somewhat lengthy but necessary for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, no annotations, no output schema), the description does a good job of covering the workflow, backend options, return values, and target specifics. It could be more complete by detailing error handling or output format specifics, but it provides sufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all parameters thoroughly. The description adds some value by clarifying device/package examples and noting that package is 'not needed for nexus/gowin', but it does not significantly enhance parameter understanding beyond what the schema provides, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'Synthesize Verilog with Yosys then place-and-route with nextpnr in one step.' It clearly distinguishes this from sibling tools like 'synthesize' (which only does synthesis) and 'litex_build' (which handles LiteX-specific flows), making the scope and differentiation evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool by mentioning the backend options ('yosys' vs 'litex') and noting that 'litex' ignores Verilog inputs. However, it does not explicitly state when to choose this over alternatives like 'synthesize' or 'litex_build', which would be needed for a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_github_coresA

Search GitHub for open-source MIT-licensed FPGA IP cores. Returns repo names, star counts, descriptions and topics. Use import_github_core to download a result into the local registry.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search terms, e.g. 'uart verilog' or 'riscv softcore'
`language`	No	Filter by HDL language (optional)
`max_results`	No	Maximum number of results to return

TDQS

A3.9/5.0

Behavior3/5

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 describes the search scope (GitHub, MIT-licensed), return format, and relationship to import_github_core. However, it doesn't mention rate limits, authentication requirements, error conditions, or pagination behavior, which are important for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with two sentences that each serve distinct purposes: the first defines the tool's function and output, the second provides usage guidance. There's zero wasted language or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no annotations and no output schema, the description provides adequate basic information about purpose and usage. However, it lacks details about the search algorithm, result ordering, error handling, or authentication requirements that would be helpful given the tool's complexity and the absence of structured behavioral annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Search GitHub'), target resource ('open-source MIT-licensed FPGA IP cores'), and return format ('repo names, star counts, descriptions and topics'). It distinguishes from sibling tools by mentioning import_github_core as a complementary action rather than an alternative search method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (searching GitHub for FPGA IP cores) and mentions import_github_core as the next step for downloading results. However, it doesn't explicitly state when NOT to use it or compare it to potential alternatives like get_ip_core or list_ip_cores from the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulateA

Compile and simulate Verilog using Icarus Verilog (iverilog + vvp). Provide the design source and a separate testbench. Returns all $display/$monitor output and any runtime errors.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	Verilog design source
`testbench`	Yes	Verilog testbench source
`timeout`	No	Timeout in seconds

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it compiles and simulates, uses specific tools (iverilog + vvp), returns output from $display/$monitor and runtime errors, and implies a timeout via the parameter. However, it lacks details on permissions, rate limits, or error handling beyond runtime errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose, inputs, and outputs without wasted words. Every sentence adds necessary information, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (simulation with compilation), no annotations, and no output schema, the description is adequate but has gaps. It covers the basic operation and outputs but lacks details on error types, output format, or prerequisites, which could be important for a simulation tool with multiple parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all parameters. The description adds marginal value by mentioning 'design source' and 'testbench' which align with 'code' and 'testbench' parameters, but does not provide additional syntax, format details, or usage examples beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Compile and simulate Verilog') using specific tools ('Icarus Verilog (iverilog + vvp)'), distinguishes from siblings by focusing on simulation rather than formatting, linting, synthesis, or IP management, and explicitly mentions the required inputs ('design source and a separate testbench').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (for Verilog simulation with Icarus Verilog) and implies usage by specifying the required inputs, but does not explicitly state when not to use it or name alternatives among the sibling tools (e.g., 'synthesize' or 'lint_hdl' for other tasks).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

synthesizeB

Synthesize Verilog HDL using Yosys or run LiteX backend. Returns resource statistics and the list of inferred modules. Supported targets: generic, ice40, ecp5, gowin, xilinx, intel.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Verilog source code
`top_module`	Yes	Name of the top-level module
`target`	No	FPGA family / synthesis target	generic
`backend`	No	Synthesis backend	yosys
`litex_board`	No	LiteX board target (required if backend=litex)
`litex_args`	No	Extra LiteX CLI args (backend=litex)
`timeout`	No	Timeout in seconds

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return values ('resource statistics and the list of inferred modules') which is helpful, but doesn't describe important behavioral aspects like whether this is a read-only analysis or a destructive synthesis operation, potential side effects, execution time implications, or error handling. For a complex synthesis tool with 7 parameters, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that efficiently convey the core functionality and supported targets. The first sentence states the main purpose, and the second provides important context about outputs and targets. No wasted words, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex synthesis tool with 7 parameters, no annotations, and no output schema, the description is incomplete. While it mentions return values, it doesn't adequately describe the tool's behavior, side effects, or how it differs from similar tools in the context. The agent would need to infer too much about this potentially complex operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'Supported targets' which aligns with the 'target' parameter enum, but provides no additional context about target differences or selection criteria. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Synthesize Verilog HDL using Yosys or run LiteX backend.' It specifies the action (synthesize/run backend), resource (Verilog HDL), and tools involved (Yosys/LiteX). However, it doesn't explicitly differentiate from sibling tools like 'litex_build' or 'place_and_route' which might have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by mentioning 'Supported targets' and the backend options, but doesn't provide explicit guidance on when to choose this tool versus alternatives like 'litex_build' or 'place_and_route'. It mentions what the tool does but not when it's the appropriate choice among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

15 tool updatesv0.1.0Mar 11, 2026
- First observedformat_hdl
- First observedgenerate_ip
- First observedget_diagnostics
- First observedget_ip_core
- First observedimport_fusesoc_core
- First observedimport_github_core
- First observedlint_hdl
- First observedlist_ip_cores
- First observedlitex_build
- First observedlitex_flow
- First observedlitex_soc
- First observedplace_and_route
- First observedsearch_github_cores
- First observedsimulate
- First observedsynthesize

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-04-13 23:45 across 15 tools

Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between lint_hdl and get_diagnostics, both focusing on HDL linting with different tools, which could cause confusion. Other tools like generate_ip and get_ip_core are clearly differentiated, and the LiteX tools (litex_build, litex_flow, litex_soc) have overlapping functionality but are described with enough detail to distinguish them.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as format_hdl, generate_ip, and list_ip_cores. There are no deviations in naming conventions, making the set predictable and easy to parse for an agent.

Tool Count5/5

With 15 tools, the server is well-scoped for FPGA development tasks, covering code formatting, IP core management, linting, simulation, synthesis, and place-and-route. Each tool serves a specific purpose without redundancy, fitting the domain's complexity appropriately.

Completeness5/5

The tool set provides comprehensive coverage for FPGA workflows, including code preparation (format_hdl, lint_hdl), IP core handling (list_ip_cores, get_ip_core, generate_ip, import functions), simulation (simulate), synthesis (synthesize), and implementation (place_and_route). There are no obvious gaps, supporting end-to-end development from design to gateware.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ChiplabOAuth
ai.veecle
Run, build, and validate firmware on virtual hardware from your AI agent. Hardware knowledge corpus.
Embedded system Code Execution Virtualization
216
Gluecron B
com.gluecron
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Version Control CI/CD & DevOps Code Analysis
622
GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,851
HexisOAuth
io.github.Bevel-Software
Git-backed platform for skills, tools, and context for AI agents
Agent Orchestration Developer Tools
187

Related MCP Servers

EDA Tools MCP Server
Developer Tools Software Architecture
kfy123bot
F
license
A
quality
D
maintenance
Enables AI assistants to perform Electronic Design Automation (EDA) tasks including Verilog synthesis, simulation, ASIC design flows, and waveform analysis through a unified interface.
Updated 5 months ago (2026-04-16 08:49 UTC)
6
-
fpgaZeroMCP
Developer Tools Command Line
lcapossio
A
license
A
quality
B
maintenance
An MCP server for FPGA toolchain operations including linting, simulation, synthesis, place-and-route, bitstream programming, and IP core registry via GitHub.
Updated a month ago (2026-08-19 21:19 UTC)
25
5
MIT
cg-agent-kit
Autonomous Agents Embedded system Developer Tools
Neosyn-Logic
A
license
A
quality
B
maintenance
Enables AI agents to design hardware by writing C-like HDL and compiling it to Verilog, with real toolchain verification including synthesis checks.
Updated a month ago (2026-08-19 20:10 UTC)
10
1
MIT
fpga-mcp
wmm246
A
license
Not graded
quality
C
maintenance
Enables AI assistants to drive Xilinx Vivado, Intel Quartus, and Anlogic TangDynasty for FPGA development, including project creation, synthesis, implementation, timing closure, and hardware programming through natural language.
Updated a month ago (2026-08-06 00:42 UTC)
2
MIT

fpgaZeroMCP

Features

Table of Contents

How it works

Prerequisites

GitHub API access

Installation

MCP Client Setup

Claude Desktop

VS Code (GitHub Copilot)

Cursor / Windsurf

Example prompts

Tools

HDL quality

Design flow

IP core registry

LiteX

Build management

Server / registry

IP Core Registry

Getting cores at runtime

Contributing a core

Synthesis Targets

LiteX

Local Core Repositories

Allowed licenses

Testing

Environment Variables

Standalone / Scripting

core.json Schema

Author

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers