Servidor MCP que expone un Flipper Zero conectado por USB como un conjunto de herramientas para clientes MCP (Claude Code, Home Assistant a través de un puente compatible, etc.). La v0 se centra en IR: listar/analizar archivos .ir guardados, repetir botones, capturar nuevas señales.
Probado con Momentum firmware (mntm-008). Cualquier fork reciente de Flipper con la misma CLI (ir tx, ir rx, storage *, loader *) debería funcionar.
Herramienta | Propósito |
| Devuelve el diccionario |
| Lista los archivos |
| Analiza un archivo |
| Transmite un botón con nombre desde un archivo |
| Transmite una señal IR analizada ad-hoc mediante hex entero con MSB primero (ej. |
| Lista los mandos IR universales integrados disponibles en el firmware (ac, tv, ventiladores, ...) |
| Lista los nombres de señal para un mando universal integrado |
| Transmite una señal con nombre desde un mando universal integrado |
| Pone el Flipper en RX, captura la siguiente pulsación del mando y la añade a un archivo |
Related MCP server: Flipper Zero MCP Server
Instala usbipd-win en Windows:
winget install usbipdLuego (desde 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 / rebootDespués de attach, el Flipper aparecerá en WSL como /dev/ttyACM0.
sudo usermod -aG dialout $USERLuego reinicia WSL para que el grupo esté activo:
wsl.exe --shutdownReabre tu terminal. groups ahora debería incluir dialout.
Desde la raíz del repositorio:
uv syncuv run python scripts/smoketest_readonly.pyDeberías ver la información del dispositivo, una lista de archivos en /ext/infrared/ y el contenido analizado de cada archivo .ir.
MCP stdio (para Claude Code, Cursor, etc.):
uv run flipper-mcp-bridgeAPI REST HTTP (para Home Assistant, curl, scripts):
uv run flipper-mcp-bridge --http --port 8765Endpoints:
Método | Ruta | Cuerpo / Consulta |
|
| — |
|
| — |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HA necesita poder acceder por HTTP al puente. Dos configuraciones sencillas funcionan de inmediato:
Ejecutar el puente en el mismo host que HA (Pi/NUC/servidor con el Flipper conectado). HA accede a http://127.0.0.1:8765. Es lo más sencillo.
Ejecutar el puente en cualquier host Linux siempre encendido en la LAN. Inícialo con --host 0.0.0.0 (la CLI imprime una advertencia: no hay autenticación en la v1, así que haz esto solo en una LAN de confianza). HA accede a http://HOST:8765.
Advertencia sobre WSL2: WSL2 utiliza NAT; la IP de WSL no es accesible desde otros hosts en la LAN. Ejecutar el puente dentro de WSL2 y esperar que HA en un dispositivo diferente lo alcance requiere redirección de puertos netsh interface portproxy en el host Windows, o ejecutar el puente directamente en el host Windows (Python + pyserial funcionan bien en Windows).
Añade esto a 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"}'Luego en automatizaciones o scripts:
action:
- service: rest_command.flipper_humidifier_togglePara una entidad tipo interruptor, usa un interruptor RESTful apuntando al mismo endpoint /ir/send-button (el estado lo mantiene HA, ya que el Flipper no expone el estado del dispositivo).
El puente elige un dispositivo serie en este orden de prioridad:
Argumento explícito port= (solo para uso de biblioteca)
Variable de entorno FLIPPER_PORT
Detección automática: el primer dispositivo conectado cuyo fabricante USB sea "Flipper Devices Inc." (o VID:PID 0483:5740)
Alternativa: /dev/ttyACM0
Así que, en el caso común, no necesitas configurar nada. Si tienes múltiples dispositivos CDC y quieres fijar uno específico:
FLIPPER_PORT=/dev/ttyACM1 uv run flipper-mcp-bridgeO añade env a la entrada del servidor en .mcp.json.
El repositorio incluye un .mcp.json en la raíz; Claude Code lo detecta automáticamente cuando inicias una sesión en este directorio (se te pedirá que lo autorices en el primer lanzamiento). Si prefieres registrarlo explícitamente:
claude mcp add flipper -- uv run --directory "$(pwd)" flipper-mcp-bridgeLatencia de captura: learn_ir_button tarda unos segundos antes de que el Flipper empiece a escuchar realmente. Pulsa el mando un momento después de llamar a la herramienta, no inmediatamente.
Transporte: Solo CLI sobre serie. El RPC de Protobuf aún no está implementado. Está bien para IR a ritmo humano; podría revisarse para flujos sensibles al rendimiento.
Bloqueado por aplicaciones en primer plano: si una aplicación que no es la CLI posee el Flipper (ej. la pantalla de espera del reloj de noche), la transmisión IR está bloqueada. El puente intenta loader close una vez en caso de conflicto, pero algunas aplicaciones solo pueden cerrarse manualmente en el dispositivo.
Captura IR cruda no soportada: las señales de protocolos desconocidos no funcionarán de ida y vuelta mediante learn_ir_button todavía.
Solo IR: Sub-GHz, NFC, RFID, GPIO, BadUSB: ninguno de estos está conectado.
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.
