Allows testing and automation of Android emulators and real devices through ADB and UIAutomator, enabling screenshot capture, UI interaction, app launching, and accessibility audits.
Provides integration with Appium for iOS automation through WebDriverAgent, enabling UI testing, element interaction, and mobile app automation workflows.
Enables testing and automation of iOS simulators and real devices via xcrun simctl and WebDriverAgent, supporting screenshot capture, UI interaction, app management, and accessibility testing.
Provides platform support for running mobile testing automation tools, serving as the base operating system for iOS simulator management and Android emulator execution.
Enables iOS simulator management and WebDriverAgent execution for iOS app testing and automation through Xcode command-line tools.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@phantom-mcp take a screenshot of the login screen on the iPhone 15 simulator"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that allows Claude Code to see and control iOS simulators, Android emulators, and real devices. 24 tools to test mobile apps without leaving the terminal.
Claude can take screenshots, read the screen, tap, scroll, fill in fields, verify assertions, record videos — automatically, on iOS and Android.
A test report with screenshots is generated automatically at the end of each test session.
Claude Code
| MCP protocol (stdio)
v
Phantom (Node.js TypeScript)
| |
v v
iOS Android
xcrun simctl ADB
WebDriverAgent UIAutomator
(localhost:8100) (adb shell)
| |
v v
Simulateur / iPhone Emulateur / DeviceRelated MCP server: mobile-device-mcp
Tool | Required for | How to check |
macOS 13+ | all | - |
Xcode 15+ | iOS |
|
Node.js 18+ | all |
|
Appium 3+ | iOS (WDA) |
|
xcuitest driver | iOS (WDA) |
|
Android SDK | Android |
|
# 1. Installer le package
npm install -g phantom-mcp
# 2. Installer Appium + driver iOS
npm install -g appium
appium driver install xcuitest
# 3. Enregistrer dans Claude Code
claude mcp add -s user phantom -- npx phantom-mcpgit clone https://github.com/nthimpulse/phantom-mcp.git
cd phantom-mcp
npm install
npm run build
claude mcp add -s user phantom -- node "$(pwd)/build/index.js"Tool | Description |
| Lists all devices (iOS sims + Android emus + real devices) |
| Selects the active device. Auto-boots if off. Auto-prepares the device (opt-out via skip_setup) |
| Sets the device to a clean state: clear clipboard / status bar overrides / dismiss keyboard / force QWERTY iOS |
Tool | Description |
| Captures the active device screen |
| Accessibility tree with index [N] for each element |
| Waits for an element to appear (with timeout) |
| Scrolls until an element is found |
Tool | Description |
| Verifies that text IS on the screen |
| Verifies that text IS NOT on the screen |
Tool | Description |
| Taps (by index, coordinates, or text). Auto-dismisses keyboard if target is obscured |
| Long press (context menus) |
| Text entry with clear option, and verify option to re-read the value after typing |
| Swipe (up/down/left/right) |
| Closes the soft keyboard (no-op if not visible) |
Tool | Description |
| Opens a URL / deep link |
Tool | Description |
| Simulates a shake |
| Changes orientation (portrait/landscape) |
| Starts/stops video recording |
Tool | Description |
| Launches an app by bundle ID / package name |
| Closes an app |
Tool | Description |
| Accessibility audit: missing labels, tap targets too small, images without alt text |
| Automatic test report: start to begin tracking, end to generate the markdown. Each action is tracked automatically. |
| Compares two screenshots pixel by pixel to detect visual regressions |
| Executes the same action on multiple devices in one command |
Phantom never boots a device automatically. It asks you to choose:
If only 1 device is active, it uses it automatically
If multiple, it asks you to choose with set_device
If none, it shows you the list of available devices
WebDriverAgent is launched automatically on the first iOS tool that needs it. First launch ~60-90s (Xcode build), then instantaneous.
All ADB commands target the device selected via -s <serial>. No multi-device confusion.
Entry uses pbcopy + Cmd+V (paste) instead of the virtual keyboard. It is instantaneous and works on all keyboard layouts (AZERTY, QWERTY, etc.).
Each action (tap, type, swipe, assert...) is automatically recorded with a screenshot. At the end of the test, a markdown report is generated in /tmp/phantom-report-xxx/.
All system commands go through execFile (no shell)
Inputs validated by regex: bundle IDs, UDIDs, package names, AVD names, URLs
iOS predicates escaped (anti-injection)
Android text escaped for the device shell
Zero as any, zero exec() shell
Optional environment variables:
PHANTOM_WDA_PATH — path to WebDriverAgent (default: ~/.appium/...)
PHANTOM_WDA_URL — WDA URL (default: http://localhost:8100)
See CONTRIBUTING.md for local setup, the pattern for adding a new tool, naming conventions, and the PR workflow.
See also:
docs/LIMITATIONS.md — known limitations + workarounds
docs/PATTERNS.md — practical recipes (iOS DatePicker, bottom sheets, etc.)
docs/FEATURE_REQUESTS.md — prioritized features for upcoming versions
docs/CHANGES_2026-04-30.md — release notes v2.3.0
MobAI or another tool is using port 8100.
lsof -i :8100
pkill -f "MobAI"xcrun simctl list devices available # iOS
adb devices -l # Androidcd ~/.appium/node_modules/appium-xcuitest-driver/node_modules/appium-webdriveragent
xcodebuild -project WebDriverAgent.xcodeproj \
-scheme WebDriverAgentRunner \
-destination "platform=iOS Simulator,name=iPhone 17 Pro" \
testls ~/Library/Android/sdk/platform-tools/adbphantom/
src/
index.ts Point d'entree MCP (24 tools)
platforms/
types.ts Interfaces communes
ios/
simctl.ts Wrapper xcrun simctl
wda.ts Client WDA + auto-launch
android/
adb.ts Wrapper ADB complet
tools/ 24 tools (21 fichiers)
utils/
device-manager.ts Detection + routing multi-device
xml.ts Parser XML partage
docs/
README.md Ce fichier
TUTORIAL.md Tuto pas-a-pas
FLOWS.md Exemples de flows de testVerifie l'accessibilite de l'ecran actuel : labels manquants, tap targets trop petits, images sans alt text. Retourne un rapport de violations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It implies a read-only audit by stating 'checks' and 'returns a report', but does not explicitly confirm no side effects or disclose any constraints like requiring a stable screen.
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 that efficiently conveys the tool's function, key checks, and output. No unnecessary words.
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 tool with no parameters and no output schema, the description is adequate. It explains the input (current screen), the checks performed, and the return type. Minor omission: it does not specify the format or structure of the violation report, but that might be implied.
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 0 parameters, so schema description coverage is 100%. Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter information, which is unnecessary.
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's purpose: checking accessibility of the current screen for missing labels, small tap targets, and missing alt text, and returning a violation report. This distinguishes it from sibling tools, which are all UI interaction or device manipulation 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 for accessibility verification but does not explicitly state when to use it vs. alternatives or when not to use it. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie qu'un élément contenant le texte donné n'est PAS visible à l'écran.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texte qui ne doit PAS être à l'écran |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately describes the behavior (verifying non-visibility) but does not disclose potential error conditions (e.g., what happens if element is visible) or side effects.
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, compact sentence that conveys the core purpose without extraneous words. It is front-loaded with the verb 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?
For a simple assertion tool with one parameter and no output schema, the description is minimally adequate. It explains the check but does not elaborate on return type or usage in testing flows.
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 provides 100% coverage for the single parameter with a clear description. The tool description adds no additional meaning beyond what the schema already states.
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 (vérifie), resource (élément contenant le texte donné), and condition (n'est PAS visible). It effectively distinguishes from the sibling assert_visible by specifying negation.
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 for asserting element absence but lacks explicit when-to-use, when-not-to-use, or reference to alternatives like assert_visible. The contrast with the sibling is implicit but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie qu'un élément contenant le texte donné est visible à l'écran. Retourne OK ou FAIL avec les éléments actuellement visibles.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texte attendu à l'écran |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Aucune annotation fournie, donc la description doit porter le poids du comportement. Elle mentionne le retour (OK/FAIL) mais ne précise pas si l'outil effectue un défilement ou attend, ce qui serait utile pour éviter des suppositions.
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?
Deux phrases concises, sans superflu. Chaque mot est nécessaire et l'information est placée en tête.
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?
Pour un outil simple avec un seul paramètre et aucun schéma de sortie, la description couvre l'essentiel. Elle pourrait néanmoins clarifier qu'il ne défile pas et ne modifie pas l'état.
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?
Le paramètre 'text' a une description dans le schéma (100 % couverte). La description générale ajoute que le texte est 'attendu' mais n'apporte pas de valeur significative au-delà du schéma.
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?
Le verbe 'Vérifie' et la ressource 'élément contenant le texte donné' précisent clairement l'action. La mention 'retourne OK ou FAIL' distingue bien des outils comme 'wait_for_element' ou 'assert_not_visible'.
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?
La description n'indique pas explicitement quand utiliser cet outil plutôt que 'wait_for_element', 'get_ui_tree' ou 'assert_not_visible'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ouvre une URL ou un deep link dans l'app (ex: myapp://profile, https://example.com). Fonctionne sur iOS et Android.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL ou deep link à ouvrir (ex: myapp://home, https://example.com/page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states it opens a URL/deep link, without mentioning potential side effects (e.g., app switching, permission requirements, or error handling). This is insufficient for an action that may change app state.
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 two sentences: first explains the action, second adds platform context. It is concise and front-loaded. No unnecessary words, though it could be slightly more structured.
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 (single parameter, no output schema), the description covers the essential purpose and platform compatibility. It does not explain return behavior or errors, but for a straightforward action this is acceptable.
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 100% with description for the 'url' parameter. The description adds minimal extra meaning beyond the schema parameter description, repeating 'URL ou deep link'. Baseline 3 is appropriate.
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: 'Ouvre une URL ou un deep link dans l'app'. It specifies the resource (URL/deep link) and the verb (ouvre). The tool is distinct from siblings which focus on UI actions, testing, and device management.
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 mentions it works on iOS and Android but provides no guidance on when to use this tool versus alternatives like 'launch_app' or 'type_text'. No exclusions or prerequisite conditions are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ferme le clavier sur le device actif (iOS et Android). No-op si pas de clavier visible. À utiliser après un type_text quand le clavier bloque les boutons en bas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the no-op behavior and platform support, but does not mention animation timing or permission requirements. Given the simplicity, this is sufficient.
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, front-loaded with the action. Every word earns its place. No unnecessary detail.
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 no parameters and no output schema, the description is complete. It explains what, when (after type_text), and edge case (no-op).
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?
There are zero parameters, and schema coverage is 100%. Per guidelines, baseline for 0 parameters is 4. The description adds no parameter info, but none 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 what the tool does: closes the keyboard on the active device. It specifies platforms (iOS and Android) and mentions the no-op behavior when no keyboard is visible, which distinguishes it from other UI interaction 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 provides explicit guidance: use after type_text when the keyboard blocks bottom buttons. This tells the agent when to use this tool versus alternatives like tap or swipe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retourne l'arbre d'accessibilité de l'écran — tous les éléments visibles avec type, texte, position. Fonctionne sur iOS et Android. Chaque élément a un index [N] utilisable avec tap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the output (visible elements with type, text, position, index) and cross-platform support. No annotations exist, but the description adequately covers the read-only nature and typical usage.
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 concise sentences with no extraneous content. Each sentence serves a purpose: what it returns, platform support, and usage of indices.
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?
Without an output schema, the description sufficiently explains the return values. For a simple query tool with no inputs, the description is complete and actionable.
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; schema coverage is 100% vacuously. Description adds no param info, which is acceptable since none exist. Baseline of 4 is appropriate.
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?
Clearly states the tool returns the accessibility tree, listing visible elements with type, text, and position. Distinguishes from sibling tools like accessibility_audit and action 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?
No explicit guidance on when to use this tool versus alternatives like assert_visible or wait_for_element. Usage is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ferme une app sur le device actif.
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Bundle ID (iOS) ou package name (Android) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Ferme une app' without detailing whether it terminates the process, saves state, or affects background tasks. This is insufficient for a destructive action.
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 short sentence with no extraneous words. However, the French language may reduce clarity for English-speaking agents, and the structure does not front-load key information beyond the verb.
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 no output schema or annotations, the description is too sparse. It omits mention of success/failure indications, error conditions, or device readiness, leaving the agent underinformed.
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 100% and the schema already describes the single parameter (bundle_id). The description adds no additional meaning or usage advice, meeting the baseline for high coverage but not exceeding it.
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 ('Ferme une app') and the target ('sur le device actif'), effectively distinguishing it from sibling tools like launch_app. However, it lacks nuance such as whether it performs a graceful close or a force kill.
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 use to close an app, but provides no explicit guidance on when to use it versus alternatives, nor any mention of prerequisites or when not to use it. The context is clear but omit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lance une app sur le device actif. iOS : bundle ID (ex: com.monapp.ios). Android : package name (ex: com.monapp.android).
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Bundle ID (iOS) ou package name (Android) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the action without detailing side effects, waiting behavior, or what happens if the app is already running.
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, effectively communicates purpose and platform-specific details. Ideal 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 1-parameter tool with no output schema, the description covers purpose and input format. However, it omits behavioral details and error scenarios, leaving some gaps for an agent.
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 100%, so the schema already documents the parameter. The description adds examples but no new meaning beyond the schema's description. Baseline of 3 is appropriate.
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 launches an app on the active device, with specific instructions for iOS and Android. However, it does not explicitly differentiate from sibling tools like deep_link or kill_app.
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 platform-specific format information (bundle ID, package name) but lacks guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste tous les devices disponibles — simulateurs iOS, émulateurs Android, et vrais devices connectés. Affiche la plateforme et l'état de chaque device.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists devices and shows platform and state, which is sufficient for a read-only operation. However, it does not mention if the list is cached or refreshed.
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, front-loaded with the purpose. No wasted words. Efficiently communicates the tool's functionality.
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 description says it shows platform and state, but does not specify the return format (e.g., list of device names, types, statuses). For a tool with no output schema, this lack of detail may leave the agent uncertain about what to expect.
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 tool has no parameters, so the description is not expected to add parameter details. The schema coverage is 100% trivially, and the description does not need to compensate.
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 'devices', specifying types (simulators, emulators, real devices). It distinguishes from siblings like set_device and prepare_device by focusing on listing rather than selection or preparation.
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 you need to know available devices, but does not explicitly state when to use it versus alternatives like multi_device or prepare_device. No guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Appui long sur un élément de l'écran. Utile pour les menus contextuels, drag & drop, ou actions secondaires.
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | Index de l'élément depuis get_ui_tree | |
| x | No | Coordonnée X | |
| y | No | Coordonnée Y | |
| text | No | Texte/label de l'élément | |
| duration | No | Durée de l'appui en secondes (défaut: 1, min: 0.1, max: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'long press' without disclosing behavioral traits like duration effect, haptic feedback, or element compatibility, leaving gaps for the agent.
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, efficiently conveying purpose and use cases with no wasted words.
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 use cases provide useful context, but without an output schema or annotations, the description lacks details on return values or side effects, making it only moderately complete for a simple action 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?
Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, which already documents parameters well.
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 (long press) and resource (screen element), and provides specific use cases (context menus, drag & drop, secondary actions), distinguishing it from siblings like tap and swipe.
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 gives context for when to use (context menus, drag & drop, secondary actions) but lacks explicit guidance on when not to use or alternatives, though it's still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute la meme action sur plusieurs devices et retourne les resultats combines. Utile pour tester sur iOS + Android en une seule commande.
| Name | Required | Description | Default |
|---|---|---|---|
| device_ids | Yes | Liste des device IDs a cibler | |
| action | Yes | Action a executer sur chaque device | |
| bundle_id | No | Bundle ID / package name (requis pour launch_app/kill_app) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool runs actions on multiple devices and returns combined results, but fails to disclose behavioral traits like failure handling, concurrency, destructive potential, or rate limits. This is insufficient for a multi-device orchestration tool.
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, front-loaded with the core action. Every word serves a purpose, making it efficient for an AI agent to parse.
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?
Despite moderate complexity (multi-device execution), the description omits details like error handling, result format, synchronization semantics, and potential side effects. With no output schema or annotations, this leaves significant gaps for correct invocation and interpretation.
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 100%, with all parameters documented. The description adds minimal value by mentioning combined results, but does not elaborate on the return format or constraints beyond schema. Baseline 3 is appropriate as schema already covers parameter meaning.
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's function: executing the same action on multiple devices and returning combined results. It explicitly mentions usefulness for testing on iOS + Android in one command, distinguishing it from single-device sibling tools like launch_app or screenshot.
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 indicates when to use this tool ('for testing on iOS + Android in one command'), implying batch testing scenarios. It does not explicitly exclude alternatives or provide when-not-to-use guidance, but the context is clear enough for an AI agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prépare le device actif pour une session de test propre : dismiss keyboard, clear clipboard, reset status bar overrides, force keyboard QWERTY (iOS). Tout est opt-out via flags. Auto-appelé par set_device sauf si skip_setup=true.
| Name | Required | Description | Default |
|---|---|---|---|
| dismiss_keyboard | No | Dismiss le clavier s'il est visible (default: true) | |
| clear_clipboard | No | Vide le clipboard du device (default: true) | |
| clear_status_bar | No | Reset les overrides de status bar iOS (default: true) | |
| force_qwerty | No | Force keyboard QWERTY sur iOS, sécurité contre AZERTY (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All behavioral aspects are explicitly listed (dismiss keyboard, clear clipboard, reset status bar, force QWERTY) and the opt-out nature is stated. With no annotations, the description adequately discloses what happens during execution, though it omits potential side effects like log generation.
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 concise: three sentences covering purpose, opt-out behavior, and auto-call context. No unnecessary words or 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?
Given no output schema and all parameters fully documented, the description provides sufficient context for a simple setup tool. It explains its role relative to set_device, making the overall usage 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 100% with each parameter having clear descriptions. The tool description adds that steps are opt-out by default, which is valuable but not a significant addition to the already detailed schema.
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 prepares the active device for a clean test session, listing specific actions (dismiss keyboard, clear clipboard, etc.) and noting it is auto-called by set_device, distinguishing it from 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?
The description indicates the tool is automatically invoked by set_device unless skip_setup=true, providing clear context for when it is used. However, it does not explicitly state when to avoid direct use or compare alternatives beyond set_device.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change l'orientation de l'écran du device (portrait ou landscape).
| Name | Required | Description | Default |
|---|---|---|---|
| orientation | Yes | Orientation souhaitée |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states that the orientation changes, but fails to mention any side effects, failure modes, or device requirements (e.g., unlocked state). This is insufficient disclosure for a mutating 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?
The description is a single, well-structured sentence that front-loads the action and immediately specifies the two possible values. Every word is necessary and no extraneous information is present.
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 one parameter and no output schema. The description adequately covers purpose and parameter values. However, it lacks any mention of return behavior or confirmation, which is a minor gap.
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 100% with one parameter fully described (enum values, description). The tool description adds no extra meaning beyond what the schema already provides, meriting the baseline score of 3.
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 ('Change l'orientation') and the resource ('écran du device') with the two possible values explicitly listed in parentheses. It is distinct from sibling tools like 'tap' or 'swipe' which perform different actions.
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, prerequisites, or context. The description only states what the tool does, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prend un screenshot du device actif (iOS ou Android) et le retourne comme image.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states it returns an image, but omits details like whether it waits for a stable state, permissions required, or any side effects (e.g., screen flash). This is insufficient for a tool that interacts with a device.
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?
A single, front-loaded sentence with no redundancy. Every word contributes to understanding the tool's function.
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 (no params, no output schema), the description is mostly complete. However, specifying the return format (e.g., base64 or filename) would improve clarity. Still, it suffices for basic use.
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?
There are zero parameters, so schema coverage is 100%. The description adds no parameter-level details but does not need to. Baseline for 0 params is 4, and the description is adequate.
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 (screenshot), the target (active device, iOS or Android), and the output (as an image). It distinguishes from siblings like visual_diff or video_record, which are different operations.
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 vs. alternatives such as visual_diff or get_ui_tree. The description does not mention prerequisites or typical use cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll vers le bas (ou la direction choisie) jusqu'à trouver un élément contenant le texte donné. Retourne l'élément trouvé ou une erreur après max_scrolls.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texte de l'élément à trouver | |
| direction | No | Direction du scroll (défaut: down) | down |
| max_scrolls | No | Nombre max de scrolls (défaut: 10, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains scrolling until text found, max_scrolls limit, and return behavior, but does not elaborate on side effects, chunking, or state changes.
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, front-loaded with action and result. Every word earns its place, no fluff.
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 straightforward nature (3 params, no output schema), the description adequately explains the core behavior, though could mention the element is visible in the viewport or that scrolling occurs stepwise.
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 100%, so description does not need to add much. It mentions direction and max_scrolls but does not provide additional semantic value beyond the 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?
The description clearly states the tool scrolls (with configurable direction) to find an element containing given text, and returns the element or an error. This distinguishes it from sibling tools like tap, swipe, or wait_for_element.
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 vs alternatives (e.g., swipe for generic scrolling). The description is functional but lacks when/when-not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sélectionne le device à utiliser pour cette session de test. Si le device est éteint, il sera démarré automatiquement. Appelle list_devices d'abord pour voir les IDs. Auto-prépare le device (clear clipboard/status bar, dismiss keyboard, force QWERTY iOS) — opt-out via skip_setup=true.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | L'ID du device (UDID iOS, serial Android, ou avd:NomAVD) | |
| skip_setup | No | Si true, ne pas auto-préparer le device (clipboard/status bar/keyboard). Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Aucune annotation n'étant fournie, la description assume la charge complète. Elle révèle des comportements clés : démarrage automatique si éteint, préparation automatique (presse-papier, barre d'état, clavier), et possibilité d'opt-out. Elle ne couvre pas les erreurs ou les permissions requises.
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?
La description est concise : trois phrases qui vont à l'essentiel. La première phrase expose le but, la seconde ajoute une condition, la troisième détaille le comportement supplémentaire. Aucun mot superflu.
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?
Compte tenu de l'absence de schéma de sortie, la description couvre bien le comportement principal. Cependant, elle ne mentionne pas la valeur de retour ni la gestion des erreurs. De plus, la relation avec l'outil frère prepare_device n'est pas clarifiée, mais la description reste suffisante pour un outil de sélection.
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?
La couverture du schéma est de 100 %, et les descriptions des paramètres dans le schéma sont détaillées. La description n'ajoute pas de sens au-delà du schéma pour les paramètres, mais elle contextualise leur utilisation (ex. skip_setup pour désactiver la préparation). Note de base 3 suffisante.
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?
La description indique clairement que l'outil sélectionne le device pour la session de test, avec des détails sur le démarrage automatique et la préparation. Elle distingue l'outil des frères en mentionnant l'auto-préparation et l'option skip_setup.
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?
La description donne des instructions explicites : appeler list_devices d'abord pour obtenir les IDs, et mentionne l'option skip_setup pour désactiver la préparation automatique. Elle ne précise pas quand ne pas utiliser l'outil, mais les directives sont suffisantes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simule un geste de shake sur le device. iOS : via raccourci Simulator (Ctrl+Cmd+Z). Android : swipes rapides.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the underlying mechanism (shortcut vs. swipes), adding value beyond 'shake'. However, it doesn't mention potential side effects, limitations (e.g., on iOS only in Simulator), or expected UI consequences.
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 concise sentences, no filler, front-loaded with action. Every sentence 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?
For a parameterless tool with no output schema, the description is complete enough: it states purpose and platform-specific execution. Could mention environment requirements (e.g., iOS Simulator only) but overall sufficient.
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?
Input schema has 0 parameters, so baseline is 4. Description doesn't need to add parameter info; it correctly omits any param 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?
Description clearly states 'Simule un geste de shake' (simulates a shake gesture), which is a specific verb+resource. It is distinct from sibling tools like swipe, tap, etc.
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 platform-specific methods (iOS shortcut, Android swipes), giving clear instructions on how to trigger the shake. However, it does not explicitly state when to use it vs alternatives, though the niche gesture makes context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fait un geste de swipe sur l'écran. Fonctionne sur iOS et Android.
| Name | Required | Description | Default |
|---|---|---|---|
| direction | Yes | Direction du swipe | |
| distance | No | Distance du swipe | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It fails to mention starting position, duration, or effect on UI elements. The description is too sparse to guide the agent on tool behavior.
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 short, clear sentences with no superfluous information. Every word contributes to understanding the tool's basic function.
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 only two parameters and no output schema. The description is adequate for a basic gesture but lacks details like coordinate point or effect on UI, which could be inferred from sibling tool names.
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 covers both parameters with enum descriptions (100% coverage). The description adds no extra value beyond confirming the gesture direction and distance. Baseline 3 is appropriate since no additional context 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 the action (swipe gesture on screen) and platform compatibility (iOS and Android). However, it does not differentiate from sibling tools like tap or scroll, missing a chance to clarify its specific purpose.
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 swipe versus alternatives such as tap, long_press, or scroll. The description provides no context about typical use cases or 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.
Tape sur un élément de l'écran. Fonctionne sur iOS et Android. Utilise index (du get_ui_tree), coordonnées (x,y), ou texte. Auto-dismiss le clavier si la cible est physiquement masquée par lui (sécurité, pas de retap nécessaire).
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | Index de l'élément depuis get_ui_tree | |
| x | No | Coordonnée X pour tap direct | |
| y | No | Coordonnée Y pour tap direct | |
| text | No | Texte/label de l'élément à taper | |
| auto_dismiss_keyboard | No | Si la cible est masquée par le clavier, le dismiss avant de tap (default: true). Mettre à false pour permettre le tap directement sur le clavier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait: auto-dismissal of the keyboard if the target is masked by it, which is not fully captured by the parameter default. However, it does not describe error handling, what happens when multiple identification methods are provided, or the return value (no output schema). With no annotations, the description carries the burden but covers only partial behavior.
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 concise with three sentences, front-loading the purpose. Each sentence adds a distinct piece of information (action, platform, methods, keyboard behavior). There is no redundancy or unnecessary detail.
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 tap tool with 5 parameters and no output schema, the description provides adequate core context but misses details like coordinate system (absolute vs relative), recommended identification method priority, and conflict resolution. The sibling tools list includes related gestures, but the description does not clarify when to use tap over long_press or swipe.
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 100% description coverage, so the baseline is 3. The description adds that 'index' comes from get_ui_tree, which is helpful, but this is implicit from the schema description. The auto-dismiss keyboard default is also described in the schema. The description does not add significant new meaning beyond the schema.
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 (tap), the target (element of screen), and three identification methods (index, coordinates, text). It also specifies platform support (iOS and Android). However, it does not explicitly distinguish this tool from siblings like long_press or swipe, though the verb 'tap' implies the basic action.
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 long_press, swipe, or type_text. It does not mention prerequisites, limitations, or scenarios where this tool is inappropriate. The user must infer usage from the tool's name and basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gère le rapport de test automatique. Le rapport démarre AUTOMATIQUEMENT dès la première interaction (tap, type_text, etc.) — tu n'as PAS besoin d'appeler 'start'. Appelle UNIQUEMENT action='end' quand tu as fini de tester pour générer le rapport markdown. Si tu veux nommer le rapport, appelle action='start' avec un nom AVANT de commencer.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 'start' pour commencer le suivi automatique, 'end' pour générer le rapport | |
| name | No | Nom du test (requis pour 'start') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic start behavior and the effect of calling start with a name. With no annotations, the description covers the key behavioral traits, though could mention error handling or multiple start calls.
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 concise sentences in French, front-loaded with the automatic start key point. No redundant information; every sentence adds value.
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 two parameters and no output schema, the description fully explains usage. It mentions markdown report generation and when to use each action, leaving no ambiguity.
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 100% and description adds context: clarifies that name is required for start despite schema not marking it required, and explains the purpose of each action.
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 manages the automatic test report, specifies the automatic start on first interaction, and distinguishes the start and end actions. It is specific about when to use each action and the report generation behavior.
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?
Explicitly instructs not to call start unless naming the report, and to only call end to generate the report. Provides clear context for when each action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Écrit du texte dans un champ. Fonctionne sur iOS et Android. Peut cibler un champ par son label/texte. Avec verify=true (opt-in), re-lit le champ après le type pour détecter les pickers d'autocomplete qui interceptent les keystrokes.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Le texte à taper | |
| element_text | No | Label ou texte du champ à cibler | |
| clear_first | No | Effacer le champ avant de taper | |
| verify | No | Re-lire le champ après le type pour confirmer la valeur. Détecte les autocomplete-pickers qui interceptent. Coûte ~200ms supplémentaires (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behaviors: works on both platforms, targeting by label/text, verify's effect and extra cost (~200ms). However, omits details on error handling, special characters, or what happens if element is not found. With no annotations, the description carries the full burden but doesn't cover all edge cases.
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 concise sentences that front-load the main action and platform support, then add detail on targeting and verify. Every sentence is informative with no wasted words.
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 moderate complexity (4 params, simple input), the description covers the core use cases and key feature (verify). Lacks some edge case details but is sufficient for typical usage. No output schema required, so completeness 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 coverage is 100%, so description adds limited value. It repeats the verify behavior already in the schema. The description's mention of 'target a field by its label/text' adds context for element_text but is not significantly beyond the schema's 'Label ou texte du champ à cibler'.
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?
Clearly states 'writes text in a field' with specific verb and resource. Distinguishes from sibling tools like tap, swipe, long_press by focusing on text input. Also notes cross-platform support (iOS and Android).
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 context for when to use: typing into fields, targeting by label, and using verify for autocomplete detection. Lacks explicit when-not-to-use or prerequisites (e.g., field must be focused), but the sibling set implies alternatives for other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enregistre une vidéo de l'écran du device. Utilise action='start' pour commencer et action='stop' pour arrêter et récupérer le fichier.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 'start' pour commencer l'enregistrement, 'stop' pour arrêter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the start/stop workflow and that stop retrieves a file. However, it does not mention potential side effects (e.g., performance impact, permission requirements) or behavior if actions are misused.
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 two sentences, both front-loaded and concise. The first sentence states the purpose, the second explains usage—no extraneous words.
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 no output schema, the description is fairly complete: it explains the workflow and the two actions. It could mention what file is returned or any limitations, 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?
The input schema already has a description for the action parameter, and the description merely restates that information. With 100% schema coverage, the description adds no new semantic meaning beyond what the schema provides.
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 records a video of the device screen, which is a specific verb and resource. This distinguishes it from sibling tools like screenshot or visual_diff, which capture images rather than videos.
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 explains the two-step process (start and stop) for using the tool, providing clear instructions. However, it does not mention when to use this tool versus alternatives like screenshot, nor does it specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare deux screenshots pour detecter des regressions visuelles. action='snapshot' pour sauver une reference, action='compare' pour comparer avec la reference.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 'snapshot' pour sauver, 'compare' pour comparer | |
| name | No | Nom du snapshot (defaut: 'default') | default |
| threshold | No | Seuil de diff en % pour considerer PASS (defaut: 0.1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention what the tool returns or any side effects (e.g., if it modifies state). This is a significant gap for a tool that mutates reference images.
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 concisely written in two sentences, front-loading the purpose and explaining the two actions without unnecessary words.
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 has 3 parameters and no output schema, the description covers the two actions but lacks information on the output (e.g., pass/fail, diff image) and how it fits with sibling tools like 'screenshot' or 'assert_visible'. It is minimally adequate but leaves room for improvement.
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 100%, so the schema already documents all parameters. The description adds minimal value beyond the schema by giving brief context for 'action' values, but does not elaborate on 'name' or 'threshold' beyond what the schema provides.
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 that the tool compares two screenshots for visual regressions and distinguishes the two modes (snapshot and compare). This provides a specific verb and resource, and differentiates from sibling tools like 'screenshot'.
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 clear guidance on when to use each action ('snapshot' to save a reference, 'compare' to compare with the reference). However, it lacks explicit guidance on when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attend qu'un élément apparaisse à l'écran (utile après navigation ou chargement). Retourne l'élément trouvé ou une erreur après timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texte, label ou nom de l'élément à attendre | |
| timeout | No | Timeout en secondes (défaut: 10, max: 120) | |
| interval | No | Intervalle en secondes (défaut: 1, max: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions waiting, returning element or error, but lacks details on polling behavior or exception handling. Adequate but not rich.
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 short, clear sentences with no fluff. Front-loaded with the core action and usage context.
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 3 parameters, no output schema, and no annotations, the description covers purpose, usage, and return value. Could detail edge cases but sufficient for most use.
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 100% with clear parameter descriptions. The description adds little beyond what the schema already provides, so baseline score of 3 is appropriate.
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 waits for an element to appear on screen, useful after navigation or loading, and returns the element or error after timeout. It distinguishes from siblings like assert_visible which may not wait.
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 usage context ('utile après navigation ou chargement'), indicating when to use. It does not explicitly list alternatives or when not to use, but it's implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action: tap, long_press, swipe, type_text, etc. Even similar tools like assert_visible and assert_not_visible are clearly opposites. No functional overlap.
All tool names use lowercase snake_case, with a mix of verb-first and noun-first constructions (e.g., 'accessibility_audit' vs 'assert_visible'), but the pattern is largely predictable and readable.
24 tools is slightly high but well-scoped for mobile testing: device management, UI interaction, assertions, visual testing, reporting, and gestures are all covered. Each tool has a clear purpose.
The set covers core workflows: device setup, UI queries, interactions, assertions, screenshots/video, and reporting. Missing explicit drag-and-drop or back navigation, but swipe and long_press compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for Appcircle mobile CI/CD platform.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Cloud iOS simulators and Android emulators your agent can create, drive, and throw away.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nthImpulse/phantom-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
