MCP-сервер, который предоставляет подключенный по USB Flipper Zero в качестве набора инструментов для MCP-клиентов (Claude Code, Home Assistant через совместимый мост и т. д.). Версия v0 сфокусирована на ИК-порте: список/анализ сохраненных файлов .ir, повтор нажатий кнопок, захват новых сигналов.
Протестировано на прошивке Momentum (mntm-008). Любой актуальный форк Flipper с тем же CLI (ir tx, ir rx, storage *, loader *) должен работать.
Инструмент | Назначение |
| Возвращает словарь |
| Список файлов |
| Анализирует сохраненный файл |
| Передает именованную кнопку из сохраненного файла |
| Передает произвольно проанализированный ИК-сигнал в виде шестнадцатеричного целого числа (старший бит первый, например |
| Список встроенных универсальных ИК-пультов, доступных в прошивке (кондиционеры, ТВ, вентиляторы и т. д.) |
| Список названий сигналов для встроенного универсального пульта |
| Передает именованный сигнал со встроенного универсального пульта |
| Переводит Flipper в режим RX, захватывает следующее нажатие пульта и добавляет его в файл |
Related MCP server: Flipper Zero MCP Server
Установите usbipd-win в Windows:
winget install usbipdЗатем (из PowerShell в Windows):
usbipd list # find the Flipper's BUSID
usbipd bind --busid <X-Y> # one-time, admin PowerShell
usbipd attach --wsl --busid <X-Y> # each replug / rebootПосле attach 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-запросы к мосту. Два простых варианта работают «из коробки»:
Запуск моста на том же хосте, что и HA (Pi/NUC/сервер с подключенным Flipper). HA обращается к http://127.0.0.1:8765. Самый простой способ.
Запуск моста на любом постоянно включенном хосте Linux в локальной сети. Запустите его с параметром --host 0.0.0.0 (CLI выведет предупреждение — в v1 нет аутентификации, поэтому делайте это только в доверенной локальной сети). HA обращается к http://HOST:8765.
Оговорка по WSL2: WSL2 использует NAT — IP-адрес WSL недоступен с других хостов в локальной сети. Запуск моста внутри WSL2 с ожиданием доступа к нему из HA на другом устройстве требует проброса портов netsh interface portproxy на хосте Windows или запуска моста непосредственно на хосте 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Для сущности типа переключателя используйте RESTful switch, указывающий на тот же эндпоинт /ir/send-button (состояние поддерживается 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 еще не подключен. Это подходит для ИК-команд с человеческой скоростью; может быть пересмотрено для потоков, чувствительных к пропускной способности.
Блокировка фоновыми приложениями: если Flipper занят приложением, не являющимся CLI (например, экран ожидания «Прикроватные часы»), передача ИК-сигнала блокируется. Мост пытается выполнить 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.
