Это моя текущая подборка на момент написания поста. Всё может измениться: что-то отключу, что-то добавлю, что-то найду лучше. MCP-стек — это живая история, не разовая настройка.
Что у меня сейчас подключено в Claude Code:
👉 google-dev-knowledge — документация Google для разработчиков прямо в контексте. Для Android критично: без него модель регулярно выдаёт устаревший или несуществующий API.
👉 Ref — поиск по технической документации с минимальным расходом токенов. В отличие от Context7, не тащит сразу 10k токенов — ищет точечно и читает конкретные страницы по мере необходимости.
👉 DeepWiki — AI-генерируемая wiki по любому публичному GitHub-репозиторию. Когда нужно разобраться в архитектуре незнакомой библиотеки — быстрее, чем читать исходники.
👉 Context7 — подтягивает актуальную, версионированную документацию по конкретным библиотекам прямо в промпт.
👉 maven-mcp — актуальные версии зависимостей из Maven Central. Больше не нужно идти на сайт проверять, что сейчас stable. Собственная разработка
👉 Playwright — автоматизация браузера. Использую когда нужно что-то распарсить или автоматизировать сценарии.
👉 Xcode MCP — сборка, тестирование и работа с симулятором прямо из Claude. Нужен XCode 26.3
👉 IDEA MCP — официальный плагин JetBrains, встроен в IDE начиная с 2025.2. Позволяет Claude работать с открытым проектом напрямую.
👉 Claude-in-mobile - взаимодействие с эмуляторами и устройствами для проверки работы приложений. Фактически выполняет то, что делает тестировщик руками.
Три базы документации одновременно — осознанно. Они покрывают разные ситуации: Context7 — когда знаешь библиотеку и хочешь свежую документацию по ней, DeepWiki — когда нужно понять незнакомый репозиторий целиком, Ref — когда важна точность и экономия контекста. На практике пересекаются редко, модель сама выбирает нужный инструмент. Если бы выбирал минимальный набор — оставил бы Ref и DeepWiki.
И главное правило, которое я для себя вывел: не подключай всё подряд сразу. Подключай MCP/плагины по мере нехватки — почувствовал, что постоянно даёшь модели одну и ту же информацию вручную, вот тогда и смотри. И помни: всегда можно написать маленький свой MCP поверх любого инструмента, если готового нет.
#Claude #MCP #AndroidDev #AI
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14👎8💩6🤡2
Forwarded from Compose Broadcast
Media is too big
VIEW IN TELEGRAM
Tracey записывает все жесты, переходы между экранами и кастомные события в кольцевой буфер — и при краше сохраняет его для воспроизведения. Видишь не просто стектрейс, а весь путь пользователя до момента падения.
Не сразу понял куда её применить, но пришла идея интеграции в флоу автоматического прокликивания экрана:
Разрабатываешь фичу локально, кликаешь руками, что-то идёт не так. Вместо того чтобы объяснять разработчику или агенту на словах "я нажал сюда, потом перешёл туда, потом кнопка не сработала" — просто скидываешь ему дамп сессии из Tracey. Он сам восстанавливает картину и сразу работает с контекстом, а не с твоим пересказом.
Структурированный контекст для дебаг-сессии с агентом, чтобы дать четкую информацию.
Библиотека на версии 0.0.2, только вышла, в продакшен пока не потащу. Но для этапа разработки и связки с AI-агентами идея выглядит рабочей.
#Compose #Android #AndroidDev
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12👎5🔥4
GitHub
GitHub - AlexGladkov/claude-in-mobile: MCP server for mobile and desktop automation — Android (via ADB), iOS Simulator (via simctl)…
MCP server for mobile and desktop automation — Android (via ADB), iOS Simulator (via simctl), and Desktop (Compose Multiplatform). Like Claude in Chrome but for mobile devices and desktop apps - Al...
Даёшь задание: "проверь, что пользователь может залогиниться и попасть на главный экран". Агент берёт эмулятор, прокликивает приложение, сообщает что получилось. Примерно так работает claude-in-mobile.
Это MCP-сервер, который подключает Claude Code к Android-эмулятору, iOS Simulator, десктопным приложениям и браузеру. Агент видит экран, может тапать, свайпать, вводить текст, читать UI-дерево — и делает это по твоим инструкциям на обычном языке, без тест-скриптов.
Отдельно стоит отметить: уже есть поддержка Aurora OS. Для тех, кто разрабатывает под российскую мобильную платформу — агент умеет работать и с ней.
Сценарий простой:
👉 описываешь что нужно проверить
👉 агент прокликивает
👉 возвращает результат
Полезно для smoke-тестирования через агента, исследования приложения перед написанием автотестов или чтобы не переключаться между терминалом и эмулятором руками.
Проект открыт к участию сообщества — если есть идеи что добавить или доработать, создавайте issues в репозитории. PR тоже приветствуются.
#MCP #ClaudeCode #AndroidDev #AuroraOS #iOS #AI #ИИ
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16👎10
Из каждой сессии с ИИ выносить не только код, но и правила
Случай из реальной работы. Crashlytics поймала краш. OTP-ресивер на Android 13 падает с NullPinterException. Отдал агенту на фикс. Он разобрал, нашёл место и сразу говорит:
Даже комментарий в коде аккуратно оставил. Формально всё верно. Именно это я и попросил сделать - исправить креш. Только он не пытался разобраться. Просто закрыл симптом и пошёл дальше. Краш исчезнет, но приложение от этого работать правильнее не станет.
Я сказал: подожди, давай поймём, что здесь происходит на самом деле.
Агент пошёл глубже и нашёл: баг самой платформы,
Первый вариант убрал бы краш. Но OTP молча перестал бы приходить на всех Android 13. Тихий отказ, невидимый в мониторинге. Хуже краша 💥
Но вот что я стал делать после того, как мы разобрались - сохранение подхода как правила для работы с багом. Говорю агенту:
Он записал: чини причину, а не симптом; defensive-обёртка только поверх устранённой причины; проглоченная ошибка обязана логироваться. В следующей сессии он это уже знает. Надеюсь...
Вот так и работает эволюция харнесса. Не надеяться, что агент сам что-то вынесет и запомнит. А в конце каждой нетривиальной сессии спрашивать себя: есть здесь урок о подходе? Если есть - фиксируй в правила. Именно так, на конкретных кейсах, харнесс становится твоим.
Код стареет. Правила копятся. Не забывайте их актуализировать со временем!
#AI #AndroidDev
Случай из реальной работы. Crashlytics поймала краш. OTP-ресивер на Android 13 падает с NullPinterException. Отдал агенту на фикс. Он разобрал, нашёл место и сразу говорит:
Дядя Федор, это всё потому что у тебя нету обертки в try/catch
Даже комментарий в коде аккуратно оставил. Формально всё верно. Именно это я и попросил сделать - исправить креш. Только он не пытался разобраться. Просто закрыл симптом и пошёл дальше. Краш исчезнет, но приложение от этого работать правильнее не станет.
Я сказал: подожди, давай поймём, что здесь происходит на самом деле.
Агент пошёл глубже и нашёл: баг самой платформы,
b/232589966. getParcelableExtra(key, Class) на API 33 кидает NPE, а наш код звал его с порога TIRAMISU (33), ровно на сломанной версии. Настоящий фикс: поднять до UPSIDE_DOWN_CAKE (34). try/catch оставить страховкой с логом, не фиксом.Первый вариант убрал бы краш. Но OTP молча перестал бы приходить на всех Android 13. Тихий отказ, невидимый в мониторинге. Хуже краша 💥
Но вот что я стал делать после того, как мы разобрались - сохранение подхода как правила для работы с багом. Говорю агенту:
хорошо, а теперь занеси этот подход в глобальные правила
Он записал: чини причину, а не симптом; defensive-обёртка только поверх устранённой причины; проглоченная ошибка обязана логироваться. В следующей сессии он это уже знает. Надеюсь...
Вот так и работает эволюция харнесса. Не надеяться, что агент сам что-то вынесет и запомнит. А в конце каждой нетривиальной сессии спрашивать себя: есть здесь урок о подходе? Если есть - фиксируй в правила. Именно так, на конкретных кейсах, харнесс становится твоим.
Код стареет. Правила копятся. Не забывайте их актуализировать со временем!
#AI #AndroidDev
👍43👎7