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.
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., "@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.
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.
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: EDA Tools MCP Server
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.
Requirement | Notes |
Python 3.11+ | |
Bundles iverilog, Yosys, nextpnr, Verilator, Verible, GHDL in one download | |
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 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_..."git clone https://github.com/lcapossio/fpgaZeroMCP
cd fpgaZeroMCP
pip install -e .Add to claude_desktop_config.json:
{
"mcpServers": {
"fpgaZeroMCP": {
"command": "python",
"args": ["/path/to/fpgaZeroMCP/server.py"],
"env": { "PYTHONPATH": "/path/to/fpgaZeroMCP" }
}
}
}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" }
}
}
}Add to your MCP settings (Settings → MCP Servers):
{
"fpgaZeroMCP": {
"command": "python",
"args": ["/path/to/fpgaZeroMCP/server.py"],
"env": { "PYTHONPATH": "/path/to/fpgaZeroMCP" }
}
}"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?"
Tool | Description |
| Syntax/error check via iverilog (V/SV) or GHDL (VHDL) — single file |
| Lint multiple files together so cross-module references resolve |
| Structured per-line diagnostics — Verilator → verible fallback (V/SV), GHDL (VHDL) |
| Auto-format via verible-verilog-format (V/SV) or vsg (VHDL) |
Tool | Description |
| Compile and run testbenches — iverilog (V/SV) or GHDL (VHDL). Returns verdict + VCD summary |
| Yosys synthesis with resource stats. Accepts |
| Yosys + nextpnr in one step. Board presets, constraint auto-detection, bitstream output |
| Flash a bitstream via |
| Enumerate built-in board presets (target/device/package/clock) |
Tool | Description |
| Browse the local registry, filter by category |
| Fetch manifest and HDL source for a core |
| Get a parameterized instantiation snippet + source files |
| Search GitHub for MIT-licensed FPGA IP repos |
| Download a GitHub repo into the local registry |
| Import a local FuseSoC CAPI2 |
Tool | Description |
| Run a LiteX board target with |
| Generate a LiteX SoC without building gateware |
| Run a LiteX board target with fully custom args |
Tool | Description |
| Start a long-running command in the background (allowlisted EDA tools only) |
| Check progress — status, elapsed time, parsed phase/utilization/timing |
| List all tracked builds (running and finished) |
| Kill a running background build |
| Delete old build logs by age and total size |
Tool | Description |
| Report which OSS CAD Suite tools are installed, with paths and versions |
| Re-scan core directories without restarting the server |
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.
# 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.
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.
Target | Vendor / Family | Full OSS P&R |
| Lattice iCE40 | yes — nextpnr-ice40 |
| Lattice ECP5 | yes — nextpnr-ecp5 |
| Lattice Nexus (CrossLink-NX, CertusPro-NX) | yes — nextpnr-nexus |
| Gowin | yes — nextpnr-gowin |
| Xilinx / AMD | Synth only |
| Intel / Altera | Synth only |
| Technology-independent | Netlist only |
Common device/package values for place_and_route:
Target | device | package |
ice40 |
|
|
ecp5 |
|
|
nexus |
| (embedded in device string) |
gowin |
| (embedded in device string) |
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"])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-coresWindows (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.
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.0Override 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.
pip install -e ".[dev]"
python -m pytest tests/ -vSome tests require OSS CAD Suite tools on PATH. Tests that need missing tools are skipped automatically.
Variable | Description |
| GitHub personal access token — raises API rate limits |
| Extra core search directories (OS path separator delimited) |
| Comma-separated SPDX IDs for |
| Override temporary workspace root directory |
| OS pathsep-separated list of extra directories that |
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{
"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"]
}Leonardo Capossio (bard0) — hello@bard0.com
MIT — see LICENSE.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | HDL source code to format | |
| language | No | HDL language variant | verilog |
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 reveal that the tool returns both formatted code and a change indicator, which is useful behavioral context. However, it doesn't mention error handling, performance characteristics, or any limitations of the underlying formatters (verible-verilog-format and vsg).
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 perfectly concise with three sentences that each earn their place: the core functionality, the specific formatters used for different languages, and the return values. It's front-loaded with the primary purpose and wastes no words.
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 relatively simple formatting tool with good schema coverage but no output schema, the description provides adequate context. It explains what the tool does, mentions the specific formatters, and describes the return values. However, without an output schema, it could benefit from more detail about the return format structure.
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?
With 100% schema description coverage, the input schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by mentioning that 'code' is 'HDL source code to format' (which the schema already states) and implying the language parameter determines which formatter is used. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Format HDL source code'), the resource involved ('HDL source code'), and the outcome ('return the result'). It distinguishes this tool from siblings like lint_hdl, simulate, and synthesize by focusing specifically on code formatting rather than analysis, verification, or synthesis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (formatting HDL code) and implicitly distinguishes it from siblings by mentioning specific formatters for different languages. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for related tasks like linting or synthesis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool generates files and snippets but lacks details on permissions needed, whether it modifies existing files, error handling, or rate limits. For a tool that likely involves file system operations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and output. It is front-loaded with the main action and avoids unnecessary details, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, nested objects, no output schema), the description is adequate but incomplete. It explains what the tool does but lacks behavioral context and usage guidelines. Without annotations or output schema, more detail on outputs or operational constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters. The description adds no additional meaning beyond implying parameter overrides affect the output, which the schema already covers. Baseline 3 is appropriate as the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate a parameterized instance'), identifies the resource ('IP core'), and specifies the output ('HDL source files and a ready-to-paste Verilog instantiation snippet'). It distinguishes from sibling tools like 'list_ip_cores' or 'get_ip_core' by focusing on generation with parameter application rather than listing or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'import_github_core' or 'synthesize'. It mentions the tool's function but does not specify prerequisites, appropriate contexts, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | HDL source code | |
| language | No | HDL language variant | verilog |
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 adds useful context about the specific linting tools used (Verilator, verible-verilog-lint, GHDL) and mentions they are part of OSS CAD Suite, which helps understand implementation details. However, it doesn't disclose rate limits, error handling, or performance characteristics that would be valuable for an agent.
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 efficiently structured in two sentences: the first states the core purpose and output format, the second specifies the tools used per language. Every sentence adds value with no wasted words, making it appropriately sized and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good purpose and tool implementation context but lacks details about return values, error conditions, or operational constraints. For a diagnostic tool with 2 parameters, it's adequate but has clear gaps in behavioral completeness that would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain code format expectations or language variant implications). Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('return structured lint diagnostics') and resources ('HDL source'), including details about the diagnostic format (line, column, severity, message) and the specific tools used for different languages (Verilator, verible-verilog-lint, GHDL). It distinguishes from siblings like 'lint_hdl' by specifying the structured diagnostic output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for HDL source code linting with specific language variants, but does not explicitly state when to use this tool versus alternatives like 'lint_hdl' or other siblings. It provides context about the tools used but lacks explicit guidance on when/when-not to use it or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full manifest and HDL source files for a named IP core.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Core name, e.g. 'uart_tx' or 'fifo' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions fetching files but does not disclose behavioral traits such as whether this requires authentication, rate limits, what happens if the core doesn't exist, or the format of the returned data. This leaves significant gaps for a tool that retrieves resources.
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 key action and resource. Every word earns its place, with no wasted text, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching files for IP cores), no annotations, and no output schema, the description is minimally adequate but incomplete. It states what is fetched but lacks details on behavior, error handling, or output format, which are important for such an operation.
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%, with the parameter 'name' documented as 'Core name, e.g. 'uart_tx' or 'fifo''. The description adds no additional meaning beyond this, as it only references 'named IP core' without extra details. Baseline 3 is appropriate when schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('fetch') and resource ('full manifest and HDL source files for a named IP core'), distinguishing it from siblings like 'list_ip_cores' (which likely lists names) or 'import_github_core' (which imports from external sources). It precisely defines what the tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need source files for a specific IP core, but it does not explicitly state when to use this versus alternatives like 'import_github_core' or 'search_github_cores'. It provides basic context but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or relative path to the .core file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that 'HDL files referenced in the .core file must exist in the same directory,' which is a crucial behavioral constraint. However, it lacks details on permissions, error handling, or output format, leaving gaps in transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource, followed by a contextual guideline. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a single parameter with full schema coverage, the description is adequate but incomplete. It covers the purpose and a key constraint, but as a mutation tool, it should ideally mention more about behavioral aspects like success indicators or error cases to be fully complete.
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%, with the parameter 'path' fully documented in the schema. The description does not add any additional meaning or context about the parameter beyond what the schema provides, so it meets the baseline of 3 without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Import') and resource ('a local FuseSoC CAPI2 .core file into the registry'), distinguishing it from sibling tools like 'import_github_core' by specifying it's for local files. It explicitly mentions the file format and target system, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Useful when you already have FuseSoC cores checked out locally.' This implicitly suggests an alternative (e.g., 'import_github_core' for remote cores), but does not explicitly state when not to use it or name alternatives directly, keeping it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) |
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.
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.
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.
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.
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.
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 HDL source code using iverilog (Verilog/SystemVerilog) or ghdl (VHDL). Returns warnings and errors so you can fix them before synthesis.
| 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) |
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.
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.
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.
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.
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.
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 all available IP cores in the registry. Optionally filter by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category, e.g. 'communication' or 'memory' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists IP cores with optional filtering, but doesn't describe what 'list' entails (e.g., format, pagination, or limitations), whether it's read-only or has side effects, or any performance or access considerations. This leaves significant gaps for a tool with no annotation coverage.
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 core purpose ('List all available IP cores in the registry') and adds a useful detail ('Optionally filter by category'). There is no wasted text, and it's appropriately sized for a simple tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter intent, but lacks details on behavior, output format, or usage context. For a list tool with no annotations, it should ideally explain more about what 'list' returns or any limitations.
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 description mentions optional filtering by category, which aligns with the single parameter in the input schema. Since schema description coverage is 100% (the parameter is fully documented in the schema), the description adds minimal value beyond what's already structured. It doesn't provide additional syntax, examples, or constraints, so it meets the baseline for high schema coverage.
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 verb ('List') and resource ('all available IP cores in the registry'), making the purpose specific and understandable. It distinguishes from siblings like 'get_ip_core' (singular retrieval) and 'search_github_cores' (external search), though it doesn't explicitly mention these alternatives. The optional filtering adds useful scope but doesn't fully differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing IP cores with optional filtering, but provides no explicit guidance on when to use this tool versus alternatives like 'get_ip_core' (for single core details) or 'search_github_cores' (for external repositories). It mentions filtering by category, which gives some context, but lacks clear when/when-not instructions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run LiteX board target with --build. Returns logs and output directory.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | LiteX board target | |
| args | No | Extra LiteX CLI args | |
| output_dir | No | Optional output directory | |
| timeout | No | Timeout in seconds |
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 mentions that the tool 'Returns logs and output directory', which gives some insight into outputs, but fails to describe critical behaviors like whether this is a read-only or destructive operation (e.g., does it modify files or create new ones?), potential side effects, error handling, or execution environment requirements. For a build tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just one sentence that efficiently conveys the core action and outputs. It is front-loaded with the main purpose ('Run LiteX board target with --build') and avoids any unnecessary details, making it easy to parse quickly. Every word earns its place, with no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a build tool (which typically involves compilation, file generation, and potential side effects), no annotations, and no output schema, the description is incomplete. It lacks information on what the build does (e.g., generates hardware binaries, software images), how outputs are structured, error conditions, or dependencies. The mention of 'Returns logs and output directory' is helpful but insufficient for a tool that likely has significant behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear documentation for all four parameters (board, args, output_dir, timeout). The description adds no additional parameter semantics beyond what the schema already states, such as explaining the format of 'board' values or typical use cases for 'args'. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run LiteX board target with --build') and the resource ('LiteX board target'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its sibling 'litex_flow' or 'litex_soc', which appear related to LiteX workflows, leaving some ambiguity about when to choose this specific build tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'litex_flow' or 'litex_soc'. It mentions the '--build' flag but doesn't explain the context or prerequisites for running a build, such as needing a configured project or specific input files. This lack of comparative or contextual guidance limits its usefulness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a generic LiteX board target with caller-provided args.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | LiteX board target | |
| args | No | Extra LiteX CLI args | |
| timeout | No | Timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'runs' a board with args and timeout. It lacks details on execution environment, permissions needed, side effects (e.g., hardware interaction), error handling, or output format, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of running a board (likely involving hardware/software interaction) and no annotations or output schema, the description is inadequate. It doesn't explain what 'running' entails, expected outcomes, or error conditions, leaving the agent with insufficient context.
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 parameters are well-documented in the schema. The description adds minimal value by implying 'args' are for the LiteX CLI and 'timeout' is for execution, but doesn't provide examples or constraints beyond the schema's defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and target ('LiteX board target'), making the purpose understandable. It distinguishes from siblings by being the only tool with 'litex' in its name that runs a board, though it doesn't explicitly differentiate from 'litex_build' or 'litex_soc' which might be related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'litex_build' or 'litex_soc'. The description mentions 'caller-provided args' but doesn't specify typical use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate LiteX SoC without building gateware. Returns logs and output directory.
| Name | Required | Description | Default |
|---|---|---|---|
| board | Yes | LiteX board target | |
| args | No | Extra LiteX CLI args | |
| output_dir | No | Optional output directory | |
| timeout | No | Timeout in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions returns ('logs and output directory') and the 'without building gateware' constraint. It lacks details on permissions, rate limits, error handling, or what 'Generate' entails operationally (e.g., configuration files, scripts). More behavioral context is needed for a tool with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: first states the purpose and key constraint, second specifies returns. It's front-loaded with the main action and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal but covers basics: purpose, constraint, and returns. For a 4-parameter tool that likely involves system operations (generating SoC configurations), it should provide more context on behavior, outputs, or integration with siblings to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of 'board' values or 'args' usage). Baseline 3 is appropriate as the schema handles parameter documentation 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 clearly states the action ('Generate LiteX SoC') and resource ('LiteX SoC'), specifying it's 'without building gateware'. It distinguishes from sibling 'litex_build' by emphasizing no gateware building, but doesn't explicitly contrast with other siblings like 'litex_flow' or 'synthesize'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating SoC configurations without full hardware implementation, suggesting when to use it (vs. building gateware). However, it doesn't provide explicit alternatives or exclusions, nor guidance on when to choose this over other siblings like 'litex_flow' or 'synthesize'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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)
| 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) |
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.
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.
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.
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.
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.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Verilog design source | |
| testbench | Yes | Verilog testbench source | |
| timeout | No | Timeout in seconds |
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.
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.
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.
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.
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.
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.
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.
| 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 |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run, build, and validate firmware on virtual hardware from your AI agent. Hardware knowledge corpus.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Git-backed platform for skills, tools, and context for AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bard0-design/fpgaZeroMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
