Click on "Deploy 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., "@quartus91-mcp Create a new Quartus project named counter_demo with MAX II board presets."
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.
用 agent 直接控制 Quartus II 9.1 的本地 MCP server。它把 Quartus 9.1 自带的命令行工具封装成 MCP tools，让 Codex 或其他 MCP client 可以创建工程、解析工程、锁引脚、生成 .vwf 仿真波形、运行仿真、编译、读取报告和烧录器件。
这个仓库只包含 MCP server、安装脚本、示例配置和 Codex skill。它不包含 Quartus II 9.1 软件本体，也不包含许可证。使用前需要你已经在自己的电脑上安装了合法可用的 Quartus II 9.1。
检测 Quartus II 9.1 安装、版本、命令行工具和许可证环境变量。
查找并解析 .qpf/.qsf 工程。
用 Quartus Tcl 创建或更新工程。
从已有工程提取可复用模板。
通过直接 pin assignment 或 board preset 批量锁引脚。
内置 MAX II EPM1270T144C5 数字实验板 preset，覆盖 LCM12864 液晶版常用模块。
根据结构化或自然语言仿真需求生成 .vwf 文件。
运行功能仿真、时序仿真、全流程编译或单 stage 编译。
读取 report/summary 文件并提取错误、警告、资源和时序摘要。
查询 JTAG 硬件并通过 quartus_pgm 烧录 .sof/.pof。
附带 quartus91-vhdl-flow Codex skill，让 agent 更稳定地完成“写 VHDL -> 建工程 -> 生成 VWF -> 仿真 -> 编译 -> 锁引脚”的完整流程。
Related MCP server: vivado-mcp
Windows，推荐与 Quartus II 9.1 同机运行。
Node.js 18 或更新版本。
Quartus II 9.1 已安装，例如：
C:\altera\91\quartus
D:\altera\91\quartus如果你的 Quartus 功能需要 license，先在系统或 MCP client 环境里配置 LM_LICENSE_FILE 或 ALTERAD_LICENSE_FILE。
Codex 或其他支持 stdio MCP server 的 MCP client。
Clone 仓库并安装 Node 依赖：
git clone https://github.com/<your-github-user>/quartus91-mcp.git
cd quartus91-mcp
npm install检查 server 能否找到 Quartus：
$env:QUARTUS91_ROOT = "C:\altera\91\quartus"
npm run smoke如果你是 Codex 用户，可以直接写入 ~\.codex\config.toml：
powershell -ExecutionPolicy Bypass -File .\scripts\install-codex-mcp.ps1 `
-QuartusRoot "C:\altera\91\quartus"安装配套 Codex skill：
powershell -ExecutionPolicy Bypass -File .\scripts\install-codex-skill.ps1然后重启 Codex，让 MCP server 和 skill 生效。
如果已经有旧的 quartus91 配置或旧 skill，可以加 -Force 覆盖：
powershell -ExecutionPolicy Bypass -File .\scripts\install-codex-mcp.ps1 `
-QuartusRoot "C:\altera\91\quartus" `
-Force
powershell -ExecutionPolicy Bypass -File .\scripts\install-codex-skill.ps1 -ForceCodex config.toml 示例：
[mcp_servers.quartus91]
command = 'node'
args = ['C:\path\to\quartus91-mcp\src\server.js']
startup_timeout_sec = 30
tool_timeout_sec = 1800
[mcp_servers.quartus91.env]
QUARTUS91_ROOT = 'C:\altera\91\quartus'通用 MCP JSON 示例：
{
"mcpServers": {
"quartus91": {
"command": "node",
"args": [
"C:\\path\\to\\quartus91-mcp\\src\\server.js"
],
"env": {
"QUARTUS91_ROOT": "C:\\altera\\91\\quartus"
}
}
}
}如果 node 不在 PATH 里，把 command 改成 node.exe 的绝对路径，例如：
command = 'C:\Program Files\nodejs\node.exe'Tool | 用途 |
| 检测 Quartus 安装路径、版本、bin/bin64 路径、命令行工具和 license 环境。 |
| 递归查找 |
| 解析 |
| 从已有工程提取可复用的基础设置、source、VWF 和 pins。 |
| 通过 Quartus Tcl 创建或更新工程/revision。 |
| 列出内置板级 preset 和可绑定资源。 |
| 对已有工程设置直接引脚或 board preset 资源引脚。 |
| 从信号、时钟、脉冲、事件、bus sequence 生成 |
| 用 |
| 运行 |
| 运行单个 stage，例如 map、fit、asm、sta、tan、sim。 |
| 执行 Quartus Tcl 命令、inline script 或脚本文件。 |
| 读取并摘要 Quartus report/summary。 |
| 调用 |
| 调用 |
| 打开 Quartus GUI，可选打开指定工程。 |
内置 preset：
maxii_epm1270t144c5_lab默认器件设置：
Family: MAX II
Device: EPM1270T144C5
I/O standard: 3.3-V LVTTL常用资源包括：
clock
reset
button
leds
switches
buttons
logic_input_8
logic_output_5
seven_segment_segments
seven_segment_decimal_point
seven_segment_pdf_segments
seven_segment_digits
dot_matrix_rows
dot_matrix_red_cols
dot_matrix_green_cols
buzzer
keypad_rows
keypad_cols
ps2
uart1
uart2
vga
fram
adc_ads7816
dac_tlv5638
i2c_shared
temperature_sensor
eeprom_24lc02
lcd12864_control
lcd12864_data
lcd12864
完整引脚表在 skills/quartus91-vhdl-flow/references/maxii-board-preset.md。
{
"name": "quartus_create_project",
"arguments": {
"projectDir": "projects/counter_demo",
"projectName": "counter_demo",
"revision": "counter_demo",
"boardPreset": "maxii_epm1270t144c5_lab",
"topLevelEntity": "counter_demo",
"sourceFiles": ["counter_demo.vhd"],
"resourceBindings": [
{ "resource": "clock", "signal": "clk" },
{ "resource": "reset", "signal": "reset" },
{ "resource": "switches", "signal": "sw", "count": 2 },
{ "resource": "leds", "signal": "led", "count": 8 }
]
}
}{
"name": "quartus_generate_vwf",
"arguments": {
"projectPath": "projects/counter_demo/counter_demo.qpf",
"outputFile": "counter_demo_stimulus.vwf",
"attachToProject": true,
"simulationTime": 500,
"timeUnit": "ns",
"requirementsText": "clk 20 ns period; rst_n low for 40 ns then high; din changes every 20 ns starting at 60 ns.",
"signals": [
{ "name": "clk", "direction": "INPUT" },
{ "name": "rst_n", "direction": "INPUT", "defaultValue": 0 },
{ "name": "din", "width": 8, "direction": "INPUT", "defaultValue": "0x00", "radix": "Hexadecimal" },
{ "name": "done", "direction": "OUTPUT" }
],
"clocks": [
{ "signal": "clk", "period": 20, "dutyCycle": 50 }
],
"events": [
{ "signal": "rst_n", "time": 0, "value": 0 },
{ "signal": "rst_n", "time": 40, "value": 1 }
],
"sequences": [
{ "signal": "din", "width": 8, "start": 60, "step": 20, "values": ["0x01", "0x02", "0x04", "0x08"] }
]
}
}运行功能仿真：
{
"name": "quartus_simulate_vwf",
"arguments": {
"projectPath": "projects/counter_demo/counter_demo.qpf",
"mode": "functional",
"timeoutSeconds": 1800
}
}仓库内置 skill：
skills/quartus91-vhdl-flow安装后，Codex 可以在相关请求中自动触发，也可以显式输入：
Use $quartus91-vhdl-flow to create a VHDL project for the MAX II board, generate a .vwf stimulus file, lock pins, and run a functional simulation.这个 skill 会指导 agent：
用 Quartus II 9.1 兼容的 VHDL 写法。
根据用户的自然语言仿真需求生成 .vwf。
优先使用 maxii_epm1270t144c5_lab preset 锁引脚。
避免 VGA/LED、I2C、数码管小数点等共享引脚冲突。
先 dry-run 不确定的仿真/编译命令，再实际运行。
npm run smokesmoke test 会真实启动 MCP server，并检查：
MCP tools 能否列出。
quartus_info 是否能找到 Quartus。
示例工程解析是否可用。
临时工程创建是否可用。
.vwf 生成和 QSF 挂载是否可用。
board preset 引脚展开是否可用。
仿真和编译命令 dry-run 是否可用。
Quartus II 9.1 很老，现代 SystemVerilog、VHDL-2008、Tcl 或 SDC 特性不一定兼容。
编译、仿真和烧录都会启动真实 Quartus 子进程；不确定参数时先使用支持 dryRun 的工具。
烧录前先调用 quartus_list_hardware，确认 cable 和 JTAG 链。
QUARTUS91_ROOT 应指向 Quartus 的 quartus 目录，或传给安装脚本一个包含 quartus 子目录的安装根目录。
这个仓库的 MAX II 引脚 preset 来自历史 Quartus 工程和 MAXII 数字实验板 LCM12864 版资料整理。请以你手头板卡原理图为最终依据。
MIT. See LICENSE.
Create a Quartus project/revision with device, top entity, HDL/SDC files, pin assignments, and generic assignments using Quartus Tcl.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectDir | Yes | Directory to create/open the project in. | |
| projectName | Yes | Quartus project name without .qpf. | |
| revision | No | Revision name. Defaults to projectName. | |
| overwrite | No | Overwrite an existing project/revision. Defaults to false. | |
| boardPreset | No | Board preset id. Use quartus_list_board_presets to inspect available presets. | |
| applyBoardDefaults | No | Apply board preset family/device/common assignments. Defaults to true when boardPreset is provided. | |
| family | No | FPGA family, for example Cyclone. | |
| device | No | Exact device, for example EP1C6F256C6. | |
| topLevelEntity | No | Top-level entity/module name. | |
| sourceFiles | No | HDL, BDF, QIP, SDC, VWF, or other project files. | |
| sdcFiles | No | Timing constraint files. Added as SDC_FILE. | |
| globalAssignments | No | Additional set_global_assignment items. | |
| locationAssignments | No | Pin/location assignments such as {to:'clk', location:'PIN_G1'}. | |
| resourceBindings | No | Pin assignments derived from a board preset resource library. | |
| instanceAssignments | No | Additional set_instance_assignment items. | |
| timeoutSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It mentions 'using Quartus Tcl' and the overwrite parameter, but does not reveal whether the tool is destructive, authentication requirements, side effects (e.g., file system changes), or limits on concurrent operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded with the core purpose, and contains no extraneous information. Every word contributes to understanding the tool's function.
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 (18 parameters, 2 required), the description covers the main functional areas but omits some parameter groups like resourceBindings, instanceAssignments, and timeout. The rich schema compensates partially, but the description alone is not fully comprehensive.
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 94%, so most parameters are already documented. The description lists high-level categories (HDL/SDC files, pin assignments) but does not add significant meaning beyond the schema. For example, 'resourceBindings' is not mentioned in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Create a Quartus project/revision' with a clear verb and resource, and lists the key elements (device, top entity, files, assignments). It distinguishes the tool from siblings like quartus_list_projects (listing) and quartus_run_flow (execution).
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 project creation/update but does not provide explicit guidance on when to use this tool versus alternatives like quartus_run_tcl or quartus_set_pins. No when-not-to-use criteria 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.
Extract reusable project defaults, source assignments, simulation settings, and pin assignments from an existing Quartus .qpf/.qsf project.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| includeSources | No | Include source file assignments in the template. Defaults to true. | |
| includePins | No | Include location assignments in the template. Defaults to true. | |
| includeSimulation | No | Include VWF/vector source assignments. Defaults to true. | |
| includeVolatile | No | Include creation/version/MISC assignments. Defaults to false. |
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 only says 'extract' without specifying whether the tool modifies the existing project, what output it produces (e.g., a new file or console output), or any prerequisites like Quartus installation. This leaves significant ambiguity.
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-formed sentence with no wasted words. It front-loads the action ('Extract reusable project defaults...') and is immediately understandable.
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 8 parameters and no output schema, the description is too minimal. It does not explain the output format (e.g., file path, data structure), default values for required parameters, or error conditions. The tool's behavior is only partially specified.
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 covers 100% of parameters with descriptions. The description lists the components being extracted (defaults, sources, pins, simulation settings), which partially maps to the boolean parameters, but adds no additional meaning beyond the schema's descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Extract' and identifies the resource as 'reusable project defaults, source assignments, simulation settings, and pin assignments from an existing Quartus .qpf/.qsf project.' This clearly differentiates it from sibling tools like quartus_create_project (creation) and quartus_inspect_project (inspection).
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 explicit guidance is given on when to use this tool versus alternatives. The context of extracting templates is implied, but there is no mention of when not to use it or which sibling tool is better for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Quartus II Vector Waveform File (.vwf) from structured simulation requirements: signals, clocks, pulses, point events, and bus sequences. Optionally attach it to a project as VECTOR_WAVEFORM_FILE/VECTOR_INPUT_SOURCE.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| outputFile | No | Output .vwf path. Relative paths use the project directory when a project is provided, otherwise the workspace root. | |
| attachToProject | No | Update QSF VECTOR_WAVEFORM_FILE and VECTOR_INPUT_SOURCE. Defaults to true when a project is provided. | |
| requirementsText | No | Original natural-language simulation requirement, kept as a comment in the generated VWF. | |
| simulationTime | Yes | Total simulation duration in the selected timeUnit. | |
| timeUnit | No | VWF time unit. Defaults to ns. | |
| gridPeriod | No | Waveform editor grid period. Defaults to 10. | |
| gridPhase | No | Waveform editor grid phase. Defaults to 0. | |
| gridDutyCycle | No | Waveform editor grid duty cycle. Defaults to 50. | |
| signals | No | ||
| clocks | No | ||
| pulses | No | ||
| events | No | ||
| waveforms | No | ||
| sequences | No | ||
| timeoutSeconds | No |
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 only states that the tool generates and optionally attaches the file, without disclosing side effects (e.g., file overwriting behavior, required permissions, error cases). The description is too brief to adequately inform the agent of behavioral traits.
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, consisting of two short sentences. The first sentence directly states the primary purpose and key input types; the second adds the optional attachment behavior. No redundant information, and critical information is front-loaded.
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 21 parameters and no output schema, the description is adequate for a high-level understanding but lacks detail on parameter interdependencies and behavior. It covers the essential purpose and optional feature but does not explain the mechanics or provide enough context for complex usage scenarios.
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 has 67% parameter description coverage, so the schema provides most parameter semantics. The tool description only lists high-level input categories (signals, clocks, etc.) without adding meaningful detail about how parameters work together. It does not compensate for the 33% of parameters lacking descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Quartus II Vector Waveform File (.vwf) from structured simulation requirements, listing the supported input types (signals, clocks, pulses, etc.). It also mentions optional attachment to a project, which differentiates it from sibling tools like quartus_simulate_vwf (which simulates rather than generates).
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 explicit guidance on when to use this tool versus alternatives. The description implies usage for generating VWF files but does not mention exclusions or conditions (e.g., when to use quartus_simulate_vwf instead). The context for use is only implicitly provided by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the Quartus II 9.1 installation, executable paths, version output, and license-related environment.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates detection of various installation aspects but does not explicitly state read-only nature or potential side effects. The absence of destructive hints is acceptable but could be clearer.
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?
Single sentence, no redundant information. Efficiently conveys the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, and description lacks details on return values such as structure of detected info. License-related environment is vague. Could be more complete given absence of 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?
Input schema has 100% coverage with descriptions for both parameters. The description does not add 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it detects Quartus II installation details, executable paths, version, and license environment. This distinguishes it from sibling tools like quartus_create_project or quartus_run_flow, which perform different actions.
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 obtaining installation info but does not specify when to prefer this over alternatives or when not to use it. No explicit guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a Quartus .qpf/.qsf project and summarize revisions, device, top entity, source files, SDCs, and assignments.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| includeAssignments | No | Include full parsed QSF assignments. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions parsing and summarizing, leaving out behavioral traits such as read-only nature, permissions, or side effects. Minimal disclosure beyond basic function.
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?
Single sentence, front-loaded with verb and resource, no fluff. However, could be slightly more structured (e.g., listing outputs) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is too sparse. Does not explain return format, limitations, or what 'assignments' specifically includes.
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 coverage is 100%, so baseline is 3. Description does not add any meaning beyond schema fields, which already describe each parameter 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?
Description clearly states the tool parses Quartus project files and summarizes key elements (revisions, device, top entity, source files, SDCs, assignments). Distinct from siblings which create, extract, or run flows.
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 explicit when-to-use or when-not-to-use guidance. Implies usage for inspection, but lacks comparison to sibling tools like quartus_info or quartus_read_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List built-in board presets derived from existing Quartus projects, including default device settings and named pin resources.
| Name | Required | Description | Default |
|---|---|---|---|
| presetId | No | Optional preset id to return only one preset. |
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 implies read-only operation by stating 'list built-in board presets derived from existing Quartus projects,' but does not explicitly confirm nondestructive behavior, rate limits, or what happens if no presets exist. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words, front-loaded with the core action ('List built-in board presets'). Every word contributes meaning, with no redundancy or wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately covers the scope and contents of the output. However, it could be slightly more complete by mentioning that presets are read-only or that the list may be empty if no projects exist.
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 coverage is 100% as the optional 'presetId' parameter is described in the schema. The tool description adds no additional parameter meaning beyond the schema, which is acceptable given high coverage. The description's mention of output contents (device settings, pin resources) is not parameter-related.
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 lists built-in board presets derived from existing Quartus projects, including default device settings and named pin resources. It uses a specific verb ('List') and resource ('built-in board presets'), and it is distinct from sibling tools that focus on project creation, extraction, or hardware listing.
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, nor any prerequisites or exclusions. It only describes what the tool does, leaving agents without context for optimal selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Quartus programming hardware and JTAG chains using quartus_pgm and jtagconfig.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| timeoutSeconds | No |
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 states it lists hardware using quartus_pgm and jtagconfig, implying a read-only operation. However, it does not disclose potential side effects (unlikely), required permissions, or behavior with no JTAG hardware connected. The transparency is adequate for a simple list but lacks depth.
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, front-loaded sentence that conveys the core purpose and implementation details with zero wasted words. It is maximally concise while providing necessary 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?
No output schema exists, yet the description does not describe the return value format or structure. It lacks mention of prerequisites (e.g., Quartus installation) and error conditions (e.g., no JTAG hardware). For a tool that produces output, this information is critical for agent decision-making.
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 67% (2 of 3 parameters have descriptions). The description adds no information about parameters, leaving timeoutSeconds undocumented. Since coverage is below 80%, the description fails to compensate, resulting in poor parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and clearly identifies the resource as 'available Quartus programming hardware and JTAG chains'. It mentions the underlying commands (quartus_pgm and jtagconfig), which adds specificity. It distinguishes from siblings like quartus_program_device or quartus_info, but does not explicitly contrast them.
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 vs alternatives. It does not mention prerequisites, when-not scenarios, or alternatives. For a tool with many siblings, this omission is significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find .qpf projects under a directory and parse their revisions.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Directory to scan. Defaults to the QuartusII91 workspace root. | |
| maxDepth | No | Recursive scan depth. Defaults to 6. | |
| maxProjects | No | Maximum projects to return. Defaults to 200. | |
| includeInstallTree | No | Also scan the Quartus install tree. Defaults to false because it is large. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action (find and parse) without disclosing side effects, auth needs, or other behavioral traits. With no annotations, the description carries full burden but remains minimal.
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?
A single, front-loaded sentence with no wasted words. Efficient and to the point.
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 tool with no output schema and no annotations, the description is minimal. It does not mention return format, defaults, or scanning behavior (recursive, maxDepth) which would help an agent.
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 baseline is 3. The description adds no extra parameter meaning beyond what the schema already 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 tool finds .qpf projects and parses their revisions, which distinguishes it from sibling tools like quartus_create_project or quartus_inspect_project.
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 on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description does not help an agent decide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch the Quartus GUI, optionally opening a project. This starts a detached visible process.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the process is detached and visible, which is behavioral information beyond the input schema. However, it does not disclose lifecycle details (e.g., blocking, error behavior) or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. The first sentence front-loads the primary purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is too minimal. It omits error handling, return behavior, and prerequisites (e.g., Quartus installation). More context is needed for a tool that launches an external GUI.
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 baseline is 3. The description adds no extra meaning beyond 'optionally opening a project,' which is already covered by the parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Launch the Quartus GUI, optionally opening a project.' It specifies the verb (launch), resource (Quartus GUI), and optionality. This distinctively describes the tool's purpose among siblings, as no other sibling tool opens the GUI.
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 an implicit usage context (to launch the GUI), but it does not explicitly state when to use this tool over alternatives or any exclusions. Given many sibling tools, explicit guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Program a device through quartus_pgm using a CDF file or explicit programming operations.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| workingDir | No | Working directory. Relative paths are resolved from the workspace root. | |
| cable | Yes | Cable name from quartus_pgm -l, for example 'USB-Blaster [USB-0]'. | |
| cdfFile | No | CDF file to pass to quartus_pgm. | |
| mode | No | Programming mode such as JTAG. Defaults to JTAG. | |
| operations | No | Programming operations such as 'p;output_files/top.sof'. Ignored when cdfFile is set. | |
| timeoutSeconds | No | ||
| maxOutputBytes | No | ||
| dryRun | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as destructive nature (overwriting device), dependency on external tools, or runtime behavior. Lacks critical safety and side-effect information.
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?
Single sentence is concise and covers the core purpose. Could be slightly more structured (e.g., bullet points for modes) but efficiently communicates the key idea.
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 10 parameters and no output schema, the description is too minimal. Does not explain return values, error behavior, or parameter relationships like installRoot/workingDir. Lacks completeness for a complex programming 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?
While schema covers 70% of parameters individually, the description adds valuable context: it explains the interplay between cdfFile and operations (operations ignored when cdfFile set). This goes beyond schema descriptions.
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?
Description clearly states the action (program), the resource (device through quartus_pgm), and the two methods (CDF file or explicit operations). It distinguishes from sibling tools like quartus_create_project by focusing on device programming.
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 explicit guidance on when to use this tool vs alternatives, no mention of prerequisites (e.g., cable must be connected, quartus_pgm required), or when not to use. The description only mentions two methods but does not guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and summarize a Quartus report/summary file from a project directory.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| file | No | Specific report file path. Relative paths are resolved from the project directory. | |
| kind | No | Report kind to pick when file is omitted. Defaults to latest. | |
| maxChars | No | Maximum report text to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It only states 'read and summarize' without mentioning side effects (likely none), required permissions, or error conditions like missing files. This is insufficient for a tool with 7 parameters.
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, concise sentence. It front-loads the purpose but is slightly vague. While efficient, it could include more specifics without becoming verbose.
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 7 parameters and no output schema, the description is too brief. It fails to explain the summarization behavior, supported report kinds, or how parameters interact. More detail is needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal extra meaning. It mentions 'summarize' but does not elaborate on parameter choices. The baseline of 3 is appropriate as the schema already describes each parameter's meaning.
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 reads and summarizes Quartus reports from a project directory. The verb 'read and summarize' and resource 'report/summary file' are specific, distinguishing it from sibling tools like quartus_create_project or quartus_run_flow, which perform different actions.
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. The description implies usage when needing to read a report, but lacks explicit context, prerequisites, or exclusions. Siblings like quartus_inspect_project might overlap in purpose but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run quartus_sh --flow for a project, such as compile or early_timing_estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| flow | No | Flow name. Defaults to compile. | |
| timeoutSeconds | No | Timeout in seconds. Defaults to 1800. | |
| maxOutputBytes | No | ||
| dryRun | No | Return the command without running it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, permissions, error behaviors, or output format. For a complex tool with 10 parameters, the minimal description leaves significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too short for a tool with 10 parameters and no output schema. It efficiently conveys the basic idea but omits necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and high parameter count, the description fails to explain return values, prerequisites, or typical use cases. It lacks completeness for an agent to invoke confidently.
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 90%, so the schema already documents most parameters. The description adds no extra meaning beyond the schema. A baseline of 3 is appropriate given 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 states the tool runs a Quartus flow (e.g., compile, early_timing_estimate) but does not differentiate from sibling tools like quartus_run_stage. It is clear on the verb-resource pair but lacks specificity to distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., quartus_run_stage, quartus_run_tcl). No context about prerequisites or conditions. The description offers no usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one Quartus command-stage executable such as quartus_map, quartus_fit, quartus_asm, quartus_sta, or quartus_pgm-adjacent tools.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| stage | Yes | Stage executable key. | |
| args | No | Extra CLI arguments appended after project/revision arguments. | |
| timeoutSeconds | No | Timeout in seconds. Defaults to 900. | |
| maxOutputBytes | No | ||
| dryRun | No |
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 only says 'Run one Quartus command-stage executable' and lists examples, but fails to mention that it launches a process, blocks until completion, requires specific permissions, or handles errors. The lack of side-effect or safety information is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is well-structured and front-loaded, but the brevity sacrifices informative content.
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?
Despite having 11 parameters and no output schema, the description is extremely brief. It does not explain what happens after execution, how to interpret results, or preconditions. For a complex tool, the description is incomplete.
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 82% (high), so baseline is 3. The description adds no extra meaning beyond the schema; it only gives examples of stage values. The schema already describes parameters adequately, so no penalty.
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 the resource 'Quartus command-stage executable', with specific examples like quartus_map, quartus_fit. It effectively distinguishes from sibling tools such as quartus_run_flow by focusing on individual stages.
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 quartus_run_flow, quartus_run_tcl, or quartus_read_report. The description does not help an agent decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Quartus Tcl command, inline script, or script file through quartus_sh.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectDir | No | Working directory. Relative paths are resolved from the workspace root. | |
| tclCommand | No | Single Tcl command. Defaults to script mode for full Tcl compatibility. | |
| script | No | Inline Tcl script body. Written to a temporary .tcl and run with -t. | |
| scriptPath | No | Existing Tcl script file to run with -t. | |
| scriptArgs | No | Arguments appended after the script path. | |
| useQuickEval | No | Use quartus_sh --tcl_eval for tclCommand. Defaults to false because Quartus 9.1 quick-eval does not support every Tcl builtin. | |
| keepTempScript | No | Keep generated temporary script. Defaults to true for traceability. | |
| timeoutSeconds | No | ||
| maxOutputBytes | No | ||
| dryRun | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool runs commands via quartus_sh but omits critical traits: whether it modifies project state, requires prerequisites (e.g., an open project), or has side effects. The description is too terse to compensate for the lack of annotations.
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, concise sentence that immediately communicates the tool's core function. It is front-loaded and contains no extraneous words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters (none required), no output schema, and no annotations. The description fails to explain common use cases, return values, or how parameters interact (e.g., the mutual exclusivity of tclCommand, script, and scriptPath is not hinted). Given the tool's complexity, the description is too minimal 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 75% (9 of 12 parameters have descriptions in the schema), which is high but not >80%. The tool description itself adds no parameter-specific meaning beyond the schema—it merely summarizes the tool's purpose. Given the schema already documents most parameters, the description's lack of additional parameter information is acceptable but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Run') and clearly identifies the resource ('Quartus Tcl command, inline script, or script file through quartus_sh'). It distinguishes this tool from sibling tools that perform specific Quartus tasks (e.g., quartus_run_flow) by highlighting its general-purpose Tcl execution capability.
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. Sibling tools exist for specific operations (e.g., quartus_create_project, quartus_run_flow), but the description does not indicate that this tool is for arbitrary Tcl commands not covered by those specialized tools. No when-not or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply direct pin assignments or board-preset resource bindings to an existing Quartus project using set_location_assignment.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| boardPreset | No | Board preset id for resourceBindings. Defaults to maxii_epm1270t144c5_lab when resourceBindings are used. | |
| assignments | No | Direct assignments. Each item must include to/signal and location/pin. | |
| resourceBindings | No | Assignments derived from a board preset resource library. | |
| clearExisting | No | Remove existing LOCATION assignments for each destination before setting the new one. Defaults to true. | |
| allowLocationReuse | No | Allow two signals to use the same physical pin. Defaults to false. | |
| ioStandard | No | Optional per-pin IO_STANDARD instance assignment, for example '3.3-V LVTTL'. | |
| timeoutSeconds | No | ||
| dryRun | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It fails to mention that the tool modifies the project file (QSF), may overwrite existing assignments, or requires Quartus to be installed. The clearExisting parameter hints at overwriting, but the description itself does not state side effects or safety considerations.
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 immediately conveys the core action. It avoids redundancy and is front-loaded with key information. However, adding a second sentence for context would improve completeness without sacrificing conciseness.
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?
Despite 14 parameters and no output schema, the description is too brief. It does not explain return values, timeout behavior, or the need for Quartus installation. For a tool that modifies project settings, more context is needed to ensure correct usage.
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 coverage is 86%, so the schema already explains most parameters. The description adds minimal value by mentioning 'direct assignments' and 'resource bindings' but does not elaborate on how these two modes work or the relationships between parameters like boardPreset and resourceBindings. It meets the baseline but does not enhance understanding.
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: applying direct pin assignments or board-preset resource bindings to an existing Quartus project. It uses specific verbs (apply, using set_location_assignment) and identifies the resource (pin assignments/bindings). This distinguishes it well from sibling tools like quartus_create_project or quartus_list_board_presets.
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 (e.g., when to use resourceBindings vs direct assignments, or prerequisites like having an open project). Users must infer from the description that an existing Quartus project is required, but no explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Quartus II simulation using a .vwf/.cvwf/.vec/.tbl/.scf/.vcd vector source. For functional simulation, it can first generate the functional simulation netlist with quartus_map.
| Name | Required | Description | Default |
|---|---|---|---|
| installRoot | No | Quartus root. Accepts either the Quartus install directory or its parent. | |
| use64bit | No | Use quartus/bin64 when available. Defaults to true. | |
| projectPath | No | Path to a .qpf file or project directory. | |
| projectDir | No | Project directory. Relative paths are resolved from the workspace root. | |
| projectName | No | Quartus project name without .qpf. | |
| revision | No | Quartus revision name. Defaults to the active revision in the .qpf. | |
| vwfFile | No | Vector source file. Defaults to VECTOR_INPUT_SOURCE or VECTOR_WAVEFORM_FILE from the QSF. | |
| mode | No | Simulation mode. Defaults to functional. | |
| generateFunctionalNetlist | No | Run quartus_map --generate_functional_sim_netlist before functional simulation. Defaults to true for functional mode. | |
| checkOutputs | No | Pass --check_outputs=on/off. | |
| overwriteWaveform | No | Pass --overwrite_waveform=on/off. Defaults to true. | |
| resultsFormat | No | Simulation results format. | |
| simArgs | No | Extra arguments appended to quartus_sim. | |
| timeoutSeconds | No | ||
| maxOutputBytes | No | ||
| dryRun | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It indicates the tool runs simulation and can generate a netlist, but does not disclose side effects (e.g., file modifications), system requirements, or whether existing results are overwritten. This is minimal disclosure for a complex simulation 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, concise and front-loaded with the core purpose. It avoids redundancy but could benefit from slight restructuring to improve scannability. Every sentence adds value.
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 16 parameters with 0 required and no output schema, the description is too brief. It omits default behaviors, parameter interdependence, and expected output format. A tool of this complexity needs more context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 81%, so the schema already documents most parameters. The description adds context by listing supported vector file formats and noting that functional netlist generation can be triggered. However, it does not elaborate on other parameters like dryRun or timeoutSeconds beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Run Quartus II simulation using a .vwf/.cvwf/.vec/.tbl/.scf/.vcd vector source.' This clearly specifies the action (simulate) and resource (vector waveform file), distinguishing it from sibling tools that handle project creation, programming, or other flows.
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 mentions 'For functional simulation, it can first generate the functional simulation netlist with quartus_map,' giving a usage hint but lacks explicit guidance on when to use this tool instead of alternatives like quartus_run_flow or quartus_run_stage. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0quartus_create_projectquartus_extract_project_templatequartus_generate_vwfquartus_infoquartus_inspect_projectquartus_list_board_presetsquartus_list_hardwarequartus_list_projectsquartus_open_guiquartus_program_devicequartus_read_reportquartus_run_flowquartus_run_stagequartus_run_tclquartus_set_pinsquartus_simulate_vwfScored across 16 tools
Each tool targets a distinct aspect of Quartus workflow (project creation, extraction, simulation, programming, etc.), with no overlapping purposes. Agents can clearly differentiate them.
All tools follow the consistent 'quartus_verb_noun' pattern in snake_case, making them predictable and easy to navigate.
16 tools are well-scoped for the Quartus domain, covering project management, synthesis, simulation, and device programming without excess or deficiency.
The set covers essential Quartus operations (create, compile, simulate, program) but lacks direct tools for editing SDC constraints or advanced timing closure, which are minor gaps.
Flash and run real firmware on physical embedded dev boards from an AI agent, over MCP.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
