USB로 연결된 Flipper Zero를 MCP 클라이언트(Claude Code, 호환 브리지를 통한 Home Assistant 등)를 위한 도구 세트로 노출하는 MCP 서버입니다. v0 버전은 IR에 중점을 둡니다: 저장된 .ir 파일 나열/파싱, 버튼 재전송, 새로운 신호 캡처.
**Momentum 펌웨어(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로 연결할 수 있어야 합니다. 두 가지 쉬운 설정이 바로 작동합니다:
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 TX가 차단됩니다. 브리지는 충돌 시 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.
