English | 简体中文
通用、SDK 无关的构建编排工具,让 AI 编程助手(Trae / Claude Desktop / Cursor / Cline 等)通过自然语言调用任意 SDK 仓库的构建脚本。
打包为 TraeCLI plugin(含 skill + slash command + MCP server),同时其 MCP server 是标准协议,任何支持 MCP 的客户端都能直接接入。也可纯命令行使用,不依赖任何 AI 工具。
Trae CLI:
trae-cli plugin marketplace add git@github.com:JannLeo/telinksdk-builder-mcp.git
trae-cli plugin install telinksdk-builder其他 MCP 客户端(Claude Desktop / Cursor / Cline): 见下方给非 Trae 工具用。
Related MCP server: dbgprobe-mcp-server
在 Trae 里打开任意 Telink SDK 仓库,对话直接说:
> /build-init # 一键扫描仓库,自动生成 builder.json
> /build b80_dongle_flash # 编译 B80 dongle flash 固件/build-init 输出(自动检测,生成配置):
检测结果:Telink eclipse-only (C-type)
构建脚本:scripts/eclipse_headless_build.py
IDE 路径:C:\TelinkIoTStudio
预设(25 个,每个对应真实 Eclipse 配置):
- 8366_dongle -> 8366_dongle_for_8373_km/8366_dongle
- b80_dongle_flash -> B80_Driver_Demo/B80_dongle_flash
- b80_dongle_otp -> B80_Driver_Demo/B80_dongle_otp
- b80b_mouse_flash_sram -> B80B_Driver_Demo/B80b_mouse_flash_sram
- lark_dongle_demo -> TC_PLATFORM_SDK_1211/Lark_Dongle_Demo
... (全覆盖,无截断)/build b80_dongle_flash 输出(真实编译,产物回传):
✓ build: success (exit=0, 42s)
copied bin: build_variants/B80_Driver_Demo_b80_dongle_flash_20260717.bin (17400 bytes)/build info 输出(查看配置):
项目:telink_8373_kmd_2.4g_mode_sdk (eclipse)
配置文件:builder.json
参数(5):IdePath / ProjectPath / BuildTarget / WorkspaceDir / OutputDir
预设(25):8366_dongle, b80_dongle_flash, ... , lark_dongle_startup_from_boot
工具链:TelinkIoTStudio.exe, 默认目标 8366_dongle_for_8373_km/8366_dongle文件 | 作用 |
| 通用构建运行器。读取项目根的 |
| MCP stdio server(零依赖,纯 Python stdlib)。暴露 4 个工具,供任意 MCP 客户端调用。内部委托给 runner。 |
|
|
任意 SDK 仓库根放一个 builder.json,声明:构建脚本路径、参数列表、预设、产物目录。
trae_build_mcp.py 被 Trae 以 stdio 方式拉起,自动发现当前工作区的 builder.json。
在 Trae 对话里说"用 rx_default 预设编译",agent 调用 build_run 工具,runner 据此生成命令并执行构建脚本,产物扫描后回传。
换仓库时只要新仓库自带 builder.json,同一份 trae_builder 工具链直接复用,无需改动。
工具 | 说明 |
| 显示当前项目的构建配置(参数、预设、产物配置、工具链)。不执行编译。 |
| 列出 |
| 执行一次构建。可传 |
| 列出已收集的构建产物(按 |
| 列出本机可用串口(Windows COMx / Linux/macOS /dev/tty*)。需 pyserial。 |
| 抓取串口输出(默认 5 秒/200 行),用于烧录后验证固件行为。端口/波特率默认取 |
| 显示 |
| 调用 Telink |
# 查看某项目的构建配置
python <BUILDER>/trae_build_runner.py --project <SDK路径> info
# 按预设编译(真实执行)
python <BUILDER>/trae_build_runner.py --project <SDK路径> build --preset rx_default
# 自定义参数 + 超时
python <BUILDER>/trae_build_runner.py --project <SDK路径> build --param Target=tx --param RomType=txrx --timeout 1200
# 仅打印命令不执行
python <BUILDER>/trae_build_runner.py --project <SDK路径> build --preset rx_default --dry-run
# 列出产物
python <BUILDER>/trae_build_runner.py --project <SDK路径> list
# 列出串口(需 pyserial)
python <BUILDER>/trae_build_runner.py --project <SDK路径> serial list
# 抓取串口输出 5 秒(端口/波特率默认取 builder.json 的 serial 段,留空自动选第一个)
python <BUILDER>/trae_build_runner.py --project <SDK路径> serial capture --port COM3 --baud 115200 --duration 5
# 烧录固件(芯片默认取 flash.default_chip;wf 不指定 --input 时自动取最新产物)
python <BUILDER>/trae_build_runner.py --project <SDK路径> flash --chip B80 --command wf --dry-run
python <BUILDER>/trae_build_runner.py --project <SDK路径> flash --chip B80 --command wf
# 读 flash 到文件 / 复位 / 擦除后写
python <BUILDER>/trae_build_runner.py --project <SDK路径> flash --chip B80 --command rf --output dump.bin --size 12k
python <BUILDER>/trae_build_runner.py --project <SDK路径> flash --chip B80 --command rst
python <BUILDER>/trae_build_runner.py --project <SDK路径> flash --chip B80 --command wf --erase --size 512k在 Trae 对话里一句话串起整个嵌入式开发流程:
> /build b80_dongle_flash # 1. 编译出 bin
> 烧录到 B80 # 2. agent 调 flash_run(wf),自动取最新 bin,烧完自动复位
> 抓 5 秒串口看看有没有 boot ok # 3. agent 调 serial_capture,读 UART 日志判断Python 3.8+
构建功能:零第三方依赖(纯 stdlib)
串口抓取:可选依赖 pyserial(pip install pyserial),未装时 serial_list/serial_capture 会给出友好提示
Eclipse headless 编译:需对应平台的 Telink IoT Studio / Eclipse CDT
在 ~/.trae/trae_cli.yaml(用户级,对所有项目生效)添加:
mcp_servers:
- name: trae_builder
type: stdio
command: python
args:
- "<BUILDER>/trae_build_mcp.py"
timeout: 30s或在项目根放 .mcp.json(项目级):
{
"mcpServers": {
"trae_builder": {
"type": "stdio",
"command": "python",
"args": ["D:\\work\\workspace\\trae_builder\\trae_build_mcp.py"],
"timeout": 30
}
}
}注册后用 trae-cli doctor 检查连接状态;在交互模式用 /mcp 查看详情和工具列表。
关于 MCP 工具的可见性:stdio MCP server 是异步加载,会话启动的
init事件里mcp_servers可能为空(此时握手尚未完成),但通常 1 秒内握手完成,工具即可被 agent 调用。若首轮 prompt 调用 MCP 工具偶发失败,重试或等待片刻即可(详见 trae-cli 文档「首轮调用 MCP 工具失败/第二轮自动恢复」)。本工具链已在tc_ble_lite_sdk-1.2.2_allinone上实测build_info与build_run均可正常返回。
/build 自定义命令除 MCP 外,还提供了 /build 自定义 prompt command(走 Bash 工具调 runner,不依赖 MCP),作为更直观的入口。
命令文件已放在 ~/.trae/commands/build.md(用户级,对所有项目生效)。在任意含 builder.json 的仓库根目录打开 Trae,输入:
/build info # 查看该仓库的构建配置(参数/预设/产物)
/build list # 列出已收集的构建产物
/build rx_default # 按预设 rx_default 编译(真实执行)
/build rx_default --dry-run # 预演,只打印命令不编译
/build build --preset rx_default --param Target=tx # 显式 build 子命令 + 覆盖参数/build 会自动用 ${workspaceFolder} 定位当前仓库,调用 trae_build_runner.py,并把结果整理后汇报。
Windows 终端注意:在
cmd.exe里用trae-cli -p "/build ..."带空格参数可能被截断;推荐在 VSCode 集成终端( PowerShell )里直接输入/build ...,或用trae-cli -p时整体加引号并在 PowerShell 下运行。
/build-init 自动生成 builder.json旧仓库没有 builder.json 时,用 /build-init 一键扫描并生成:
/build-init # 扫描当前仓库,自动生成 builder.json
/build-init --ide C:\TelinkIoTStudio # 指定 IDE 路径覆盖默认值/build-init 调用 trae_build_init.py,自动识别常见构建模式:
模式 | 识别方式 | 生成内容 |
Telink A 型(release_sdk_tool) | 找 | IDE 路径、芯片列表(B80/B80B/tc122x 等)、每芯片一个预设 |
Telink B 型(telink_ble 后处理) | 找 | 从 |
Telink C 型(纯 Eclipse 工程) | 有 | 从 |
Makefile | 找 | 解析出 target 列表,每个 target 一个预设 |
通用脚本 | 找根目录 | 基础配置 |
fallback 模板 | 以上均未命中 | 提示用户手填 |
runner / MCP server / 生成器:纯 Python stdlib,三平台通用。
C 型构建脚本:scripts/eclipse_headless_build.py(纯 Python)三平台通用;在 Windows 找 TelinkIoTStudio.exe/eclipse.exe,Linux/macOS 找 eclipse/TelinkIoTStudio。
A/B 型:Windows 下用仓库自带的 .bat(保留 Telink 多阶段编排);Linux/macOS 下生成器会自动把构建脚本切换到跨平台的 eclipse_headless_build.py,并把 IDE 启动器名去掉 .exe。
runner 自动选解释器:.py→python/python3,.sh→bash,.ps1→powershell/pwsh,.bat→cmd.exe。
依赖:仅需 Python 3.8+;Eclipse headless 编译还需对应平台的 Telink IoT Studio / Eclipse CDT。
命令文件在 ~/.trae/commands/build-init.md。也可命令行直接用:
python <BUILDER>/trae_build_init.py <仓库路径> --dry-run # 预览不写
python <BUILDER>/trae_build_init.py <仓库路径> # 写入 builder.json
python <BUILDER>/trae_build_init.py <仓库路径> --ide C:\TelinkIoTStudio生成后即可 /build info 查看、/build <预设名> 编译。若是 fallback 模板,按提示编辑 builder.json 补全 build.script.path 即可。
也可手写 builder.json,参考 trae_builder_schema.json 或现有 tc_ble_lite_sdk-1.2.2_allinone/robin_builder.json。最小示例:
{
"schema_version": "1.0",
"sdk": { "name": "my-sdk", "type": "make" },
"build": {
"script": { "path": "build.ps1", "interpreter": "powershell.exe" },
"parameters": [
{ "name": "Target", "type": "enum", "enum": ["debug","release"], "default": "release" }
],
"presets": [
{ "name": "dbg", "params": { "Target": "debug" } }
],
"artifacts": { "scan_dirs": ["build"], "name_pattern": "*.bin", "max_age_hours": 168 },
"timeout_seconds": 600
}
}本仓库的 MCP server(trae_build_mcp.py)是标准 MCP stdio 协议,不依赖 Trae。任何支持 MCP 的客户端都能接入,同样获得 build_info / build_presets / build_run / build_list 四个工具。
先 clone 仓库(或下载),记下路径(下面用 <BUILDER> 代指 clone 后的 telinkbuildskill 目录)。
编辑配置文件:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"trae_builder": {
"command": "python",
"args": ["<BUILDER>/trae_build_mcp.py"]
}
}
}重启 Claude Desktop,对话框会出现 build_info 等工具。
在项目根创建 .cursor/mcp.json:
{
"mcpServers": {
"trae_builder": {
"command": "python",
"args": ["<BUILDER>/trae_build_mcp.py"]
}
}
}以 Cline 为例,在其 MCP 设置(通常 ~/.cline/mcp_settings.json 或扩展设置)加:
{
"mcpServers": {
"trae_builder": {
"command": "python",
"args": ["<BUILDER>/trae_build_mcp.py"]
}
}
}stdio 启动命令:python <BUILDER>/trae_build_mcp.py,无参数。server 自动发现当前工作区的 builder.json。
注意:非 Trae 客户端没有
/build、/build-init命令和 build skill(那些是 Trae 专用格式),但 MCP 工具完全可用。首次为一个 SDK 仓库生成builder.json,用下面的命令行方式。
# 生成 builder.json(扫描仓库,自动检测构建模式)
python <BUILDER>/trae_build_init.py /path/to/sdk-repo
# 查看配置
python <BUILDER>/trae_build_runner.py --project /path/to/sdk-repo info
# 按预设编译
python <BUILDER>/trae_build_runner.py --project /path/to/sdk-repo build --preset rx_default
# 列出产物
python <BUILDER>/trae_build_runner.py --project /path/to/sdk-repo list# 直接喂 JSON-RPC 测 MCP server(不依赖 Trae)
python <BUILDER>/trae_build_mcp.py < <BUILDER>/scripts/_mcp_probe_in.json已验证:initialize / tools/list / build_info / build_presets / build_run(dry-run) / build_list / shutdown 全部正常返回。
欢迎 issue / PR。如果你觉得有用,给个 ⭐ 让更多人看到。
建议在 GitHub 仓库 Settings 里添加 Topics(提升被搜索到的概率):
mcp mcp-server trae-plugin embedded firmware eclipse-cdt telink sdk-builder cross-platform ai-coding
分享到社区时可用:
Trae / Claude / MCP 社区(Discord、GitHub Discussions)
嵌入式开发论坛(说明:让 AI 直接编译 Telink/嵌入式 SDK 固件)
掘金/知乎等技术博客(配 demo 截图/录屏效果最佳)
Show the builder config for the current project (parameters, presets, artifacts config, toolchain). No build is performed.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project root containing builder.json. Defaults to the server's working directory or TRAE_BUILDER_PROJECT env var. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states 'No build is performed,' indicating a read-only operation, and lists the config contents. It does not mention permissions or output format, but for a read-only info tool, this is adequate.
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 long, with the first sentence stating the purpose and contents, and the second clarifying the non-build nature. No filler words; every sentence 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?
For a simple info tool with one optional parameter and no output schema, the description covers the essential behavioral aspects and parameter details. It lists config sections, which provides some indication of return content. Could mention the output is the full config, but overall sufficient.
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 describes the 'project' parameter with a default behavior note. The description adds value by explaining the default resolution: 'Defaults to the server's working directory or TRAE_BUILDER_PROJECT env var.' This goes beyond the schema 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 states 'Show the builder config for the current project (parameters, presets, artifacts config, toolchain).' This is a specific verb-resource combination and explicitly lists included sections. It distinguishes from sibling tools like build_run by stating 'No build is performed.'
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 clearly indicates the tool's purpose (view config) and explicitly says 'No build is performed,' which helps differentiate from build_run. However, it does not explicitly mention alternatives or when not to use it, though the context is clear enough for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List collected build artifacts (from the directories configured in builder.json 'artifacts.scan_dirs').
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It transparently describes a read-only listing operation from a specific configuration. While it doesn't mention potential behaviors like authentication needs or performance, it covers the essential behavior without contradiction.
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, well-structured sentence that efficiently communicates the core purpose and context. Every part is relevant, no redundancy or unnecessary detail.
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 one undocumented parameter and no output schema, the description provides the core functionality but falls short of completeness. It does not explain how to use the 'project' parameter or what the output format is, leaving gaps for a simple list 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?
The schema describes one optional parameter 'project' but the description does not explain its purpose or effect. With 0% schema description coverage, the description adds no meaning, forcing the agent to infer or ignore the parameter, which hinders correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'collected build artifacts', specifies the source configuration file and key, and distinguishes it from siblings like 'build_info' (likely build details) and 'build_run' (triggering builds).
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. The usage is implied (when you want to list artifacts), but there are no descriptions of when not to use it or comparisons to sibling tools, which would improve decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the named build presets defined in this project's builder.json.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only states the basic action. It does not disclose that this is a read-only operation, whether it accesses local or remote files, or any side effects. Important behavioral details like error handling or default behavior when the project parameter is omitted are missing.
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 at one sentence. It is front-loaded but sacrifices necessary detail. While not verbose, the lack of parameter and behavior information makes it feel under-specified rather than efficiently concise.
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 one optional parameter, no output schema, and no annotations, the description leaves significant gaps. It does not explain the return format, what happens if builder.json is missing, or if the project parameter is required for non-default projects. The context is insufficient for an agent to use the tool reliably.
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 0% description coverage and the tool description adds no meaning to the 'project' parameter. It does not explain how the parameter is used (e.g., to specify a different project) or that it is optional. The agent cannot infer parameter semantics from 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 clearly states the action ('List') and the specific resource ('named build presets defined in this project's builder.json'). It distinguishes itself from siblings like build_list and build_info by specifying the source file, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., build_list or build_info). The description does not indicate prerequisites, such as whether builder.json must exist, or contrast with sibling tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a build using the project's builder.json. Pass either a preset name and/or explicit parameter overrides (e.g. {"Target":"tx"}). Output artifacts are scanned afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Parameter overrides as key/value. Keys must match the 'parameters' list in builder.json. | |
| preset | No | Preset name from builder.json (e.g. 'rx_default'). | |
| dry_run | No | If true, print the command without executing the build. | |
| project | No | Project root. Defaults to cwd. | |
| timeout | No | Override build timeout in seconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only mentions 'output artifacts are scanned afterwards', missing side effects, permissions, error handling, or state changes.
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 sentences, front-loaded with action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description omits output format, error handling, and default behaviors for project/timeout, leaving gaps for a build tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds usage pattern for preset and params but doesn't significantly enhance understanding 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?
The description clearly states the tool runs a build using builder.json, specifying the verb 'run' and resource. It distinguishes from siblings like build_info or build_list by indicating execution action.
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?
Provides parameter usage pattern (preset and/or overrides) but lacks guidance on when to use this vs. sibling tools 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.
Show the 'flash' section of builder.json (default chip, bdt_path, timeout, reset_after_flash). Does not invoke bdt.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses read-only behavior (shows data, no side effects). However, it does not mention any authorization or side effects beyond not invoking bdt.
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 concise sentences, front-loaded with purpose and a critical constraint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is largely complete. It lacks parameter explanation but otherwise covers key behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fails to explain the single parameter 'project' (a string). Schema coverage is 0%, and no param info is provided, leaving the agent to guess its purpose.
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?
Clearly states the tool shows the 'flash' section of builder.json and explicitly says it does not invoke bdt, distinguishing it from actions like flashing.
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?
Provides the negative guidance 'Does not invoke bdt,' implying use for inspection not execution, but does not explicitly mention when to use versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke Telink bdt.exe to write/read flash/core/otp/analog or reset the chip. Reads builder.json 'flash' section for defaults (chip, bdt_path). Use wf to flash firmware (auto-picks latest .bin from build_variants if no input_file), rst -f to reset, rf to read back. Auto-resets after wf unless reset_after_flash=false.
| Name | Required | Description | Default |
|---|---|---|---|
| chip | No | bdt chip prefix, e.g. 'TL721X','B80','TC321X'. Empty = builder.json flash.default_chip or inferred from presets. | |
| size | No | -s size like '512k','12k'. | |
| erase | No | Add -e (erase before write). | |
| address | No | Flash/core/analog address (decimal). | |
| command | No | bdt command. wf=write flash, rf=read flash, wc/rc=core, wa/ra=analog, wo/ro=otp, lf=lock flash, rst=reset (-f flash/-c core), pc=print code/PC (-i optional .lst), ac=analyze chip (evk), sws=set sws (evk), help=help. | wf |
| dry_run | No | Print bdt command without executing. | |
| project | No | Project root. Defaults to cwd. | |
| timeout | No | Override per-op timeout in seconds. | |
| input_file | No | -i input file path (.bin). Empty for wf = latest artifact under build_variants. | |
| output_file | No | -o output file path for rf/rc/ro. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors such as reading builder.json defaults, auto-picking latest .bin, and auto-resetting after wf. It could mention dependencies or error handling, but it provides substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core purpose. It could benefit from structured bullet points, but it is efficient and informative.
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, no output schema, and no annotations, the description covers essential behaviors, defaults, and common usage patterns. It could mention expected outputs or errors, but it is sufficient for tool selection.
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% with parameter descriptions. The description adds value by explaining default behaviors (e.g., auto-picking .bin, reading builder.json) and auto-reset logic, going beyond 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 that the tool invokes Telink bdt.exe to write/read flash/core/otp/analog or reset the chip. It lists specific commands and their purposes, distinguishing it from sibling tools like build_run or flash_info.
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 explicit usage patterns: 'Use wf to flash firmware', 'rst -f to reset', 'rf to read back', and mentions auto-resets unless configured otherwise. It lacks explicit when-not-to-use or comparison with siblings but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a serial port and capture its output for a bounded duration. Useful to verify firmware behavior after flashing: read the UART log and let the agent judge if 'boot ok' / version string / expected output appears. Port/baud default to builder.json 'serial' section; auto-picks first port if none given.
| Name | Required | Description | Default |
|---|---|---|---|
| baud | No | Baud rate. Empty = builder.json serial.baud (default 115200). | |
| port | No | Serial port (e.g. 'COM3', '/dev/ttyUSB0'). Empty = builder.json serial.default_port or auto-detect. | |
| project | No | Project root. Defaults to cwd. | |
| max_lines | No | Maximum lines to capture. | |
| duration_seconds | No | How long to capture, in seconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses bounded duration and defaults but omits details like whether it blocks, error handling, or whether it returns immediately. Basic transparency, not deep.
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?
Three sentences, front-loaded with purpose and use case. No unnecessary words, 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 5 optional params, no output schema, and 7 siblings, the description provides enough context for basic usage (use case, defaults). Lacks output description but sufficient for a capture tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 params with descriptions. The description adds value by explaining fallback logic (builder.json, auto-detect) and defaults for port/baud, which are not fully captured in 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 opens a serial port and captures bounded output, with a specific use case: verifying firmware behavior after flashing. This distinguishes it from sibling serial_list and other tools.
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 explicitly gives a use case ('verify firmware behavior after flashing') and explains default behavior (builder.json config, auto-detect). While it doesn't mention when not to use it, the context with siblings is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available serial ports on this machine (cross-platform: COMx on Windows, /dev/tty* on Linux/macOS). Requires pyserial.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 an external dependency ('pyserial') and the cross-platform behavior. It does not mention error handling or return format, but the operation is simple and the description is honest.
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 sentences, no filler. Every sentence adds value: the first states the purpose with cross-platform detail, the second states the dependency. Front-loaded and efficient.
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?
While the description covers the purpose and dependency, it lacks information about the return value format (e.g., list of strings, device paths). With no output schema, the description could have explained what the agent will receive. Otherwise, adequate for a simple 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?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description need not add parameter information beyond what the schema provides. Baseline for 0 parameters is 4.
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 verb 'List' and resource 'available serial ports' clearly state the tool's action and target. The cross-platform naming examples (COMx, /dev/tty*) add specificity. It distinguishes from sibling 'serial_capture', which implies a different operation.
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 prerequisites ('Requires pyserial') and contextual cross-platform details, but does not explicitly state when to use this tool versus alternatives like 'serial_capture'. However, the purpose is clear enough for an agent to infer that it is for enumeration before capture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0build_infobuild_listbuild_presetsbuild_runflash_infoflash_runserial_captureserial_listEach tool targets a distinct action: build configuration, artifact listing, preset listing, building, flash config, flashing, serial capture, and port listing. No overlap in purpose.
All tools follow a consistent <resource>_<action> pattern (e.g., build_info, flash_run, serial_list). The naming is predictable and clear.
With 8 tools covering build configuration, execution, flashing, and serial verification, the count is well-scoped for an embedded firmware development workflow.
The surface covers the core workflow from config to flash to serial verification. A minor gap is lack of a tool to modify builder.json directly, but overrides are supported via build_run.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JannLeo/telinksdk-builder-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
