USB接続されたFlipper ZeroをMCPクライアント（Claude Code、互換ブリッジ経由のHome Assistantなど）向けのツールセットとして公開するMCPサーバー。v0ではIR（赤外線）に焦点を当てており、保存された.irファイルのリスト表示・解析、ボタンの再送、新しい信号のキャプチャが可能です。
Momentum firmware (mntm-008) でテスト済みです。同じCLI（ir tx, ir rx, storage *, loader *）を持つ最近のFlipperフォークであれば動作するはずです。
ツール | 用途 |
| Flipperの |
| SDカード上のディレクトリ内の |
| 保存された |
| 保存された |
| MSBファーストの整数16進数（例: |
| ファームウェアで利用可能な内蔵ユニバーサルIRリモコン（ac, tv, fansなど）をリスト表示する |
| 内蔵ユニバーサルリモコンの信号名をリスト表示する |
| 内蔵ユニバーサルリモコンから指定した信号を送信する |
| 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シェルを再起動します。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リクエストを送れる必要があります。以下の2つの簡単な構成がそのまま利用可能です：
ブリッジをHAと同じホストで実行する（Flipperを接続したPi/NUC/サーバー）。HAは http://127.0.0.1:8765 にアクセスします。これが最も簡単です。
LAN上の常時稼働Linuxホストでブリッジを実行する。--host 0.0.0.0 を付けて起動します（CLIで警告が表示されます。v1では認証がないため、信頼できるLAN内でのみ実行してください）。HAは http://HOST:8765 にアクセスします。
WSL2の注意点: WSL2はNATを使用するため、WSLのIPにはLAN上の他のホストから到達できません。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スイッチを使用してください（Flipper自体はデバイスの状態を公開しないため、状態はHA側で管理されます）。
ブリッジは以下の優先順位でシリアルデバイスを選択します：
明示的な port= 引数（ライブラリ使用時のみ）
FLIPPER_PORT 環境変数
自動検出: USBメーカーが "Flipper Devices Inc."（またはVID:PID 0483:5740）である最初に見つかったデバイス
フォールバック: /dev/ttyACM0
通常は設定不要です。複数のCDCデバイスがあり、特定のデバイスを指定したい場合は以下のようにします：
FLIPPER_PORT=/dev/ttyACM1 uv run flipper-mcp-bridgeまたは、.mcp.json サーバーエントリに env を追加してください。
リポジトリのルートに .mcp.json が含まれています。このディレクトリでセッションを開始すると、Claude Codeが自動的に読み込みます（初回起動時に信頼するかどうか尋ねられます）。明示的に登録したい場合は以下のようにします：
claude mcp add flipper -- uv run --directory "$(pwd)" flipper-mcp-bridgeキャプチャの遅延: learn_ir_button は、Flipperが実際にリッスンを開始するまでに数秒かかります。ツールを呼び出した直後ではなく、少し間を置いてからリモコンを押してください。
トランスポート: シリアル経由のCLIのみです。Protobuf RPCはまだ実装されていません。人間が操作するペースのIRには十分ですが、スループットが重要なフローについては今後見直される可能性があります。
フォアグラウンドアプリによるブロック: CLI以外のアプリ（ナイトスタンド時計のアイドル画面など）がFlipperを占有している場合、IR送信はブロックされます。ブリッジは競合時に一度 loader close を試みますが、デバイス上で手動で終了させる必要があるアプリもあります。
Raw IRキャプチャは未サポート: 未知のプロトコルの信号は、learn_ir_button を介した往復がまだできません。
IRのみ: 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.
