MCP 服务器，将通过 USB 连接的 Flipper Zero 作为 MCP 客户端（如 Claude Code、通过兼容桥接器的 Home Assistant 等）的一组工具。v0 版本专注于红外功能：列出/解析已保存的 .ir 文件、重放按钮、捕获新信号。
已在 Momentum 固件 (mntm-008) 上测试。任何具有相同 CLI (ir tx, ir rx, storage *, loader *) 的近期 Flipper 分支版本均应适用。
工具 | 用途 |
| 返回 Flipper 的 |
| 列出 SD 卡上目录下的 |
| 解析已保存的 |
| 发送来自已保存 |
| 通过 MSB 优先的整数十六进制发送临时解析的红外信号（例如 |
| 列出固件上可用的内置通用红外遥控器（空调、电视、风扇等） |
| 列出内置通用遥控器的信号名称 |
| 发送来自内置通用遥控器的指定信号 |
| 将 Flipper 置于 RX 模式，捕获下一次遥控器按键，并将其附加到 |
Related MCP server: Flipper Zero MCP Server
在 Windows 上安装 usbipd-win：
winget install usbipd然后（从 Windows PowerShell）：
usbipd list # find the Flipper's BUSID
usbipd bind --busid <X-Y> # one-time, admin PowerShell
usbipd attach --wsl --busid <X-Y> # each replug / rebootattach 后，Flipper 将在 WSL 中显示为 /dev/ttyACM0。
sudo usermod -aG dialout $USER然后重启 WSL 以使组生效：
wsl.exe --shutdown重新打开 shell。groups 现在应该包含 dialout。
从仓库根目录：
uv syncuv run python scripts/smoketest_readonly.py你应该能看到设备信息、/ext/infrared/ 下的文件列表以及每个 .ir 文件的解析内容。
MCP stdio（用于 Claude Code、Cursor 等）：
uv run flipper-mcp-bridgeHTTP REST API（用于 Home Assistant、curl、脚本）：
uv run flipper-mcp-bridge --http --port 8765端点：
方法 | 路径 | 正文 / 查询 |
|
| — |
|
| — |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HA 需要能够通过 HTTP 访问该桥接器。两种简单的设置可以直接使用：
在与 HA 相同的主机上运行桥接器（插入 Flipper 的 Pi/NUC/服务器）。HA 访问 http://127.0.0.1:8765。最简单。
在局域网内任何常开的 Linux 主机上运行桥接器。使用 --host 0.0.0.0 启动（CLI 会打印警告——v1 版本没有身份验证，因此仅在受信任的局域网内执行此操作）。HA 访问 http://HOST:8765。
WSL2 注意事项：WSL2 使用 NAT——WSL IP 在局域网的其他主机上不可达。在 WSL2 内运行桥接器并期望不同设备上的 HA 访问它，需要在 Windows 主机上进行 netsh interface portproxy 端口转发，或者直接在 Windows 主机上运行桥接器（Python + pyserial 在 Windows 上运行良好）。
将其放入 configuration.yaml：
rest_command:
flipper_humidifier_toggle:
url: "http://FLIPPER_HOST:8765/ir/send-button"
method: POST
content_type: "application/json"
payload: '{"file":"/ext/infrared/Remote.ir","button":"Humid"}'
flipper_ac_off:
url: "http://FLIPPER_HOST:8765/ir/universal/send"
method: POST
content_type: "application/json"
payload: '{"remote":"ac","signal":"OFF"}'然后在自动化或脚本中：
action:
- service: rest_command.flipper_humidifier_toggle对于类似开关的实体，请使用指向相同 /ir/send-button 端点的 RESTful 开关（状态由 HA 维护，因为 Flipper 本身不暴露设备状态）。
桥接器按以下优先级顺序选择串口设备：
显式的 port= 参数（仅限库使用）
FLIPPER_PORT 环境变量
自动检测：USB 制造商为 "Flipper Devices Inc."（或 VID:PID 0483:5740）的第一个已连接设备
回退：/dev/ttyACM0
因此在通常情况下，你不需要设置任何内容。如果你有多个 CDC 设备并想固定其中一个：
FLIPPER_PORT=/dev/ttyACM1 uv run flipper-mcp-bridge或者将 env 添加到 .mcp.json 服务器条目中。
该仓库在根目录提供了一个 .mcp.json 文件——当你在此目录中启动会话时，Claude Code 会自动识别它（首次启动时会提示你信任它）。如果你想显式注册它：
claude mcp add flipper -- uv run --directory "$(pwd)" flipper-mcp-bridge捕获延迟：learn_ir_button 在 Flipper 真正开始监听之前需要几秒钟。调用工具后稍等片刻再按下遥控器，不要立即按下。
传输：仅限串口 CLI。Protobuf RPC 尚未连接。对于人类节奏的红外操作没问题；可能会针对吞吐量敏感的流程重新考虑。
被前台应用阻塞：如果非 CLI 应用拥有 Flipper（例如床头钟空闲屏幕），红外发送将被阻塞。桥接器在冲突时会尝试执行一次 loader close，但某些应用只能在设备上手动退出。
不支持原始红外捕获：未知协议信号尚无法通过 learn_ir_button 进行往返。
仅限红外：Sub-GHz、NFC、RFID、GPIO、BadUSB——这些均未连接。
Remove a named button from an .ir file (reads, filters, rewrites).
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| button | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions the tool 'reads, filters, rewrites' the file, indicating a destructive write operation. However, it does not specify what happens if the button does not exist, whether the change is reversible, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. It is appropriately short but could be slightly more detailed without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params and no output schema, the description covers the basic purpose and hints at the internal process. However, it lacks usage context and parameter details, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no extra meaning to the parameters 'file' and 'button' beyond their names. It does not specify file format, button naming conventions, or path details.
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 ('Remove') and the resource ('named button from an .ir file'), and mentions the internal steps (reads, filters, rewrites). This distinguishes it from siblings like list_ir_buttons or send_ir_button.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_ir_buttons or send_ir_button. No when-not-to-use or prerequisite info is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Flipper's device_info dict (firmware, hardware, radio, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns a dict but does not disclose any behavioral traits like caching, permissions, or response details beyond the basic return type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero wasted words. Front-loaded with the key action and resource.
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 zero parameters and an output schema, the description sufficiently covers the tool's purpose and return content. No gaps identified for this 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?
No parameters, so description adds no parameter info. Baseline of 4 is appropriate since schema coverage is 100% and no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the Flipper's device_info dict with specific categories (firmware, hardware, radio), distinguishing it from all IR-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not guidance, but the context of sibling tools being all IR implies this is for device information. Clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put Flipper in IR RX, wait for a single remote press (up to timeout_seconds), then append the captured signal as a named button to the given .ir file. Creates the file if it doesn't exist. The user must press a physical remote at the Flipper during the capture window.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| button | Yes | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: Flipper enters IR RX, waits up to timeout_seconds, appends to file (creates if absent), requires physical press. No annotations exist, so description carries full burden; minor gaps like handling duplicate button names not specified.
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, each adding meaningful information. Efficiently front-loads the core action and provides supplementary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main workflow and file handling. Missing return value details (no output schema) and handling of duplicate button names. Adequate for basic use but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to parameters (file is the .ir file, button is the name for captured signal, timeout_seconds is max wait). Schema coverage is 0%, so description must compensate, but lacks details like file extensions or time-out behavior.
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?
Specifically describes putting Flipper in IR RX mode, waiting for a remote press, and appending the signal as a named button to a file. Clearly distinguishes from siblings like send_ir_button and delete_ir_button.
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?
Clearly states when to use: to capture a new IR signal from a physical remote. Does not explicitly exclude other cases or mention alternatives, but the context of siblings provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a saved .ir file on the Flipper and return its buttons.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'parses' and 'returns'. It does not disclose side effects (none expected for a read operation), error conditions (e.g., missing file, invalid format), or whether it modifies state. Minimal 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 a single, efficient sentence that conveys the core action with no extraneous words. It is front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, output schema exists), the description sufficiently explains the input and outcome. It could mention that the file must be on the Flipper or that buttons are returned as structured data, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond the schema's parameter name 'file'. It does not explain what the file path refers to, the expected format, or constraints (e.g., must be an existing .ir file).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Parse' and identifies the resource as a 'saved .ir file' on the Flipper, clearly stating it returns buttons. This distinguishes it from sibling tools that delete, learn, send, or list files/remotes, making its 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., when the file exists, prerequisites, or that it's for reading only). The description lacks any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List .ir files under a directory on the Flipper's SD card (non-recursive).
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | /ext/infrared |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It states the tool lists files non-recursively, which is a key behavioral trait. However, it does not mention that this is a read-only operation, what happens if the directory does not exist, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 15 words, front-loaded with essential information. It contains no superfluous text and effectively conveys the tool's purpose.
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 listing tool with one optional parameter and an output schema, the description covers the key aspects: file type, directory scope, and recursion behavior. Minor gaps include lack of usage guidelines (when to use vs siblings) and no mention of error handling or connectivity requirements.
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 for the single parameter 'directory'. The description adds meaning by stating the tool lists files under a directory, clarifying that the parameter is the path. It also constrains the operation to .ir files and non-recursive listing, which provides additional semantic context beyond the schema field name.
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 'List .ir files under a directory on the Flipper's SD card (non-recursive)', specifying the action (list), resource (.ir files), location (directory on SD card), and a constraint (non-recursive). It distinguishes itself from sibling tools like list_ir_buttons (which lists buttons) and list_universal_remotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_ir_buttons or send_ir_signal. It does not mention any prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in universal IR remote names on this firmware (ac, tv, fans, ...).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states it lists built-in names. It does not disclose any side effects (none expected), permission needs, or performance traits. Minimal but acceptable for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with examples, no wasted words. Perfectly front-loaded and 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?
The tool is simple with no parameters and a clear purpose. Although the description does not detail the output, an output schema exists, so completeness is adequate. Slight deduction for not explicitly stating the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema, and schema description coverage is 100%. The description adds nothing beyond the schema, but baseline 3 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists built-in universal IR remote names, with specific examples (ac, tv, fans). The verb 'list' is specific and the resource is distinct from siblings like list_ir_files or list_universal_signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. While the context of sibling tools implies its use for remote names, the description does not direct the agent to alternatives like list_universal_signals or send_universal_signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the signal names available for a built-in universal remote (e.g. POWER, VOL+).
| Name | Required | Description | Default |
|---|---|---|---|
| remote | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the action without indicating side effects, read-only nature, authorization needs, or errors. For a listing operation, it's likely safe, but important context is 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 a single sentence of 15 words, front-loading the action and purpose. No redundant information, every word contributes.
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 tool with one parameter and an output schema, the description provides the basic purpose but lacks usage guidance, parameter clarification, and behavioral transparency. It is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required string parameter 'remote' with no description (0% coverage). The description mentions 'built-in universal remote' but does not clarify what value the parameter expects (e.g., name or ID), nor does it provide examples for the parameter itself.
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 'signal names for a built-in universal remote', with examples like POWER, VOL+. This distinguishes it from siblings like list_universal_remotes and list_ir_buttons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description does not mention prerequisites, nor does it exclude any scenarios. Sibling tool names imply differentiation, but the description itself lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transmit a named button from a saved .ir file on the Flipper. Raises on CLI error.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | ||
| button | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only mentions 'Raises on CLI error', but fails to disclose other traits such as whether the operation is destructive, requires specific permissions, or what the return value is.
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 redundancy, directly conveys purpose and error behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain what 'transmit' entails (e.g., sending an IR signal), success behavior, or how to differentiate from similar tools. Insufficient for an agent to use 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 description adds basic context: 'file' is a saved .ir file and 'button' is a named button, but lacks details on file path format or button name conventions. With 0% schema description coverage, this provides necessary but minimal improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Transmit a named button from a saved .ir file on the Flipper', which provides a specific verb and resource, distinguishing it from siblings like 'learn_ir_button' or 'list_ir_buttons'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'send_ir_signal' or 'send_universal_signal'. Prerequisites (file existence, valid button) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transmit an ad-hoc parsed IR signal. address and command are MSB-first integer
hex as reported by ir rx (e.g. protocol='NECext', address='DF02', command='EE11').
Optional '0x' prefix is fine. Raises on CLI error.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | ||
| address | Yes | ||
| command | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions 'Raises on CLI error', but lacks disclosure of side effects (e.g., physical IR output), permissions, or idempotency. Basic transmission is implied, but overall transparency is low.
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 wasted words, clear structure. First sentence defines purpose, second provides parameter details and error behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 params with 0% schema coverage, description explains parameter format and error handling. However, lacks details on return values, prerequisites, or how the output looks. Adequate but not comprehensive for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, description explains address and command as MSB-first hex with examples (e.g., 'DF02'), and mentions protocol example ('NECext'). Adds meaning beyond schema, but protocol is not fully described. Partially compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Transmit an ad-hoc parsed IR signal', differentiating from send_ir_button (which sends stored buttons) and send_universal_signal. The verb 'transmit' and resource 'IR signal' are specific.
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 format instructions (hex, MSB-first, optional prefix) and error behavior, but does not explicitly state when to use this tool over siblings. The context with siblings like send_ir_button implies use for ad-hoc signals, but not direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transmit a named signal from a built-in universal remote (e.g. remote='ac', signal='OFF').
| Name | Required | Description | Default |
|---|---|---|---|
| remote | Yes | ||
| signal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states that it 'transmits' a signal, but omits key details like side effects, authorization needs, success/failure behavior, or whether the remote must be available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with an example. Every word earns its place; no redundancy or filler.
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 lack of annotations and output schema, the description is insufficient. It does not explain return values, error conditions, prerequisites, or constraints, leaving the agent without critical context for a successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides an example (remote='ac', signal='OFF'), which gives some meaning, but does not explain valid values, format constraints, or relationship to sibling list tools that could provide valid options.
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 transmits a named signal from a built-in universal remote, with an explicit example. It distinguishes from sibling tools like list_universal_remotes and list_universal_signals, as well as IR-specific 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 implies usage when sending a universal remote signal, but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or context for 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.1delete_ir_buttondevice_infolearn_ir_buttonlist_ir_buttonslist_ir_fileslist_universal_remoteslist_universal_signalssend_ir_buttonsend_ir_signalsend_universal_signalScored across 10 tools
Each tool targets a distinct action or resource: device_info for hardware info, list_* for browsing, learn_* for capturing, send_* for transmitting, and delete_* for removal. No two tools overlap in purpose.
Most tools follow a verb_ir_noun or verb_universal_noun pattern (e.g., delete_ir_button, send_universal_signal). The one exception is device_info, which uses noun_noun, breaking the pattern slightly.
With 10 tools, the server covers the core IR workflows (browse, learn, send, delete) without being overwhelming. The count feels well-scoped for the domain.
Basic IR operations are covered, but there are gaps: no tool to delete an entire .ir file, rename a file or button, or directly create an empty file. These missing operations may cause workflow dead ends.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Remote MCP server to read and manage your Atako AI agents, messages, files, and integrations.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
