MCP-IDB
mcp-idb
Integración del servidor MCP para el puente de desarrollo iOS de Facebook (idb).
Descripción general
Este paquete proporciona integración entre MCP (Protocolo de contexto de modelo) e idb (Puente de desarrollo de iOS) de Facebook, lo que permite la gestión automatizada de dispositivos iOS y la ejecución de pruebas a través de MCP.
Iniciar el servidor:
npx -y @noahlozevski/mcp-idbRelated MCP server: iOS simulators MCP
Prerrequisitos
Instalación de idb
Para instalar idb:
brew tap facebook/fb
brew install idb-companion
# verify installation
idbPara obtener más detalles, visita el repositorio oficial de idb en GitHub .
Configuración
Configuración de mcp-config.json
Para usar idb en su configuración de MCP, agregue lo siguiente a su mcp-config.json :
{
"mcpServers": {
"idb": {
"command": "npx",
"args": ["-y", "@noahlozevski/idb"]
}
}
}Algunos ejemplos de casos de uso incluyen:
Desarrollo de pruebas automatizadas
Prueba de captura de pantalla
Interacciones automatizadas ("toque el botón de inicio en la pantalla")
Instalar/eliminar aplicaciones
Desarrollo
Formato de código
Este proyecto utiliza Prettier para formatear el código. Para formatear el código:
npm run format # Format all filesLa configuración de formato se puede encontrar en .prettierrc en la raíz del proyecto.
Solución de problemas
Problemas comunes y soluciones:
No se encontró el compañero de idb : asegúrese de que idb-companion esté instalado mediante Homebrew
Dispositivo no detectado : asegúrese de que el dispositivo iOS esté:
Conectado a través de USB
De confianza en la computadora
Tiene habilitado el modo desarrollador
Contribuyendo
Siga las pautas de contribución estándar de MCP al realizar cambios en este paquete.
Licencia
Este proyecto es parte de Mobile Control Plane (MCP) y sigue las políticas de licencia internas de Amazon.
Available Tools
1 toolidbD
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The IDB command to execute (e.g., list-apps, screenshot, etc.). - For a full list of commands, run 'idb help'. - For help with a specific command, run 'idb <command> --help'. To interact with the device (simulator): IMPORTANT: Always try using the 'idb ui describe-all' command to identify buttons before dispatching UI actions. If that doesn't work, try using the following commands: - **Tap** - **Command:** 'idb ui tap X Y [--duration DURATION]' - **Description:** Simulates a tap at the given screen coordinates. Optionally, you can set the tap's duration. - **Swipe** - **Command:** 'idb ui swipe X_START Y_START X_END Y_END [--delta STEP_SIZE]' - **Description:** Simulates a swipe gesture from the start point to the end point. By default, the swipe moves in steps of 10 points; use '--delta' to change the step size. - **Press a Button** - **Command:** 'idb ui button {APPLE_PAY, HOME, LOCK, SIDE_BUTTON, SIRI} [--duration DURATION]' - **Description:** Simulates pressing a specified hardware button. The press duration can be adjusted with the '--duration' flag. - **Inputting Text** - **Command:** 'idb ui text "some text"' - **Description:** Types the provided text string into the target device. - **Key Events** - **Single Key:** 'idb ui key KEYCODE [--duration DURATION]' - **Key Sequence:** 'idb ui key-sequence KEYCODE1 KEYCODE2 ...' - **Description:** Simulates key press events. Use the single key command for one key press (with an optional duration) or the key sequence command for multiple sequential key events. **Frame and Coordinates in idb ui describe-all:** The output from 'idb ui describe-all' provides detailed layout information for each UI element. Each element includes a 'frame' object with: - **x and y:** The coordinates of the element's top-left corner relative to the device screen. - **width and height:** The dimensions of the element. Additionally, an 'AXFrame' string presents this data in a human-readable format like '{{x, y}, {width, height}}'. These values allow you to determine an element's position—commonly by calculating its center (x + width/2, y + height/2) for precise interactions. For instance, in the sample output, the "More, tab, 4 of 4" button has a frame starting at x=330, y=876.33 with a width of 110 and height of 45.67. A tap command such as 'idb ui tap 375 880' (which targets near the element's center) successfully triggers the button. | |
| options | No | Optional arguments for the IDB command |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
idb
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'idb' stands alone with no other tools to confuse it with, making disambiguation perfect by default.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'idb' is a standalone identifier with no pattern deviations or mixing of conventions.
A single tool with no description makes it difficult to assess the server's purpose, but one tool is generally too few for meaningful functionality unless it's a trivial utility. Without context, this feels insufficient for most domains, suggesting a mismatch in scope.
With only one tool and no description, it's impossible to infer the domain or assess coverage. There are likely significant gaps, as a single tool cannot provide CRUD/lifecycle coverage for any non-trivial purpose, making the surface severely incomplete.
Maintenance
Related MCP Connectors
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
MCP-Native LLM Orchestration Agent
Mozark's MCP server for AI-powered app testing: device access, test automation, and QA insights.
Related MCP Servers
- AlicenseCqualityDmaintenanceA bridge between iOS simulators and the Model Context Protocol, enabling programmatic control of iOS simulators through standardized communication interfaces.1244TypeScriptMIT
- AlicenseNot gradedqualityCmaintenanceA MCP server that enables LLMs to interact with iOS simulators through natural language commands.328Apache 2.0
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI assistants to interact with iOS simulators, perform accessibility testing, manage apps, and automate complex iOS workflows.32Apache 2.0
- AlicenseNot gradedqualityBmaintenanceMCP server and CLI for iOS development — build, test, automate, and diagnose from any AI agent or terminal.1MIT