Which integrations are available for this server?

Provides tools for FPGA power estimation and analysis using Xilinx Power Design Manager (PDM), allowing users to manage projects, configure scenarios, and evaluate power consumption.

How do I use PDM MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PDM MCP Server Open my project and show power summary" 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.

PDM MCP Server

by Can-Y

Overview Schema Related Servers Score Discussions

Python

Local

PDM MCP Server

AI 驱动的 FPGA 功耗评估助手 — 将 Xilinx Power Design Manager (PDM) 的 Python API 封装为 MCP (Model Context Protocol) 服务，供 AI Agent 通过自然语言进行功耗建模与分析。

前置条件

Python ≥ 3.10
Xilinx PDM (Power Design Manager) 已安装
- PDM 的 Python API (xv_pdm_pytasks) 必须可用
- 安装路径会被自动检测（详见下方「PDM 路径配置」）

Related MCP server: MCP for Vivado

安装

从源码安装

git clone <repo-url>
cd pdm_mcp
pip install .

安装后可使用 pdm-mcp 命令：

pdm-mcp version   # 显示版本
pdm-mcp serve     # 启动 MCP server

PDM 路径配置

MCP Server 启动时会按以下优先级自动查找 PDM 安装路径：

PDM_HOME 环境变量 → $PDM_HOME/pdm.bat
项目根目录的 path.txt 文件（格式：PDM：H:\path\to\PDM\bin）
系统 PATH 中的 pdm.bat / pdm
默认安装路径回退（C:/Xilinx/*/PDM/bin/pdm.bat 等）

若自动检测失败，可创建 path.txt 指定路径，或设置环境变量：

set PDM_HOME=H:\AMDDesignTools\PDM_2026.1\PDM\bin

MCP 客户端配置

在 AI 客户端（如 Kimi Code、Claude Desktop 等）中添加 MCP Server 配置：

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

如果未安装到系统 PATH，指定完整路径：

{
  "mcpServers": {
    "pdm-mcp": {
      "command": "python",
      "args": ["-m", "pdm_mcp", "serve"],
      "cwd": "H:/path/to/pdm_mcp"
    }
  }
}

使用

MCP Server 提供 10 个工具，每个工具通过 action 参数选择具体操作。

1. `session` — 会话管理

action	参数	说明
`start`	`session_id` (默认 `"default"`), `mode` (默认 `"py"`), `pdm_path`, `timeout`	启动 PDM 子进程会话
`stop`	`session_id`	关闭指定会话
`list`	无	列出所有活跃会话

session(action="start")
session(action="list")
session(action="stop", session_id="my_session")

2. `project` — 项目管理

action	关键参数	说明
`open`	`path`	打开 .pdm 项目文件
`create`	`name`, `part`	创建新项目
`close`	无	关闭当前项目
`save`	`save_path` (可选)	保存/另存为
`info`	无	项目基本信息
`list_blocks`	无	列出所有 Block
`list_architectures`	无	列出可用 FPGA 架构
`list_parts`	`architecture`, `package_filter`	筛选器件型号
`list_processes`	无	列出工艺角 (Maximum/Typical)
`select_part`	`part`, `process`	更换器件
`import_xpe`	`file`, `append`	导入 XPE 文件
`export_xdc`	`file`, `thermal`, `rails`, `overwrite`	导出 XDC 约束
`export_power_design`	`file`, `overwrite`	导出 Power Design XML
`reset`	无	重置项目数据

project(action="open", path="my_design.pdm")
project(action="save")
project(action="info")
project(action="list_parts", architecture="Artix-7", package_filter="csg324")

3. `power` — 功耗查询

action	关键参数	说明
`summary`	无	总功耗摘要（自动保存快照）
`block_power`	`block_name`	指定 Block 功耗分解
`rails`	无	电源轨电压/电流/功耗
`thermal`	无	热分析（结温/θ-JA/裕量）
`clock_power`	无	各时钟域功耗
`export_report`	`output_path`	导出功耗报告

power(action="summary")
power(action="block_power", block_name="logic")
power(action="export_report", output_path="report.txt")

4. `scenario` — 场景配置

action	关键参数	说明
`set_environment`	`temp`, `airflow`, `heatsink`	温度/风流量/散热器
`set_clock_frequency`	`name`, `freq_mhz`	修改时钟频率
`set_toggle_rate`	`block`, `pct`	修改翻转率
`set_resource_util`	`block`, `lut`, `ff`, `bram`, `dsp`	修改资源用量（绝对数量）
`recalculate`	无	触发功耗重算
`compare`	无	对比两次功耗快照

scenario(action="set_environment", temp=85, airflow=250, heatsink="medium")
scenario(action="set_clock_frequency", name="clk_main", freq_mhz=200)
scenario(action="set_resource_util", block="logic", lut=50000, ff=60000, bram=80, dsp=100)
scenario(action="recalculate")
scenario(action="compare")

5. `clock` — 时钟管理

action	关键参数	说明
`list`	无	列出所有时钟
`create`	`name`, `freq`, `io_type`, `io_standard`, `is_gated`, `min_freq`	创建时钟
`delete`	`name`	删除时钟
`edit`	`name`, `freq`, `io_type`, ...	编辑时钟参数
`settings`	`name`	获取时钟设置
`sample_settings`	无	获取示例设置模板
`replace`	`name`, `other`, `blocks`	替换时钟引用
`mgr_types`	无	列出时钟管理器类型
`mgr_list`	无	列出现有时钟管理器
`mgr_create`	`name`, `type`, `input_clock`, `vco_range`	创建时钟管理器
`mgr_delete`	`name`	删除时钟管理器
`mgr_settings`	`name`	获取时钟管理器设置

clock(action="create", name="clk_200", freq=200, io_type="HD")
clock(action="mgr_create", name="mmcm1", type="MMCM", input_clock="clk_200")

6. `ip` — IP 核管理

action	关键参数	说明
`types`	无	列出可用 IP 类型
`list`	`ip_type`	列出指定类型的 IP 实例
`create`	`ip_type`, `ip_name`	创建 IP
`delete`	`ip_type`, `ip_name`	删除 IP
`settings`	`ip_type`, `ip_name`	获取 IP 当前设置
`sample_settings`	`ip_type`	获取 IP 设置模板

ip(action="types")
ip(action="list", ip_type="GTH")
ip(action="create", ip_type="GTH", ip_name="gth_0")

7. `power_design` — 电源设计

action	关键参数	说明
`info`	无	电源域/电源名称概览
`rail_characteristics`	无	电源轨特性详情
`delivery_design`	无	电源交付设计汇总
`set_consolidation`	`mode`	设置电源轨整合模式

power_design(action="info")
power_design(action="rail_characteristics")
power_design(action="set_consolidation", mode="Consolidated")

8. `vivado` — Vivado 数据导入

action	关键参数	说明
`import_report`	`report_path`, `label`	导入 Vivado 功耗报告
`compare`	`label`	与 PDM 结果逐项对比
`import_utilization`	`util_report_path`, `block_name`	导入利用率报告

vivado(action="import_report", report_path="post_route_power.rpt")
vivado(action="compare", label="vivado_import")
vivado(action="import_utilization", util_report_path="utilization.rpt")

9. `estimate` — 快速估算（无需 PDM 会话）

action	关键参数	说明
`quick`	`part`, `clock_mhz`, `lut_pct`, ...	快速功耗估算 (±40%)
`recommend`	`budget`, `logic_cells`, `family`	根据预算推荐器件
`families`	无	列出支持的 FPGA 系列

estimate(action="quick", part="xc7a100tcsg324-1", clock_mhz=200, lut_pct=60)
estimate(action="recommend", budget=3.0, logic_cells=50000, family="7series")
estimate(action="families")

10. `explore` — 属性探索

action	关键参数	说明
`block_resources`	`block`	列出 Block 的资源名
`block_summaries`	`block`	列出 Block 的汇总表名
`resource_info`	`block`, `resource`	获取资源字段名/记录名
`resource_defaults`	`block`, `resource`	获取资源默认值
`resource_valid_values`	`block`, `resource`, `fields`	获取字段有效值范围
`summary_info`	`target`, `summary`	获取汇总表详情
`list_property`	`target`	列出对象属性名
`report_property`	`target`, `pattern`, `all_props`, `detail`	报告对象属性
`reset_property`	`target`, `prop`	重置属性为默认值

explore(action="block_resources", block="logic")
explore(action="resource_defaults", block="logic", resource="logic_config")
explore(action="report_property", target="project", pattern="*", all_props=True)

使用模板

以下是常见场景的操作模板。直接将这些指令告诉 AI Agent 即可。

模板 A：设计前期最大功耗快速评估（无 PDM 项目）

器件尚未确定，需要快速估算最坏情况功耗，给出电源设计余量。

1. 调用 estimate(action="families")，了解有哪些 FPGA 系列可选。
2. 用 estimate(action="quick") 做粗估。关键参数：
   - part: 候选器件，如 "xc7a100tcsg324-1"
   - clock_mhz: 主时钟频率
   - lut_pct / ff_pct / bram_pct / dsp_pct: 设为预期的最大值（如 80-90）
   - io_count / io_standard / io_toggle: IO 数量和翻转率
   - temp / airflow / heatsink: 环境条件
3. 多选几个候选器件重复 quick 估算，比较结温。
4. 用 estimate(action="recommend")，传入功耗预算和资源需求，验证选型。
5. 电源余量建议：总功耗 × 1.3 ~ 1.5 作为电源设计目标。

示例对话：

用户: 我在设计一个 200MHz 主频、占用约 70% LUT 的逻辑，用 xc7a100t，
      想知道最大功耗大概多少，电源要留多少余量。
      (AI 自动调用 estimate quick → 返回总功耗和结温 → 建议余量)

模板 B：精确功耗评估（基于 PDM 项目）

已有 RTL / Vivado 工程，需要精确评估并导出约束到 PCB 设计。

1. session(action="start")
2. project(action="create", name="my_design", part="xc7a100tcsg324-1")
3. 用 explore(action="block_resources", block="logic") 查看可用资源字段。
4. 用 scenario(action="set_resource_util") 填入综合后的 LUT/FF/BRAM/DSP 用量（绝对数量）。
   例如 ``lut=50000, ff=60000, bram=80, dsp=100``。
5. 用 clock(action="create") 创建设计中的时钟，或 scenario(action="set_clock_frequency")
   修改已有时钟。
6. 用 scenario(action="set_environment", temp=85, airflow=250, heatsink="medium")
   设置工作环境。
7. scenario(action="recalculate") 重算功耗。
8. power(action="summary") 查看总功耗，power(action="thermal") 检查结温是否超标。
9. 如结温过高，调整 airflow 或 heatsink，重复步骤 7-8。
10. project(action="export_xdc", file="thermal.xdc") 导出散热约束。
11. power_design(action="rail_characteristics") 查看电源轨特性，确定每路电源需求。
12. project(action="save")
13. session(action="stop")

模板 C：导入 Vivado 结果并验证

综合/布线已完成，导入 Vivado 报告验证 PDM 建模精度。

1. session(action="start")
2. project(action="open", path="my_design.pdm")
3. vivado(action="import_report", report_path="post_route_power.rpt")
4. vivado(action="import_utilization", util_report_path="utilization.rpt", block_name="logic")
5. scenario(action="recalculate")
6. vivado(action="compare")  → 总功耗和各项逐项对比，>10% 差异标记 WARN。
7. 根据差异调整 PDM 参数（调用 scenario / clock），重复步骤 5-6。
8. project(action="save")
9. session(action="stop")

模板 D：多场景功耗对比

同一设计在不同频率、温度下的功耗差异。

1. session(action="start")
2. project(action="open", path="my_design.pdm")
3. power(action="summary")                         → 保存快照 A（基准）
4. scenario(action="set_clock_frequency", 
            name="clk_main", freq_mhz=300)         → 调整频率
5. scenario(action="recalculate")
6. power(action="summary")                         → 保存快照 B
7. scenario(action="compare")                      → 对比 A vs B
8. scenario(action="set_environment", 
            temp=85, airflow=0, heatsink="none")   → 调整环境
9. scenario(action="recalculate")
10. power(action="summary")                        → 保存快照 C
11. scenario(action="compare")                     → 对比 B vs C
12. session(action="stop")

模板 E：器件选型与 Part 替换

当前器件功耗超标，需要更换器件并重新评估。

1. session(action="start")
2. project(action="open", path="my_design.pdm")
3. project(action="list_parts", architecture="Artix-7")  → 查看同架构备选器件
4. power(action="summary")                                → 当前功耗
5. project(action="select_part", part="xc7a200tfbg484-2") → 换更大器件
6. scenario(action="recalculate")
7. power(action="summary")                                → 验证新器件功耗和结温
8. 若不满意，重复步骤 5-7。
9. project(action="save", save_path="my_design_a200t.pdm")
10. session(action="stop")

模板 F：时钟系统规划

从零配置复杂时钟网络（含 MMCM/DPLL）。

1. session(action="start")
2. project(action="create", name="clock_design", part="xcku3p-ffva676-1-i")
3. clock(action="sample_settings")                           → 了解时钟设置模板结构
4. clock(action="create", name="sys_clk", freq=125, 
         io_type="HD", io_standard="LVCMOS 1.8V")            → 创建系统时钟
5. clock(action="mgr_types")                                 → 查看可用的时钟管理器
6. clock(action="mgr_create", name="mmcm_sys",
         type="MMCM", input_clock="sys_clk", vco_range="Low") → 创建 MMCM
7. clock(action="mgr_settings", name="mmcm_sys")             → 查看 MMCM 产生的输出时钟
8. scenario(action="recalculate")
9. project(action="save")
10. session(action="stop")

模板 G：电源轨设计与原理图检查

导出电源设计数据，提供给硬件工程师做原理图检查。

1. session(action="start")
2. project(action="open", path="my_design.pdm")
3. scenario(action="set_environment", temp=85,
            airflow=250, heatsink="medium")
4. scenario(action="recalculate")
5. power_design(action="info")                               → 查看电源域和电源名称
6. power_design(action="rail_characteristics")               → 查看每路电压/电流
7. power_design(action="delivery_design")                    → 查看电源交付方案
8. power_design(action="set_consolidation", 
               mode="Consolidated")                          → 尝试整合模式
9. power_design(action="delivery_design")                    → 对比整合后的方案
10. project(action="export_power_design", 
            file="power_design.xml")                         → 导出 XML 供原理图检查
11. project(action="export_xdc", file="thermal.xdc",
            thermal="Ambient")                               → 导出环境温度约束
12. project(action="save")
13. session(action="stop")

模板 H：导入 XPE 快速起步

已有 Vivado XPE 文件，直接导入作为起点。

1. session(action="start")
2. project(action="create", name="from_xpe", part="xc7a100tcsg324-1")
3. project(action="import_xpe", file="baseline.xpe")          → 导入 XPE 数据
4. power(action="summary")                                    → 查看导入后的功耗
5. explore(action="block_resources", block="logic")           → 查看 XPE 填充了哪些资源
6. scenario(action="set_environment", temp=85, airflow=250,
            heatsink="medium")
7. scenario(action="recalculate")
8. power(action="summary")
9. project(action="save")
10. session(action="stop")

模板 I：同设计跨器件功耗对比（基于 PDM）

同一套设计参数（资源、时钟、环境），在不同 FPGA 型号上的功耗和结温差异。

1. session(action="start")
2. project(action="open", path="my_design.pdm")

   # ---- 器件 A ----
3. scenario(action="set_resource_util", block="logic",
            lut=50000, ff=60000, bram=80, dsp=100)
4. clock(action="create", name="clk_main", freq=200)
5. scenario(action="set_environment", temp=85, airflow=250, heatsink="medium")
6. scenario(action="recalculate")
7. power(action="summary")                                → 保存快照（器件 A）

   # ---- 器件 B ----
8. project(action="select_part", part="xc7a200tfbg484-2") → 切换到更大器件
9. scenario(action="recalculate")
10. power(action="summary")                               → 保存快照（器件 B）
11. scenario(action="compare")                            → 对比 A vs B

    # ---- 器件 C ----
12. project(action="select_part", part="xcku3p-ffva676-1-i") → 切换到 UltraScale
13. scenario(action="recalculate")
14. power(action="summary")                               → 保存快照（器件 C）
15. scenario(action="compare")                            → 对比 B vs C

16. session(action="stop")

说明：compare 对比的是最近两次 power(summary) 的快照。三器件以上需两两依次对比，每次 compare 后记录输出即可。

模板 J：纯快速估算跨器件对比（无需 PDM）

连 PDM 项目都不需要，直接用 estimate quick 快速比较多个器件。

1. estimate(action="quick", part="xc7a35tcsg324-1", clock_mhz=200,
            lut_pct=70, temp=85, airflow=250, heatsink="medium")
   → 记录: A35T → 功耗 X.XW, 结温 YY°C

2. estimate(action="quick", part="xc7a100tcsg324-1", clock_mhz=200,
            lut_pct=70, temp=85, airflow=250, heatsink="medium")
   → 记录: A100T → 功耗 X.XW, 结温 YY°C

3. estimate(action="quick", part="xc7a200tfbg484-2", clock_mhz=200,
            lut_pct=70, temp=85, airflow=250, heatsink="medium")
   → 记录: A200T → 功耗 X.XW, 结温 YY°C

4. estimate(action="quick", part="xcku3p-ffva676-1-i", clock_mhz=200,
            lut_pct=70, temp=85, airflow=250, heatsink="medium")
   → 记录: KU3P → 功耗 X.XW, 结温 YY°C

5. 横向比较四个器件的总功耗和结温，选择最优性价比型号。

11. `guide` — 引导式评估向导

只需告诉 AI "我想评估 xxx 的功耗"，AI 会调用本工具一步步询问所需参数，每步给出可选值，无需记忆任何工具名。

流程：器件型号 → 评估模式（quick/pdm/vivado） → 逐步填参 → 自动计算结果。

# 用户: "我想评估 xc7a100t 的功耗"
# AI 自动调用:
guide(step="start")
# → 返回: "请输入 FPGA 器件型号"
guide(step="device", value="xc7a100tcsg324-1")
# → 返回: "选择评估模式: quick / pdm / vivado"
guide(step="mode", value="quick", device="xc7a100tcsg324-1")
# → 返回: "主时钟频率是多少 (MHz)？"
guide(step="quick_clock_mhz", value="200", device="xc7a100tcsg324-1")
# → 返回: "LUT 利用率大约多少 (%)？"
# ... 逐步收集参数 ...
# → 最终返回: 功耗估算结果（含 breakdown、结温）

示例对话：

用户: 我想评估 xc7a100t 的功耗，200MHz 主频，资源用了大概 70%
AI:   (自动调用 guide → 收集参数 → 返回总功耗 1.2W，结温 45°C，建议电源余量 1.8W)

开发

运行测试

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

项目结构

pdm_mcp/
├── src/pdm_mcp/
│   ├── __main__.py           # CLI 入口 (pdm-mcp serve)
│   ├── server.py             # FastMCP 实例 + 工具注册
│   ├── config.py             # PDM 路径检测
│   ├── analysis/
│   │   ├── estimator.py      # 快速功耗估算模型
│   │   └── power_parser.py   # Vivado 报告解析器
│   ├── session/
│   │   ├── pdm_session.py    # PDM 子进程管理（哨兵协议）
│   │   ├── session_manager.py # 多会话生命周期
│   │   └── base_session.py   # 抽象基类 + PdmResult
│   └── tools/                # 10 个 MCP 工具
│       ├── session_tools.py
│       ├── project_tools.py
│       ├── power_tools.py
│       ├── scenario_tools.py
│       ├── clock_tools.py
│       ├── ip_tools.py
│       ├── power_design_tools.py
│       ├── import_tools.py
│       ├── estimate_tools.py
│       └── exploration_tools.py
├── scripts/mainloop.py       # PDM 子进程 REPL
├── tests/                    # 测试
├── docs/                     # UG1781 参考文档
└── pyproject.toml

Bug 反馈

请通过以下任一方式提交反馈：

GitHub Issues: 在项目仓库提交 Issue，附上以下信息：
- pdm-mcp version 输出
- 完整的错误信息 / 堆栈跟踪
- 复现步骤
- PDM 版本 (pdm.bat 所在目录名即为版本号)
日志: 启动 MCP Server 时会输出日志到 stderr，包含 PDM 路径检测信息和运行时错误。如果遇到问题，请附上日志。

常见问题排查:

问题	可能原因	解决方法
`PDM 路径检测失败`	PDM 未安装或路径不在默认位置	设置 `PDM_HOME` 或创建 `path.txt`
`会话 'xxx' 不存在`	未调用 `session(action="start")`	先启动会话再操作
`No project open`	未调用 `project(action="open")`	先打开项目再查询
功耗值为 0	未设置资源利用率或时钟频率	调用 `scenario` 配置参数后 `recalculate`

Available Tools

11 tools

clockA

统一时钟管理工具 — 通过 action 参数选择操作。

Clock 操作： list — 列出所有时钟 create — 创建时钟 (name, freq, io_type, io_standard, is_gated, min_freq) delete — 删除时钟 (name) edit — 编辑时钟 (name, freq, io_type, io_standard, is_gated, min_freq) settings — 获取时钟设置 (name) sample_settings — 获取时钟示例设置模板 replace — 替换时钟 (name, other, blocks)

Clock Manager 操作： mgr_types — 列出可用时钟管理器类型 mgr_list — 列出所有时钟管理器 mgr_create — 创建时钟管理器 (name, type, input_clock, vco_range) mgr_delete — 删除时钟管理器 (name) mgr_settings — 获取时钟管理器设置 (name)

Args: action: 操作类型，见上。 name: 时钟/管理器名称。 freq: 时钟频率 (MHz)。 io_type: IO 类型，如 "HD"、"HP"。 io_standard: IO 标准，如 "LVCMOS 1.8V"、"LVDS"。 is_gated: 是否为门控时钟 (create: bool; edit: "true"/"false"/"")。 min_freq: 最低缩放频率 (MHz)，0 表示无。 other: replace 时的目标时钟名称。 blocks: replace 时限定作用的 Block 列表，逗号分隔。 type: 管理器类型，如 "MMCM"、"DPLL"、"XPLL"。 input_clock: 管理器输入时钟名称。 vco_range: VCO 范围，"Low" 或 "High"。 session_id: 目标会话 ID。

ParametersJSON Schema

Name	Required	Default
`freq`	No
`name`	No
`type`	No
`other`	No
`action`	Yes
`blocks`	No
`io_type`	No
`is_gated`	No
`min_freq`	No
`vco_range`	No	Low
`session_id`	No	default
`input_clock`	No
`io_standard`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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 the operations and parameters but does not mention side effects, authorization needs, rate limits, or behavioral traits beyond the listed actions.

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

Conciseness4/5

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

The description is well-structured with clear sections for clock and clock manager operations, and front-loads the purpose. It is slightly verbose but organized for readability.

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

Completeness4/5

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

Given the high complexity (13 parameters, many actions) and presence of an output schema, the description is fairly complete. It covers all actions and parameters, though it lacks explanation of default values, error handling, or operation ordering.

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

Parameters4/5

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

With schema description coverage at 0%, the description compensates by explaining each parameter in the context of actions (e.g., 'freq: 时钟频率 (MHz)'). This adds significant meaning beyond schema titles. However, some parameters like 'session_id' are only listed in the args section without per-action context.

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

Purpose5/5

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

The description clearly identifies the tool as a unified clock management tool ('统一时钟管理工具') and enumerates all specific operations (list, create, delete, edit, etc.) for both clocks and clock managers. This distinguishes it from siblings like 'session' or 'power_design'.

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

Usage Guidelines3/5

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

The description lists actions and their parameters, implying usage for clock management tasks. However, it lacks explicit guidance on when to use this tool versus alternatives, and does not provide exclusion criteria or prerequisites.

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

estimateA

快速功耗估算 / Part 推荐 / 系列列表——无需 PDM 会话。

action 决定操作：

"quick": 快速功耗估算，基于 XPE 公开系数 + 线性模型，秒级返回。精度约 ±40%。
"recommend": 根据功耗预算和资源需求推荐合适的 Part 型号。
"families": 列出支持快速估算的 FPGA 系列及典型参数。

quick 参数: part: FPGA 器件型号，如 "xc7a100tcsg324-1"。 clock_mhz: 主时钟频率 (MHz)。 lut_pct: LUT 利用率百分比 (0-100)。 ff_pct: FF 利用率百分比 (0-100)。 bram_pct: BRAM 利用率百分比 (0-100)。 dsp_pct: DSP 利用率百分比 (0-100)。 io_count: IO 引脚数量。 io_standard: IO 标准，如 "LVCMOS33"、"LVDS"、"SSTL15"。 io_toggle: IO 翻转率百分比 (0-100)，默认 12.5。 gt_count: GT 高速收发器数量。 gt_rate: GT 线速率 (Gbps)。 temp: 环境温度 (°C)，默认 25。 airflow: 风流量 (LFM)，默认 250。 heatsink: 散热器类型 (none/small/medium/large)，默认 medium。

recommend 参数: budget: 总功耗预算 (W)。 logic_cells: 需要的逻辑单元数。 bram_kb: 需要的 BRAM (Kb)。 dsp_slices: 需要的 DSP Slice 数。 io_count: 需要的 IO 引脚数。 gt_count: 需要的 GT 收发器数。 family: 限定系列，如 "7series"、"ultrascale"。 max_count: 最多返回结果数，默认 5。

ParametersJSON Schema

Name	Required	Default
`part`	No
`temp`	No
`action`	Yes
`budget`	No
`family`	No
`ff_pct`	No
`airflow`	No
`bram_kb`	No
`dsp_pct`	No
`gt_rate`	No
`lut_pct`	No
`bram_pct`	No
`gt_count`	No
`heatsink`	No	medium
`io_count`	No
`clock_mhz`	No
`io_toggle`	No
`max_count`	No
`dsp_slices`	No
`io_standard`	No	LVCMOS33
`logic_cells`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It discloses that quick estimation is based on a linear model, returns in seconds, and has ±40% accuracy. It also provides default values for parameters. However, it does not mention error conditions, idempotency, or permission requirements.

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

Conciseness4/5

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

The description is well-structured with a summary line, action sections, and parameter lists. It is front-loaded with the main purpose. However, it is lengthy due to detailed parameter explanations; some default values are redundant with the schema, but overall efficient.

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

Completeness4/5

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

Given the complexity of the tool (21 parameters, three modes) and the presence of an output schema, the description is fairly complete. It covers all actions and parameters, though it could mention how the output varies by action or handle error scenarios.

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

Parameters5/5

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

The schema description coverage is 0%, yet the description comprehensively explains every parameter for 'quick' and 'recommend' actions, including units, defaults, and value ranges (e.g., lut_pct 0-100). This fully compensates for the lack of schema descriptions.

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

Purpose5/5

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

The description clearly states the tool does three distinct operations: quick power estimation, part recommendation, and listing families. It uses specific verbs and resource targets, and although it doesn't explicitly differentiate from siblings, the action-based design implies distinct use cases.

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

Usage Guidelines4/5

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

The description provides clear context for each action, such as when to use 'quick' (rough estimation) vs 'recommend' (part selection). However, it lacks explicit guidance on when not to use this tool or alternatives among sibling tools like 'power' or 'explore'.

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

exploreA

统一探索入口，通过 action 参数选择子功能。

Actions: block_resources(block) 列出指定 Block 的资源名称。 block_summaries(block) 列出指定 Block 的汇总表名称。 resource_info(block, resource) 获取 Block 资源的字段名和记录名。 resource_defaults(block, resource) 获取 Block 资源的默认值。 resource_valid_values(block, resource, fields) 获取 Block 资源字段的有效值范围。fields 逗号分隔，留空获取所有。 summary_info(target, summary) 获取汇总表的字段名、记录名和当前值。target 为 "project" 或 block 名。 list_property(target) 列出 PDM 对象的属性名。target 为 "project" / block名 / "block.resource"。 report_property(target, pattern, all_props, detail) 报告 PDM 对象的属性。pattern 支持通配符和正则。 reset_property(target, prop) 重置 PDM 对象的属性为默认值。

Args: action: 操作名（见上方列表）。 block: Block 名称（block_* / resource_* 操作使用）。 resource: 资源名称（resource_* 操作使用）。 fields: 字段名，逗号分隔（resource_valid_values 使用）。 summary: 汇总表名称（summary_info 使用）。 target: 目标对象，"project" / block名 / "block.resource"。 pattern: 属性名匹配模式（report_property 使用）。 all_props: 是否报告所有属性（report_property 使用）。 detail: 是否报告详细帮助信息（report_property 使用）。 prop: 要重置的属性名（reset_property 使用）。 session_id: 目标会话 ID。

ParametersJSON Schema

Name	Required	Default
`prop`	No
`block`	No
`action`	Yes
`detail`	No
`fields`	No
`target`	No	project
`pattern`	No	*
`summary`	No
`resource`	No
`all_props`	No
`session_id`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It details each action's behavior and parameters, though it does not cover side effects, auth requirements, or rate limits. Still, it provides adequate transparency for an exploration tool.

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

Conciseness4/5

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

The description is well-structured with a clear intro and a bullet-style list of actions. It is longer but each sentence adds value. Could be slightly more concise, but overall efficient.

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

Completeness5/5

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

Given the complexity (11 parameters, multiple actions), the description is comprehensive. It covers all actions and parameters clearly. An output schema exists, so return values are not needed.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose in the context of each action. For example, block is used in block_* actions, resource in resource_* actions, and fields valid values.

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

Purpose5/5

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

The description clearly states it is a unified exploration entry point with sub-functions selected by action parameter. Each action is explicitly listed with its purpose, distinguishing it from sibling tools that have different functionalities.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use each action through the action list. It does not include when-not-to-use or alternatives, but the context is clear enough for an agent to select the correct action.

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

guideA

引导式功耗评估向导——逐步收集参数，给出选项，无需记忆工具名和参数。

每次调用返回下一步应该问用户什么问题，以及可选的选项列表。 AI Agent 负责向用户展示问题并收集回答，然后将回答作为 value 传入下一步。

典型流程::

guide(step="start")                                    → 询问器件型号
guide(step="device", device="xc7a100tcsg324-1")       → 询问评估模式
guide(step="mode", value="quick")                     → 询问时钟频率
guide(step="quick_clock", value="200")                → 询问 LUT 利用率
...                                                   → 逐步收集参数
guide(step="quick_heatsink", value="medium")          → 返回估算结果

Args: step: 当前步骤名。首次调用用 "start"。 value: 用户对当前步骤的回答。数字/字符串均可。 device: 器件型号（仅 step="device" 时需要）。

ParametersJSON Schema

Name	Required	Default
`step`	No	start
`value`	No
`device`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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 the step-by-step behavior, the interaction pattern, and the return of a next question with options. It also explains parameter roles. It does not cover destructive side effects, but that seems irrelevant for a wizard.

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

Conciseness5/5

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

The description is well-structured: a concise definition, interaction explanation, a detailed but not bloated example flow, and parameter details. Every sentence adds value, and the most important information (purpose and usage pattern) appears first.

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

Completeness4/5

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

Given the wizard's complexity and 0% schema coverage, the description is quite complete. It covers the flow, parameter roles, and return of a question. An output schema exists, so return value details are likely covered elsewhere. Minor omission: no mention of error handling or final result format, but overall adequate.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates fully. It explains each parameter: 'step' for current step, 'value' for user answer, 'device' only needed at the device step. Example calls illustrate usage. This adds deep semantic context beyond the bare schema.

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

Purpose5/5

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

The description clearly defines the tool as a guided power estimation wizard that collects parameters step by step. It uses the verb '引导式功耗评估向导' and distinguishes itself from siblings by its interactive step-by-step nature. The example flow further clarifies its purpose.

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

Usage Guidelines4/5

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

The description explicitly states that each call returns the next question for the user and that the AI agent must present questions and collect answers. It provides a typical flow and parameter explanations. However, it does not explicitly mention when not to use this tool or compare it to alternatives like 'estimate' or 'power'.

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

ipA

综合 IP 管理工具。

Args: action: 操作类型。 - "types": 列出可用的 IP 类型。 - "list": 列出指定类型的 IP 实例（需 ip_type）。 - "create": 创建 IP 实例（需 ip_type + ip_name）。 - "delete": 删除 IP 实例（需 ip_type + ip_name）。 - "settings": 获取 IP 实例的当前设置（需 ip_type + ip_name）。 - "sample_settings": 获取 IP 类型的示例设置模板（需 ip_type）。 ip_type: IP 类型，如 "MIG"、"PCIE"、"GTH"。 ip_name: IP 实例名称。 session_id: 目标会话 ID。

ParametersJSON Schema

Name	Required	Default
`action`	Yes
`ip_name`	No
`ip_type`	No
`session_id`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions destructive actions like 'delete' without any warning about irreversibility or required permissions. For a management tool with create/delete capabilities, 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.

Conciseness5/5

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

The description is brief yet complete, structured as a bullet list under 'Args:'. Every sentence serves a purpose: the opening line states the tool's scope, and the list enumerates actions concisely. No redundant information.

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

Completeness4/5

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

Given that an output schema exists, return values are not needed. The description covers all actions and parameter dependencies. However, it does not address error handling, default values (e.g., session_id defaults to 'default' but not mentioned), or the fact that some required parameters per action are not marked as required in the schema.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must and does fully compensate. It explicitly lists each action value with its required parameters (e.g., 'create: 创建 IP 实例（需 ip_type + ip_name）') and provides example values for ip_type. This adds crucial meaning beyond the bare schema.

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

Purpose5/5

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

The description clearly states '综合 IP 管理工具' (comprehensive IP management tool) and lists six distinct actions (types, list, create, delete, settings, sample_settings) with specific verbs and resources. This specificity distinguishes it from sibling tools like session, power_design, or vivado, which focus on other subsystems.

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

Usage Guidelines3/5

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

The description outlines each action's required parameters, implicitly guiding when to use each action (e.g., create requires ip_type+ip_name). However, it does not explicitly state when to use this tool versus alternatives, nor does it provide 'when not to use' guidance.

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

powerA

统一的功耗查询/导出工具。

通过 action 参数选择子功能：

summary: 项目总功耗摘要（静态/动态/结温）。每次调用自动保存快照。
block_power: 某个 Block 的详细功耗分解（需 block_name）。
rails: 各电源轨的电压、电流、功耗。
thermal: 热分析结果（结温、环境温度、θ-JA 等）。
clock_power: 各时钟域的功耗分布。
export_report: 导出功耗报告为文本或 CSV 文件（需 output_path）。

Args: action: 操作类型：summary / block_power / rails / thermal / clock_power / export_report。 block_name: block_power 操作的 Block 名称。 output_path: export_report 操作的输出文件路径。 format: export_report 操作的输出格式，"text" 或 "csv"。 session_id: 目标会话 ID。

ParametersJSON Schema

Name	Required	Default
`action`	Yes
`format`	No	text
`block_name`	No
`session_id`	No	default
`output_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Discloses one behavioral trait: summary automatically saves snapshots per call. However, with no annotations provided, the description could better indicate side effects, auth needs, or whether operations are read-only. Lacks comprehensive transparency.

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

Conciseness4/5

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

Well-organized with a lead sentence, bullet list of subfunctions, and an args section. Every sentence earns its place, though slightly verbose; could be tightened slightly without losing clarity.

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

Completeness5/5

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

Given the tool's complexity (5 parameters, multiple modes) and the presence of an output schema (unshown), the description covers all subfunctions and parameters sufficiently, leaving no gaps in understanding.

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

Parameters5/5

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

Schema descriptions coverage is 0%, yet the description explains each parameter's role (action, block_name, output_path, format, session_id) and defaults, adding crucial meaning beyond the schema.

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

Purpose5/5

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

Description clearly states the tool is for unified power query/export, listing all subfunctions (summary, block_power, rails, thermal, clock_power, export_report) with brief explanations, making purpose highly specific and distinguishable from siblings.

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

Usage Guidelines3/5

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

Provides context for each action and its required parameters (e.g., block_name for block_power), but does not explicitly mention when to use this tool over alternatives like power_design or estimate, nor does it state when not to use.

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

power_designB

Power Design 综合工具：信息查询、电源轨特性、电源传输设计、合并模式设置。

Args: action: 操作类型。 - "info": 获取 Power Design 概览（域、电源、汇总类型、合并模式）。 - "rail_characteristics": 获取 power_rail_characteristics 汇总表。 - "delivery_design": 获取 power_delivery_design 汇总表。 - "set_consolidation": 设置电源轨合并模式（需配合 mode 参数）。 mode: 合并模式，仅在 action="set_consolidation" 时使用。 session_id: 目标会话 ID。

ParametersJSON Schema

Name	Required	Default
`mode`	No
`action`	Yes
`session_id`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions that set_consolidation requires the mode parameter, but it does not describe side effects, authentication needs, rate limits, or what happens if the action is invalid.

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

Conciseness4/5

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

The description is reasonably concise, with a clear front-loaded summary followed by parameter details. It could be slightly more structured, but it effectively communicates the essential information.

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

Completeness3/5

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

The tool has an output schema but the description does not mention return values. It covers the four actions and parameter dependencies, but it does not address prerequisites like session existence or error behavior, leaving some gaps.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It explains the purpose of each action and specifies that mode is only used for set_consolidation, and session_id is the target session ID. However, it does not detail allowed values or formats for mode.

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

Purpose4/5

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

The description clearly states the tool is a comprehensive tool for power design, listing four specific actions (info, rail_characteristics, delivery_design, set_consolidation) that define its purpose. It is distinct from siblings like 'power' which likely focuses on a single aspect.

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

Usage Guidelines3/5

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

The description provides usage context by detailing each action and its purpose, but it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

projectC

统一的 PDM 项目操作入口。

Actions: open(path) — 打开 .pdm 项目文件 create(name, part, output_dir) — 创建新的 PDM 项目 close — 关闭当前项目 save(save_path) — 保存项目（可选另存为路径） info — 获取项目基本信息 list_blocks — 列出所有 Block list_architectures — 列出可用 FPGA 器件架构 list_parts(arch, package) — 按架构/封装筛选 Part 型号 list_processes — 列出可用的工艺角类型 select_part(part, process) — 更换 FPGA 器件型号 import_xpe(file, append) — 导入 XPE 文件 export_xdc(file, thermal, rails, overwrite) — 导出功耗约束为 XDC export_power_design(file, overwrite) — 导出 Power Design 为 XML reset — 重置项目（清除所有数据）

Args: action: 操作名称（见上方列表）。 session_id: 目标会话 ID。

ParametersJSON Schema

Name	Required	Default
`file`	No
`name`	No
`part`	No
`path`	No
`rails`	No
`action`	Yes
`append`	No
`process`	No
`thermal`	No	Junction
`overwrite`	No
`save_path`	No
`output_dir`	No
`session_id`	No	default
`architecture`	No
`package_filter`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It mentions actions and their effects only briefly (e.g., 'reset' clears all data), but lacks details on side effects, permissions, or error behavior.

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

Conciseness3/5

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

The description is structured as a list of actions and arguments, but is somewhat lengthy. The overall purpose is stated upfront, but some redundancy exists.

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

Completeness2/5

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

Given 15 parameters and no schema descriptions, the description leaves many gaps. It does not explain return values or error handling, and the output schema is not leveraged.

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

Parameters3/5

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

With 0% schema description coverage, the description provides inline parameter hints per action (e.g., open(path), create(name, part, output_dir)), partially compensating. However, not all schema parameters are linked to actions.

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

Purpose4/5

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

The description clearly states it is a unified PDM project operation entry and lists all supported actions. It distinguishes itself from sibling tools by being the central project operations hub.

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

Usage Guidelines2/5

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

The description lists actions but provides no guidance on when to use this tool versus alternatives like 'power_design' or 'estimate'. No decision criteria or exclusions are mentioned.

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

scenarioA

统一的场景管理入口——通过 action 参数选择操作。

Actions:

"set_environment" — 设置环境参数（温度、风流量、散热器）。需要 temp，可选 airflow（默认 250）、heatsink（默认 medium）。
"set_clock_frequency" — 修改某个时钟的频率。需要 name、freq_mhz。
"set_toggle_rate" — 修改某个 Block 的信号翻转率。需要 block、pct（0–100）。
"set_resource_util" — 修改某个 Block 的资源用量（绝对数量）。需要 block，可选 lut / ff / bram / dsp （-1 表示不修改对应项）。填入实际使用的资源数，如 lut=50000 表示已用 50000 个 LUT。
"recalculate" — 参数修改后重新计算功耗。
"compare" — 对比最近两次功耗快照（依赖 power(action="summary") 保存的快照），
10% 差异标记 WARN。

Args: action: 操作类型（见上）。 session_id: 目标会话 ID。 temp: 环境温度 (°C)（set_environment）。 airflow: 风流量 LFM（set_environment，默认 250）。 heatsink: 散热器类型 none/small/medium/large（set_environment，默认 medium）。 name: 时钟名称（set_clock_frequency）。 freq_mhz: 新频率 MHz（set_clock_frequency）。 block: Block 名称（set_toggle_rate / set_resource_util）。 pct: 翻转率百分比 0–100（set_toggle_rate）。 lut: 已用 LUT 数量（set_resource_util, -1 跳过）。 ff: 已用 FF 数量（set_resource_util, -1 跳过）。 bram: 已用 BRAM Tile 数量（set_resource_util, -1 跳过）。 dsp: 已用 DSP Slice 数量（set_resource_util, -1 跳过）。

ParametersJSON Schema

Name	Required	Default
`ff`	No
`dsp`	No
`lut`	No
`pct`	No
`bram`	No
`name`	No
`temp`	No
`block`	No
`action`	Yes
`airflow`	No
`freq_mhz`	No
`heatsink`	No
`session_id`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

The description discloses behavioral traits like the need to call recalculate after modifications and the dependency on power(action='summary') for compare. No annotations are provided, so the description carries full burden. It lacks details on side effects, reversibility, or rate limits.

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

Conciseness5/5

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

The description is well-structured with a clear opening, bulleted actions, and parameter lists. Every sentence serves a purpose, and it is concise given the complexity of 6 actions and 13 parameters.

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

Completeness4/5

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

For a multi-action tool with conditional parameters, the description covers all actions' inputs and notes cross-dependencies (e.g., compare requires power snapshots). It omits output schema details but that is acceptable given output schema exists. Slight miss on not describing return structure for recalculate or set operations.

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

Parameters5/5

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

With 0% schema coverage, the description fully compensates by explaining each parameter's purpose, constraints (e.g., pct 0-100, lut default -1), and per-action grouping. This adds significant meaning beyond the raw schema.

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

Purpose5/5

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

The description clearly defines the tool as a unified scenario management entry point with specific actions, each described with verb and resource. It distinguishes from sibling tools like power, estimate, and session by focusing on scenario parameter manipulation.

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

Usage Guidelines4/5

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

The description explicitly lists each action and its required/optional parameters, guiding the agent on when to use each. However, it does not provide exclusions or contrast with sibling tools for when not to use this tool.

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

sessionA

PDM 会话管理（三合一工具）。

三个 action：

"start" — 启动一个新的 PDM 会话。
"stop" — 关闭指定的 PDM 会话。
"list" — 列出所有活跃的 PDM 会话及其状态。

启动模式：

"py" (默认) — 启动 pdm -mode py -script mainloop.py 无头子进程，通过 Python API 执行所有操作。适合脚本化和 CI 场景。
"gui" — 启动 PDM GUI（暂未实现）。

每个 session_id 对应一个独立的 PDM 实例，支持多会话并行。

Args: action: 操作类型，"start" / "stop" / "list"。 session_id: 会话标识符，默认 "default"。start/stop 使用。 mode: 启动模式，"py" / "gui"，默认 "py"。仅 action="start" 使用。 pdm_path: 可选，自定义 PDM 可执行文件路径。留空则自动检测。仅 action="start" 使用。 timeout: 启动超时秒数，默认 120。仅 action="start" 使用。

ParametersJSON Schema

Name	Required	Default
`mode`	No	py
`action`	Yes
`timeout`	No
`pdm_path`	No
`session_id`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It details that 'start' launches a headless subprocess, 'stop' closes a session, and 'list' shows active sessions. It also explains modes ('py' vs 'gui' not implemented) and that each session_id corresponds to an independent instance. Could clarify if 'stop' is reversible.

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

Conciseness4/5

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

Description is well-structured with a title, bullet points for actions, and a parameter list. Front-loaded with the tool's purpose. Slightly verbose but every sentence adds value. Could be more streamlined.

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

Completeness5/5

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

Given the complexity (5 parameters, no annotations, output schema present), the description is complete: covers all actions, parameters, modes, and behavioral details. No gaps in information needed for correct usage.

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

Parameters5/5

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

Schema description coverage is 0%, so description must compensate. It thoroughly explains all five parameters: action, session_id, mode, pdm_path, timeout, including defaults and applicability conditions. Adds significant meaning beyond the bare schema.

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

Purpose5/5

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

Description clearly states 'PDM session management (three-in-one tool)' and enumerates three actions (start, stop, list) with specific verbs and resources. It distinguishes itself from sibling tools by focusing on session management.

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

Usage Guidelines4/5

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

Description explains when to use each action (start/stop/list) and mentions multi-session parallelism. However, it lacks explicit guidance on when not to use the tool or alternatives relative to siblings.

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

vivadoB

Vivado 导入与对比工具 (单一入口)。

action: "import_report" — 导入 Vivado report_power 输出文件进行对比分析。参数: report_path (必需), label (可选, 默认 "vivado_import")。解析文件后缓存，供 compare 使用。 "compare" — 将导入的 Vivado 功耗数据与当前 PDM 结果逐项对比。差异 >10% 标记 [WARN]。参数: label (可选, 默认 "vivado_import")。 "import_utilization" — 从 Vivado 利用率报告自动填充 PDM Block 的资源参数。参数: util_report_path (必需), block_name (可选)。

Args: action: 操作类型: "import_report" / "compare" / "import_utilization"。 report_path: Vivado .rpt 或 .txt 文件路径 (import_report 必需)。 label: 导入标签，用于多次导入区分，默认 "vivado_import"。 util_report_path: Vivado utilization report 文件路径 (import_utilization 必需)。 block_name: Block 名称，留空则填充顶层 Block。 session_id: 目标会话 ID。

ParametersJSON Schema

Name	Required	Default
`label`	No	vivado_import
`action`	Yes
`block_name`	No
`session_id`	No	default
`report_path`	No
`util_report_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It reveals that import_report caches data for compare and that compare marks >10% differences. However, it does not disclose side effects (e.g., overwriting PDM data), error handling, authentication needs, or rate limits. The behavioral details are partial.

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

Conciseness3/5

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

The description is structured with action definitions and parameter lists, but it is verbose and mixes Chinese and English, which may reduce clarity. Some information (e.g., the first line in Chinese) is redundant. It could be more concise while maintaining completeness.

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

Completeness3/5

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

Given the tool's complexity (three actions, six parameters), the description covers basic usage but lacks details on output format, error handling, and prerequisites. The presence of an output schema reduces the need to explain return values, but the description still feels incomplete for a multi-action tool.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must add meaning. It explains report_path, label, util_report_path, and block_name with context. However, session_id is mentioned without explanation, and default values are not clarified. The description adds some value but does not fully compensate for the lack of schema descriptions.

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

Purpose4/5

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

The description clearly identifies the tool as a Vivado import and comparison tool with three specific actions (import_report, compare, import_utilization). It uses specific verbs and resources. However, it does not explicitly differentiate from sibling tools like 'estimate' or 'power_design', which could overlap in functionality.

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

Usage Guidelines3/5

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

The description implies usage contexts for each action (e.g., import_report for analysis, compare for difference detection) but lacks explicit guidance on when to use this tool vs alternatives. No exclusion criteria or prerequisites are mentioned. The description is adequate but not directive.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.1.0Jul 28, 2026
- First observedclock
- First observedestimate
- First observedexplore
- First observedguide
- First observedip
- First observedpower
- First observedpower_design
- First observedproject
- First observedscenario
- First observedsession
- First observedvivado

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation4/5

Tools are mostly distinct, but power_design and power both deal with power data, and project includes power export functions. Descriptions clarify usage, so only minor confusion possible.

Naming Consistency5/5

All tool names are single lowercase words or underscore, following a consistent noun-based pattern. No mixed conventions.

Tool Count5/5

11 tools is well-scoped for a comprehensive power design management server, covering sessions, projects, power, clocks, IP, and more without being overwhelming.

Completeness4/5

Most essential operations are covered, including project lifecycle, power analysis, scenario management, and Vivado integration. Minor gaps exist, such as no dedicated tool for block management or voltage rail settings.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

TokenOracle
com.guffeyholdings
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Finance Monitoring
2
PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113398
pAIchart MCP HubOAuth
app.paichart
MCP Hub: AI service discovery, per-user OAuth, and multi-service workflow orchestration
App Automation Cloud Platforms Data Platforms
22
AI/MCP Enablement Agency A
com.checkmycontractorquote
AI workflow/MCP implementation package planner.
Developer Tools AI & Machine Learning Agent Orchestration
1

Related MCP Servers

EDA Tools MCP Server
Developer Tools Autonomous Agents
NellyW8
F
license
A
quality
F
maintenance
A comprehensive Model Context Protocol server that connects AI assistants to Electronic Design Automation tools, enabling Verilog synthesis, simulation, ASIC design flows, and waveform analysis through natural language interaction.
Updated a year ago (2025-07-29 15:06 UTC)
6
108
-
MCP for Vivado
Developer Tools App Automation Autonomous Agents
lzw12123
F
license
C
quality
C
maintenance
An AI-centric MCP server that enables automated Xilinx Vivado workflows, including project management, synthesis, implementation, and timing analysis. It allows AI agents to drive hardware design processes while integrating directly with the official Vivado GUI for visual context.
Updated 5 months ago (2026-04-08 14:32 UTC)
15
4
-
Vivado MCP Server
Embedded system Command Line Developer Tools
coreyhahn
A
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server that enables AI assistants like Claude to directly interact with AMD/Xilinx Vivado FPGA development tools.
Updated 7 months ago (2026-02-19 12:52 UTC)
40
59
MIT
fpga-mcp
wmm246
A
license
Not graded
quality
C
maintenance
Enables AI assistants to drive Xilinx Vivado, Intel Quartus, and Anlogic TangDynasty for FPGA development, including project creation, synthesis, implementation, timing closure, and hardware programming through natural language.
Updated a month ago (2026-08-06 00:42 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Can-Y/PDM_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

PDM MCP Server

前置条件

安装

从源码安装

PDM 路径配置

MCP 客户端配置

使用

1. session — 会话管理

2. project — 项目管理

3. power — 功耗查询

4. scenario — 场景配置

5. clock — 时钟管理

6. ip — IP 核管理

7. power_design — 电源设计

8. vivado — Vivado 数据导入

9. estimate — 快速估算（无需 PDM 会话）

10. explore — 属性探索

使用模板

模板 A：设计前期最大功耗快速评估（无 PDM 项目）

模板 B：精确功耗评估（基于 PDM 项目）

模板 C：导入 Vivado 结果并验证

模板 D：多场景功耗对比

模板 E：器件选型与 Part 替换

模板 F：时钟系统规划

模板 G：电源轨设计与原理图检查

模板 H：导入 XPE 快速起步

模板 I：同设计跨器件功耗对比（基于 PDM）

模板 J：纯快速估算跨器件对比（无需 PDM）

11. guide — 引导式评估向导

开发

运行测试

项目结构

Bug 反馈

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `session` — 会话管理

2. `project` — 项目管理

3. `power` — 功耗查询

4. `scenario` — 场景配置

5. `clock` — 时钟管理

6. `ip` — IP 核管理

7. `power_design` — 电源设计

8. `vivado` — Vivado 数据导入

9. `estimate` — 快速估算（无需 PDM 会话）

10. `explore` — 属性探索

11. `guide` — 引导式评估向导