MCP-сервери для React Native у 2026 році: DevTools, дебагери і що насправді потрібно вашому агенту
clear_logsget_logsget_pressable_elementsios_screenshotscan_metrosearch_logsswipetap
MCP-сервер для React Native це міст між вашим AI-агентом і запущеним застосунком. MCP (Model Context Protocol) це стандарт, що дозволяє інструментам на кшталт Claude Code, Cursor і Windsurf викликати зовнішні інструменти; MCP-сервер для React Native відкриває те, що ви зазвичай робите вручну під час налагодження (читаєте консоль, стежите за мережевими запитами, проклацуєте екрани, робите скриншоти), як інструменти, які агент може викликати сам.
Без нього агент налагоджує наосліп. Він редагує код, а потім просить вас запустити застосунок, проклацати відтворення й вставити назад усе, що надрукував термінал Metro. З ним агент проходить цей цикл сам: діє на пристрої, спостерігає результат, читає докази, виправляє, перевіряє.
Якщо ви шукали "react native devtools mcp" або "react native mcp", то, мабуть, знайшли з пів дюжини репозиторіїв на GitHub зі схожими назвами й без чіткого розуміння, чим вони відрізняються. Цей посібник розповідає, що насправді потрібно для повного циклу налагодження, що вміють open-source сервери, про які варто знати, і де кожен із них зупиняється, а також показує справжнє, не змонтоване демо повного циклу з ExecBro.
Що потрібно для повного циклу налагодження
Перш ніж порівнювати інструменти, варто точно визначити, що означає «налагодження з агента». Циклу «виправити й перевірити» на справжньому пристрої потрібні шість можливостей:
- Бачити екран. Скриншоти, а в ідеалі структурований вигляд того, що відрендерено, щоб агент знав, де він.
- Діяти на пристрої. Тап, свайп, введення тексту. Читати логи марно, якщо відтворення досі має проклацувати людина.
- Читати консоль. Логи з фільтрацією й пошуком, а не сирий дамп, що заливає контекстне вікно агента.
- Досліджувати мережу. Які запити пішли, з якими даними й відповідями, а для тестування шляхів помилок ще й можливість мокати відповіді чи імітувати офлайн.
- Досліджувати стан і компоненти. Дерево компонентів, props і стан застосунку (Redux чи інший), щоб агент міг перевірити, у що вірить UI, а не лише що він показує.
- Працювати на обох платформах без змін у застосунку. iOS і Android, з підключенням до вже запущеного застосунку, без потреби спершу встановлювати нативні модулі.
Сервер, що покриває лише одну-дві з цих можливостей, усе одно допомагає, але цикл рветься там, де можливості бракує: агент читає помилку, а потім віддає керування вам, щоб ви її відтворили.
Open-source MCP-сервери для React Native
Це проєкти, що зараз займають результати пошуку "react native mcp". Усі вони справжні й корисні; різниця в тому, яку частину циклу покриває кожен.
metro-mcp
steve228uk/metro-mcp (metromcp.dev) найповніший із серверів спільноти. Він побудований на плагінах, знаходить Metro скануванням портів і під’єднується до Hermes через Chrome DevTools Protocol, що дає йому дуже багато без змін у коді застосунку: збір логів консолі й помилок, моніторинг мережі з тілами відповідей, перегляд стану Redux і dispatch, інспекцію дерева React fiber, аудити accessibility, читання AsyncStorage, профілювання CPU і heap, автоматизацію UI (тап, свайп, введення тексту) і запис взаємодій у тести Appium, Maestro чи Detox. Працює з Expo і чистим React Native, зокрема з фізичними пристроями через USB, а необов’язковий хук __METRO_BRIDGE__ додає власні команди й відкриття стану.
Де зупиняється: на момент написання задокументовані можливості не містять скриншотів, тож агент діє, не перевіряючи візуально, куди потрапив, а мокання мережі чи імітації умов для тестування шляхів помилок немає.
react-native-debugger-mcp
twodoorsdev/react-native-debugger-mcp під’єднується до дебагера вашого застосунку через Metro й отримує логи консолі в реальному часі. Налаштування це один запис npx у конфігурації MCP.
Де зупиняється: це читач логів (без скриншотів, без взаємодії, без мережі), а репозиторій відтоді заархівовано на GitHub, тож його більше не підтримують. Він і далі працює як мінімальний варіант «дати агенту бачити консоль», але виправлень чи оновлень не чекайте.
Limelight
getlimelight/limelight-sdk (getlimelight.io) іде шляхом SDK: ви встановлюєте @getlimelight/sdk у застосунок і отримуєте інспекцію стану для Zustand і Redux, моніторинг мережі з першочерговою підтримкою GraphQL, трансляцію консолі зі стеками викликів, відстеження рендерів і наскрізне трасування через серверний middleware, а зверху інтеграцію MCP для агентів.
Де зупиняється: це спостереження через SDK у застосунку, тож ні скриншотів, ні взаємодії, і все залежить від того, чи вбудуєте ви їхній код у свій застосунок. До того ж на момент написання в репозиторії не було комітів із березня 2026 року, а в цій категорії це фактично покинутий проєкт, а не пауза. Інструмент налагодження стоїть на рухомому стеку: нові релізи React Native, зміни в Hermes і Bridgeless, оновлення ОС і симуляторів і довгий хвіст особливостей пристроїв. Інструменти в цій ніші лишаються коректними лише завдяки постійній підтримці (саме тому ExecBro випускає виправлення майже щодня), тож інспектор, замерзлий на п’ять місяців, може не лише не мати функцій, а й показувати вивід, що тихо бреше. Коли ми самі спробували Limelight, у десктопному застосунку вже були помітні баги, і відтоді нічого не вийшло.
Reactotron MCP
Reactotron, давній інспектор RN від Infinite Red, тепер відкриває MCP-сервер, щоб агенти могли читати його таймлайн: події, стан, мережеву активність і власні команди, надіслані застосунку.
Де зупиняється: він успадковує модель Reactotron, тобто спершу треба встановити й налаштувати reactotron-react-native у застосунку. Він спостерігає те, що повідомляє клієнт Reactotron; взаємодія з екраном і скриншоти поза його межами.
Порівняння можливостей
| Можливість | ExecBro | metro-mcp | react-native-debugger-mcp | Limelight | Reactotron MCP |
|---|---|---|---|---|---|
| Логи консолі (фільтр/пошук) | ✅ | ✅ | ✅ | ✅ | ✅ |
| Скриншоти | ✅ iOS + Android | ❌ | ❌ | ❌ | ❌ |
| Тап / свайп / введення тексту | ✅ зокрема за testID |
✅ | ❌ | ❌ | ❌ |
| Запит елементів, які можна натиснути | ✅ | ❌ | ❌ | ❌ | ❌ |
| Інспекція мережі | ✅ | ✅ | ❌ | ✅ | ✅ |
| Мокання мережі / імітація офлайну | ✅ | ❌ | ❌ | ❌ | ❌ |
| Дерево компонентів / інспекція | ✅ | ✅ | ❌ | частково | частково |
| Стан застосунку (Redux тощо) | ✅ | ✅ | ❌ | ✅ | ✅ |
| Виконання JS у застосунку | ✅ | через __METRO_BRIDGE__ |
❌ | ❌ | власні команди |
| Працює без змін у коді застосунку | ✅ (SDK необов’язковий) | ✅ (bridge необов’язковий) | ✅ | ❌ потрібен SDK | ❌ потрібен клієнт |
| Керування пристроями (запуск симулятора, застосунку) | ✅ | ✅ | ❌ | ❌ | ❌ |
| Кілька пристроїв в одній сесії | ✅ вибір device у кожному інструменті |
❌ один застосунок на сесію | ❌ | ❌ | ✅ вибір підключеного застосунку |
Таблицю складено за публічною документацією кожного проєкту в серпні 2026 року; відкрийте issue, якщо щось змінилося.
Закономірність така: більшість серверів обирають одну половину циклу. Спостерігачі (логи, мережа, стан) не дають агенту нічого відтворити, а навіть найширший із них керує екраном, якого не бачить: без скриншотів і карти елементів, які можна натиснути, кожна дія робиться наосліп. ExecBro створено як увесь цикл в одному сервері, і це простіше показати, ніж довести, тож ось як це виглядає насправді.
Цикл на практиці з ExecBro
Усе нижче це не змонтований вивід сесії на симуляторі iOS (відео вище з тієї самої сесії). Завдання: перейти на екран, якого ще навіть не видно, а потім чисто й надійно перехопити на ньому логи. Ніхто жодного разу не торкається пристрою.
Підключитися. Один виклик під’єднує сервер до всього, що запущено:
mcp__execbro__scan_metro {"startPort": 8090, "endPort": 8090}Metro scan results:
Port 8090: Found 1 device(s)
- Connected to org.reactjs.native.example.RnDebuggerTestApp (iPhone 14)
Подивитися. Скриншот показує, де застосунок насправді:
mcp__execbro__ios_screenshot {"udid": "A4287B5C-5156-40B1-86F9-32CD855FBD4A"}
Скласти карту екрана замість того, щоб вгадувати координати. Саме тут сервер, що розуміє React, відрізняється від сліпої автоматизації за координатами:
mcp__execbro__get_pressable_elements {}Found 20 pressable elements (3 icon-only, 17 with text labels)
1. HeaderMenuButton "☰" — center:(92,164) frame:(47,128 88x71) [a11y="Open navigation …"]
Потрібного екрана, Diagnostics, у списку немає, а отже, його ще немає на екрані. Тож агент робить свайп смугою навігації, перечитує карту й тепер натискає ціль за testID, а не за позицією в пікселях:
mcp__execbro__tap {"testID": "screen-nav-Diagnostics", "screenshot": false}{
"success": true,
"method": "accessibility",
"query": {"testID": "screen-nav-Diagnostics"},
"pressed": "Diagnostics"
}Прочитати докази. Очистити буфер, запустити відтворення (три тапи, що створюють log, warn і error), а потім прочитати рівно те, що сталося:
mcp__execbro__get_logs {"summary": true}Log Summary (SDK):
Total logs: 3
By Level:
log: 1
warn: 1
error: 1
mcp__execbro__get_logs {"level": "error"}Console Logs (1 entries, SDK):
9:56:52 PM [error] [playground] error log
Подивитися, діяти, подивитися знову, прочитати. Агент пройшов увесь цикл, і жодна людина не торкалася ні симулятора, ні термінала Metro. Туторіал про логи консолі крок за кроком розбирає цю сесію, а туторіал про мокання мережі показує те, чого не пробує жоден інший сервер на цій сторінці: примусово отримати 500, зіпсоване тіло відповіді чи режим польоту, щоб ваша справжня обробка помилок справді спрацювала.
Крім циклу вище, ExecBro покриває й решту можливостей із таблиці порівняння: інспекцію дерева компонентів, читання стану Redux і dispatch, виконання JS у застосунку, перевірку помилок бандла, OCR на скриншотах, а також запуск симуляторів і застосунків, щоб агент міг почати з холодної машини.
І він не обмежений одним пристроєм. scan_metro одразу підключає кожен симулятор і емулятор, що працює з цільовим екземпляром Metro, логи й мережеві запити буферизуються для кожного пристрою окремо, а кожен інструмент приймає параметр device, тож одна сесія агента може керувати симулятором iPhone і емулятором Android пліч-о-пліч і спрямовувати кожну дію куди треба. Так перевіряють виправлення на обох платформах в одній розмові, а не у двох.
Поширені питання
Чи є офіційний MCP-сервер React Native DevTools?
Ні. Основна команда React Native постачає React Native DevTools (дебагер на основі Chrome DevTools, що з’явився у 0.76), але це графічний інтерфейс для людини, а не MCP-сервер. Усе в ніші MCP, зокрема ExecBro, це незалежні інструменти, що під’єднуються до тих самих базових поверхонь (Metro, Hermes, пристрій).
Чи треба змінювати код застосунку?
Для більшості серверів на цій сторінці, зокрема ExecBro, ні: вони під’єднуються до запущеного застосунку через Metro і набір інструментів платформи. Необов’язковий SDK ExecBro додає перехоплення того, чого не видно ззовні, наприклад виводу консолі, залогованого до підключення агента, але нічого його не вимагає. Винятки це MCP від Reactotron і Limelight, бо кожному потрібен налаштований у застосунку клієнтський SDK.
Чи працює це з Claude Code, Cursor і Windsurf?
Так. У цьому й суть MCP: будь-який агент із підтримкою MCP може користуватися будь-яким із цих серверів. ExecBro це один запис npx у конфігурації MCP вашого агента; посібник з налаштування охоплює Claude Code, Claude Desktop, Cursor, Windsurf, Zed та інші.
Лише симулятор чи справжні пристрої?
ExecBro працює із симуляторами iOS, емуляторами Android і фізичними Android-пристроями через adb. Механіка скриншотів і взаємодії відрізняється залежно від платформи, але набір інструментів однаковий.
Скільки це коштує?
Сервери спільноти вище мають відкритий код. ExecBro теж безкоштовний, з усіма інструментами на безкоштовному тарифі в межах місячного ліміту використання; Pro знімає ліміт для необмеженої кількості викликів інструментів.
Як обрати
Якщо вам потрібне широке спостереження на основі CDP, доступ до стану й профілювання, metro-mcp це добре зроблений проєкт зі справжнім розвитком. Якщо ваша команда вже користується Reactotron, його MCP-сервер стане природним доповненням. Сервери лише для логів дозволяють почати найшвидше, але найвідоміший із них, react-native-debugger-mcp, уже заархівовано, і це варто зважити, перш ніж будувати на ньому робочий процес.
Якщо вам потрібен цикл, у якому агент бачить екран, керує ним за testID, читає логи й мережу, примусово проходить шляхи помилок і перевіряє власне виправлення, то саме цю прогалину й закриває ExecBro. Обидва туторіали за посиланнями вище це справжні записані сесії, тож ви можете оцінити цикл за доказами, а не за списком функцій.