Local-first платформа, которая даёт AI-агентам настоящий «большой палец» на мобильных устройствах.
中文 | English
Локальная, кроссплатформенная платформа Skills для мобильных устройств, ориентированная на AI-агентов.
Проект завершил ITER-0052 Desktop Device Screen & Live Observation: рабочая панель настольного компьютера при выполнении задач агента показывает панель экрана устройства, обновляя реальные скриншоты после действий в каждом раунде; отчёт о задаче можно разворачивать по раундам для просмотра скриншотов-доказательств. В Runtime добавлена конечная точка только для чтения GET /v1/artifacts/{artifact_id}/content (аутентификация Bearer token, только скриншоты PNG, максимум 8 MiB на файл, no-store), событие task.step_completed несёт screenshot_artifact_id этого раунда.
Рабочая панель настольного компьютера (Tauri 2) автоматически запускает и аутентифицирует локальный Runtime, главная страница показывает унифицированную диагностику готовности и список обнаруженных устройств, поддерживает отправку задач на естественном языке, временную шкалу выполнения и полные отчёты. Разработка настольной части описана в apps/desktop/README.md. Используйте Python 3.11+:
make check
make runRuntime по умолчанию прослушивает 127.0.0.1:8765, предоставляя /v1/health, /v1/devices и POST /v1/devices/{device_id}/observe.
Related MCP server: Android MCP Server
При локальной приёмке на реальном устройстве в macOS + Codex настольном клиенте можно использовать скрипт в один клик:
./scripts/run-mcp-preview.zshПри первом запуске скрипт запросит ввод ключа модели и сохранит ключ модели и стабильный локальный токен Runtime отдельно в связку ключей macOS; при последующих запусках запрос не повторяется. Скрипт безопасно останавливает старый mobile_agent.api.server, занимающий целевой порт, повторно использует неизменённую регистрацию MCP и запускает новый Runtime. Codex/ChatGPT, если уже запущен, не нужно закрывать или перезапускать. Только при первой регистрации, явном --refresh-mcp, изменении конфигурации MCP или Tool Catalog запущенному Codex потребуется один перезапуск и создание новой задачи для обновления кэшированной среды MCP; обычный перезапуск Runtime не требуется.
Ключ модели попадает только в Keychain и окружение процесса Runtime, не записывается в репозиторий или вывод скрипта. Скрипт остаётся на переднем плане, остановка Runtime по Ctrl+C. Если нужно только проверить пути Python, ADB, Codex и конфигурацию модели, не читая ключи и не изменяя конфигурацию MCP, используйте:
./scripts/run-mcp-preview.zsh --checkЕсли нужно принудительно обновить регистрацию MCP или удалить предварительный Secret:
./scripts/run-mcp-preview.zsh --refresh-mcp
./scripts/run-mcp-preview.zsh --forget-secretsОбновление регистрации не ротирует токен в Keychain. Если целевой порт занят другой программой, скрипт откажется от случайного завершения; он автоматически останавливает только процессы, явно принадлежащие mobile_agent.api.server в командной строке.
Чтобы Web, CLI и MCP использовали один и тот же Runtime, запустите сервис с явным локальным токеном:
MOBILE_AGENT_API_TOKEN=<local-random-token> \
MOBILE_AGENT_ADB_PATH=/usr/local/platform-tools/adb \
make runЗатем настройте stdio Server в MCP Host, используя тот же токен. Пример см. в mcp-server.example.json. Команда, которую фактически запускает MCP Host:
PYTHONPATH=runtime \
MOBILE_AGENT_API_TOKEN=<same-local-random-token> \
python3.11 -m mobile_agent.mcpMCP предоставляет целевые Tools, охватывающие диагностику готовности, проверку устройств и установленных приложений, жизненный цикл приложений, асинхронные задачи агента, запрос/отмену задач, деидентифицированные журналы, агрегированные снимки производительности, диагностические пакеты доказательств, сравнение производительности и локальную очистку хранения Artifact. Он не предоставляет ADB, произвольный Shell, произвольные пути файлов или атомарные Tools, такие как input.tap. Действия, требующие подтверждения, разрешены только после того, как MCP Host показал пользователю параметры и влияние и получил подтверждение, разрешено передавать confirmed=true.
После запуска можно просмотреть унифицированную диагностику готовности:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.runtime_diagnoseGET /v1/readiness и Web UI показывают Android Gateway, подключение/авторизацию устройств, Session, занятость Lease и рекомендации по исправлению. Если ADB не установлен или путь неверен, Runtime всё равно запускает диагностический интерфейс и больше не выходит напрямую с ADB_NOT_FOUND.
Просмотр текущих возможностей, рисков, требований к подтверждению и ограничений одного устройства:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_inspect <device_id>MCP также предоставляет только для чтения mobile_list_apps и mobile_inspect_app для ограниченного перечисления идентификаторов приложений и запроса версии, источника установки и статуса включения одного приложения. Они не возвращают пути APK, подписи, разрешения или исходный dumpsys, а также не запускают и не изменяют приложения.
Локальная установка APK принимает только один .apk в каталоге <data-dir>/apks. Внешний агент должен сначала вызвать mobile_prepare_apk_install для получения краткосрочного Approval, содержащего имя файла, размер, SHA-256, идентификатор пакета Manifest и влияние замены; после того как MCP Host покажет пользователю эту сводку и получит явное подтверждение, можно вызывать mobile_install_apk. Approval истекает через десять минут и по умолчанию может быть использован только один раз. Runtime не загружает URL, не принимает split APK или произвольные параметры ADB.
Удаление приложения использует отдельный двухэтапный процесс mobile_prepare_app_uninstall → mobile_uninstall_app. Prepare только читает и возвращает версию приложения, определение системного приложения и влияние удаления данных; системные приложения или приложения с неизвестными атрибутами отклоняются напрямую. Только после того как пользователь явно подтвердит эту сводку, можно отправить асинхронную задачу удаления. При сбое или неизвестном результате нельзя автоматически повторять.
Жизненный цикл приложений предоставляет mobile_inspect_app_state, mobile_launch_app и mobile_stop_app. Проверка состояния возвращает только наличие процесса, нахождение на переднем плане и флаг остановки; запуск и остановка возвращают асинхронный task_id, перед остановкой несистемного приложения требуется явное подтверждение. Для постоянного удаления данных приложения необходимо сначала вызвать mobile_prepare_app_data_clear, показать имя пакета, версию и влияние удаления данных и получить новое явное подтверждение, затем вызвать mobile_clear_app_data. Очистка данных приложения не удаляет приложение, при сбое или unknown outcome нельзя автоматически повторять.
После явного подтверждения соберите последний снимок журналов (требуется передать локальный API token, сгенерированный при запуске Runtime):
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_logs_collect \
<device_id> --max-lines 500 --minimum-level info --confirm --token <runtime-token>Журналы сначала деидентифицируются, затем сохраняются как локальный Artifact размером до 1 MiB; CLI и REST не возвращают содержимое журналов. Добавьте --async-task, чтобы немедленно получить task_id, и используйте унифицированный статус выполнения, события, отмену и отчёт о задаче:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_logs_collect \
<device_id> --confirm --async-task --deadline-seconds 60 --token <runtime-token>Соберите агрегированные снимки CPU, памяти, температуры батареи и системной нагрузки:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_performance_snapshot \
<device_id> --async-task --deadline-seconds 90 --token <runtime-token>Артефакт производительности содержит только агрегированные JSON-метрики, не сохраняет исходный текст dumpsys, имена процессов или детали приложений.
Однократно соберите скриншот, UI Tree, деидентифицированные журналы, агрегированную производительность и необязательное состояние приложений, и создайте локальный ZIP с манифестом SHA-256:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.diagnostic_bundle_collect \
<device_id> --app-id <package-id> --max-log-lines 500 \
--minimum-log-level info --confirm --token <runtime-token>Диагностический пакет относится к риску Medium и требует явного подтверждения. CLI, Web, REST и MCP возвращают только метаданные Artifact и безопасную сводку, не встраивают скриншоты, UI Tree, журналы или содержимое ZIP; имена файлов в пакете фиксированы, общий размер не превышает 24 MiB, и пакет не загружается и не отправляется наружу.
Просмотрите занятость локального хранилища Artifact и выполните только для чтения предварительную проверку доказательств, превышающих стандартный срок хранения 7 дней:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.local_storage
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.local_data_cleanup_prepare \
--retention-days 7 --max-artifacts 500 --token <runtime-token>Prepare не удаляет файлы, только возвращает количество кандидатов, размер, срок действия и краткосрочное Approval. После того как пользователь проверит сводку влияния и явно подтвердит, можно отправить асинхронную задачу очистки:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.local_data_cleanup \
<approval-id> --confirm --token <runtime-token>Очистка принимает только привязанные к Approval системно сгенерированные Artifact ID, относительные пути, размеры и SHA-256; не принимает произвольные пути, не удаляет базу данных задач, конфигурацию, ключи или APK, и не запускается автоматически в фоне и не автоматически повторяет сбои.
Сравните две завершённые задачи снимков производительности на одном устройстве:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.device_performance_compare \
<baseline_task_id> <candidate_task_id> --token <runtime-token>Отчёт о задаче Web также может установить один успешный снимок в качестве базовой линии, затем выбрать другой снимок для сравнения. Результат сравнения только показывает числовое направление и порог стабильности двух точечных выборок, не автоматически определяет причинно-следственную связь или регрессию производительности.
Если adb не в PATH, можно явно настроить:
MOBILE_AGENT_ADB_PATH=/usr/local/platform-tools/adbITER-0003 добавляет GET /v1/tools, POST /v1/tools/{tool_id}/invoke и POST /v1/skills/app.open/invoke. input.tap относится к риску Medium и по умолчанию требует явного подтверждения.
ITER-0004 добавляет безопасный разбор иерархии UI, семантический Selector, input.tap_element и POST /v1/skills/settings.navigate/invoke. Семантический клик относится к риску Medium, при неоднозначном совпадении выполнение отклоняется.
ITER-0005 добавляет ограниченные политикой input.swipe, input.text, ограниченный семантический поиск прокрутки и POST /v1/skills/settings.scroll_navigate/invoke. Прокрутка и ввод относятся к риску Medium и по умолчанию требуют явного подтверждения; сценарии паролей, кодов подтверждения, платежей, безопасности аккаунтов и автоматической отправки не входят в эту итерацию.
ITER-0006 добавляет минимальный Task Runner, отчёт о доказательствах TaskRun и предварительный синхронный endpoint POST /v1/tasks/settings.scroll_navigate/run. Этот endpoint только оборачивает существующий Skill settings.scroll_navigate, не заменяя будущий дизайн асинхронной очереди задач.
ITER-0007 добавляет внутрипроцессный Task Store, TaskEvent и query endpoints GET /v1/tasks/{task_id}, GET /v1/tasks/{task_id}/events. Этот Store действителен только в течение жизненного цикла процесса Runtime и пока не поддерживает восстановление после перезапуска.
ITER-0008 добавляет первую версию представления отчёта о задачах CLI, которое может отображать TaskRun и TaskEvent в читаемый пользователем отчёт:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.task_report <task_id>Эта команда запрашивает задачи и события из локального API Runtime.
ITER-0009 добавляет SQLite Task Store, по умолчанию сохраняющий задачи и события в <data-dir>/mobile-agent.db. При установке MOBILE_AGENT_DATA_DIR база данных находится в этом каталоге; в противном случае используется каталог локальных данных по умолчанию для платформы.
ITER-0010 добавляет список исторических задач:
PYTHONPATH=runtime python3.11 -m mobile_agent.cli.task_list --limit 20Список показывает последние сводки задач, можно скопировать task_id и использовать task_report для просмотра деталей.
ITER-0011 добавляет локальный Web UI. После запуска Runtime откройте:
http://127.0.0.1:8765/uiчтобы просмотреть историю задач и детали отчёта о задачах.
ITER-0012 добавляет кнопку «Запустить безопасное демо» в Web UI. Эта кнопка выбирает онлайн Android-устройство и запускает фиксированную задачу: открыть системные настройки и перейти на страницу дисплея/яркости. POST-запрос по-прежнему использует локальный токен Runtime и разрешён только для страниц loopback того же источника.
ITER-0013 добавляет предварительный просмотр цикла агента до подключения модели: POST /v1/tasks/agent.run. Этот endpoint использует детерминированный Planner для генерации ограниченных решений, в настоящее время поддерживает только безопасную демонстрационную цель «перейти в системные настройки, страницу дисплея/яркости» и записывает сводку наблюдений, решения Planner, результаты выполнения Skill и доказательства в отчёт о задаче.
ITER-0014 добавляет поле ввода задач на естественном языке и кнопку «Запустить предпросмотр агента» в Web UI. Страница вызывает POST /v1/tasks/agent.run и после возврата задачи обновляет список истории и открывает отчёт о задаче.
ITER-0015 добавляет внутренний контракт предварительного просмотра LLM Planner и MockLLMPlanner. Вывод в стиле модели должен сначала пройти структурированный разбор и проверку полей, затем повторную проверку через allowlist Skill Agent Runner; эта итерация не вызывает реальные сервисы моделей и не читает ключи моделей.
ITER-0016 добавляет предварительный просмотр OpenAI-совместимого Planner Provider, отключённого по умолчанию. Provider может создавать запросы в стиле chat-completions, разбирать структурированные ответы через инжектируемый transport и повторно использовать проверку вывода Planner из ITER-0015; по умолчанию Runtime не включает реальный Provider, тесты не зависят от сети или ключей моделей.
ITER-0017 добавляет конфигурационный шлюз для Provider модели: конфигурация по умолчанию по-прежнему возвращает RuleBasedPlanner; только при явном включении openai_compatible, предоставлении base_url, model и api_key_ref и разрешении ключа через инжектируемый SecretResolver будет создан OpenAI-совместимый Planner. Эта итерация не подключается к Runtime по умолчанию и не читает реальные ключи.
ITER-0018 добавляет read-only entry point статуса модели Provider: GET /v1/model-provider/status и панель «Модель Provider» в Web UI. Статус показывает только включён ли, provider, model и настроена ли ссылка на ключ, не возвращает реальные ключи или исходный текст api_key_ref; Runtime по умолчанию по-прежнему не включает реальные модели.
ITER-0019 добавляет чтение локальной конфигурации модели: при запуске Runtime читает <data-dir>/model-provider.json или файл, указанный в MOBILE_AGENT_MODEL_CONFIG, и позволяет переменным окружения MOBILE_AGENT_MODEL_* переопределять поля конфигурации. Файл конфигурации сохраняет только api_key_ref, предварительный SecretResolver для разработки разрешает только ссылки env:MOBILE_AGENT_MODEL_SECRET_*; Agent Runner по умолчанию по-прежнему не вызывает реальные модели.
ITER-0020 подключает Planner модели к Runtime по умолчанию с контролем: когда конфигурация выключена, продолжает использовать RuleBasedPlanner; когда конфигурация включена и ссылка на ключ разрешима, использует OpenAI-совместимый Planner; когда конфигурация включена, но недоступна, задачи агента явно завершаются с MODEL_UNAVAILABLE, не откатываясь молча на RuleBasedPlanner. Вывод модели по-прежнему должен проходить через структурированный разбор, allowlist Skill, Policy Engine и Device Gateway.
ITER-0021 улучшает карточку статуса модели Provider в Web UI: различает не включено, подключено, конфигурация недоступна и конфигурация прочитана, при недоступности подсказывает проверить файл конфигурации, MOBILE_AGENT_MODEL_CONFIG и MOBILE_AGENT_MODEL_SECRET_*. Репозиторий предоставляет пример конфигурации: model-provider.example.json.
ITER-0022 обновляет предварительный просмотр агента с «одного раунда решения модели, вызывающего большой Skill» на «много раундов решения модели + атомарное выполнение Tool + повторное наблюдение в каждом раунде». Planner может выводить run_tool, finish, Runtime разрешает только whitelist Tools и при finish выполняет детерминированную проверку через UI Selector; старый путь run_skill сохраняется для совместимости.
ITER-0023 повышает AgentObservationSummary, AgentDecision и AgentStepResult в отчётах каждого раунда агента до публичных JSON Schema и обновляет Schema TaskRun для официальной поддержки agent.run. Настольный клиент, CLI и будущие внешние агенты могут стабильно потреблять многораундовые отчёты Observe–Plan–Act.
ITER-0024 добавляет обратную связь о прогрессе действий агента: Runtime сравнивает переднее приложение и UI tree до и после Tool, передаёт changed / unchanged на следующий раунд модели и блокирует повторную отправку того же действия без прогресса. Web-отчёт синхронно показывает фактический Tool, параметры и прогресс страницы.
ITER-0025 оптимизирует Observation на стороне модели: фильтрует узлы без семантической разметки, приоритетно сохраняет видимый текст и действующие узлы, добавляет метаданные обрезки сводки и деидентифицирует текст UI перед попаданием в Prompt модели и сводку задачи, удаляя распространённые номера телефонов, email и длинные числовые идентификаторы.
ITER-0026 добавляет строгий контракт ToolCall агента, ограниченное исправление недопустимых параметров модели и сохранение доказательств неудачных раундов. На реальном устройстве завершён многораундовый замкнутый цикл модели «перейти в дисплей и яркость».
ITER-0027 создаёт основу для целевой онлайн-оценки агента: реальные модели каждый раз перепланируют, сталкиваясь с текущим интерфейсом устройства, оценка ограничивает только цель, конечное состояние, запрещённые Tools и бюджет раундов, не сравнивает фиксированные пути действий. Завершённый agent.run можно оценить через POST /v1/tasks/{task_id}/evaluate, пример сценария находится в agent-evaluation-scenario.example.json.
ITER-0042 организует несколько независимых от пути сценариев в версионированный Suite. Сначала выполните цели в Suite через Web или MCP, затем передайте завершённые task_id в read-only агрегирующий CLI; эта команда только вызывает существующие API оценки, не отправляет и не воспроизводит действия устройств:
./scripts/report-mcp-evaluation.zsh \
--suite evaluations/android-settings-smoke-v1.json \
--task settings.bluetooth.v1=task_<id> \
--task settings.display-brightness.v1=task_<id> \
--task settings.battery.v1=task_<id>Отчёт показывает общий процент успеха, процент успеха по сценариям, время p50/p95, среднее количество раундов и Tools, а также статистику повторов Provider, NO_PROGRESS, MODEL_UNAVAILABLE и нарушений политики. Suite определяет цели и независимые условия успеха, не содержит фиксированных путей действий. Скрипт только читает зарегистрированную в Codex локальную информацию о подключении mobile-agent, не печатает токены и не отправляет задачи устройств.
ITER-0028 усиливает надёжность: целевое позиционирование без побочных эффектов и сбой проверки finish могут быть переданы модели как failed round для продолжения планирования; finish может комбинировать переднее приложение/активность и UI Selector; клики в верхней системной области и нижней жестовой области перехватываются перед отправкой. Ошибки таймаута, HTTP, соединения и формата ответа Provider классифицируются и записываются, для retryable запросов модели выполняется максимум одна повторная попытка; недопустимый Selector показывает только деидентифицированную диагностику на уровне полей. Если модель опускает не критичный для безопасности reason, Runtime генерирует фиксированное аудиторское пояснение, не инициируя дополнительный запрос на исправление модели; Tool, Selector, Policy и условия завершения по-прежнему строго проверяются.
ITER-0029 добавляет необязательные условия успеха, принадлежащие Runtime, для вызывающей стороны. POST /v1/tasks/agent.run может принимать acceptance, используя семантику all-of для проверки finish, отправленного моделью, с передним идентификатором приложения, Activity и уникальным UI Selector; путь по-прежнему динамически планируется моделью на основе наблюдений в реальном времени. Отчёт о задаче сохраняет и показывает goal_acceptance и completion_source. Пример запроса находится в agent-run-runtime-acceptance.example.json.
ITER-0030 добавляет двухэтапную компиляцию целей: POST /v1/goals/compile преобразует короткую цель на естественном языке в проверяемый черновик AgentGoalSpec, содержащий расширенную цель выполнения, предположения, уверенность и необязательные условия успеха. Черновик модели должен быть явно подтверждён пользователем перед передачей в agent.run; задача по-прежнему динамически планируется моделью на основе наблюдений в реальном времени, не генерируя фиксированные пути действий. Пример: agent-goal-spec.example.json.
ITER-0031 добавляет асинхронное выполнение агента: POST /v1/tasks/agent.run/async немедленно возвращает 202 Accepted и task_id, GET /v1/task-executions/{task_id} и /events предоставляют постоянное состояние и события по раундам, POST /v1/task-executions/{task_id}/cancel запрашивает отмену на безопасной границе. Асинхронное создание поддерживает Idempotency-Key; исходный синхронный POST /v1/tasks/agent.run сохраняет совместимость. Локальный Web UI по умолчанию использует асинхронный вход.
ITER-0032 добавляет эксклюзивную аренду одного устройства для публичных write entrypoints Runtime и необязательный deadline_seconds (по умолчанию 600 секунд, диапазон 1–1800) для синхронного/асинхронного agent.run. Когда устройство занято другой задачей, возвращается DEVICE_LOCKED; после превышения бюджета на безопасной границе задача завершается с timed_out/TASK_DEADLINE_EXCEEDED, доказательства выполненных действий сохраняются.
ITER-0033 добавляет блокировку одного экземпляра Runtime для одного каталога данных и генерирует session_id для каждого непрерывного онлайн-подключения устройства. Задачи и аренда привязаны к текущей Session; после отключения или переподключения устройства старые задачи останавливаются с DEVICE_SESSION_CHANGED, последующие действия не отправляются на новое подключение. Device, TaskExecution, TaskRun и отчёты Web/CLI показывают идентификатор сессии.
ITER-0034 добавляет унифицированную готовность Runtime/Device: Web и CLI используют один и тот же read-only Contract для интерпретации ADB, подключения и авторизации устройств, состояния Session и Lease; только устройства ready могут запускать задачи из Web. При отсутствии ADB Runtime переходит в диагностический режим и предоставляет рекомендации по исправлению, не устанавливает инструменты автоматически и не изменяет конфигурацию устройств.
ITER-0035 добавляет Device Inspection и Capability Catalog. В Web можно нажать на устройство, чтобы просмотреть восемь базовых возможностей V1; GET /v1/devices/{device_id}/inspection и CLI показывают текущую доступность, риск, идемпотентность, требования к проверке, связанные Tools и ограничения. Inspection только читает обнаружение устройств и Lease, не делает скриншоты, не читает UI и не выполняет действия.
ITER-0036 добавляет первый инженерный диагностический Skill: POST /v1/skills/device.logs.collect/invoke. Android Adapter принимает только ограниченное количество строк и фиксированные уровни журнала, использует фиксированные параметры logcat для сбора снимка; Skill требует явного подтверждения Medium risk и после локальной деидентификации генерирует Artifact device_log. Web и CLI показывают только метаданные Artifact. Непрерывная потоковая передача, произвольные фильтры logcat и загрузка журналов не входят в эту итерацию.
ITER-0037 подключает сбор журналов к унифицированной асинхронной цепочке задач: POST /v1/tasks/device.logs.collect/async возвращает 202 Accepted и повторно использует состояние TaskExecution, инкрементальные события, Idempotency-Key, отмену, Deadline, Device Session, Lease и постоянные отчёты TaskRun. Кнопка журналов Web по умолчанию отправляет асинхронно; синхронный endpoint Skill сохраняется. Исполнитель разрешает только зарегистрированные в коде типы задач Agent и журналов, клиент не может отправлять произвольные обработчики.
ITER-0038 добавляет device.performance.snapshot: Android Adapter собирает общий CPU, Total/Free RAM, заряд/температуру батареи, uptime и load average через фиксированные read-only команды, записывая только нормализованные числовые значения в локальный JSON Artifact. Синхронный Skill, асинхронная Task, Web и CLI используют один и тот же Contract; не предоставляются детали приложений/PID и непрерывная выборка.
ITER-0039 добавляет POST /v1/performance-comparisons, принимая два успешных снимка производительности TaskRun на одном устройстве в качестве входных данных, вычисляет двухточечные разности и пороговые тенденции для CPU, памяти, заряда, температуры и нагрузки. Сравнение полностью читает структурированные доказательства задач локально, не обращается к устройствам, моделям или исходному dumpsys; Web и CLI явно предупреждают, что двухточечные выборки не могут сами по себе доказать причинно-следственную связь или регрессию производительности.
ITER-0040 добавляет MCP 2025-11-25 stdio предварительный просмотр для разработчиков. Дочерний процесс MCP вызывает только фиксированный localhost REST API уже запущенного Runtime, поэтому разделяет задачи, Session, Lease и Policy с Web; все длительные возможности асинхронно возвращают task_id ThumbAgent. Входы Tools соответствуют публичному Contract, проходят строгую проверку и ограничение скорости перед вызовом, ошибки домена возвращаются как structuredContent. MCP Tasks, удалённая передача, Resources или Prompts пока не реализованы.
ITER-0047 добавляет device.diagnostics.bundle. Одна подтверждённая асинхронная задача в том же Device Session и Lease объединяет Observation, деидентифицированные журналы, агрегированную производительность и необязательное состояние приложений, создавая локальный ZIP с фиксированным содержимым. Манифест записывает имена, размеры и SHA-256 четырёх исходных Artifacts; Runtime повторно проверяет целостность источников и набор файлов ZIP перед публикацией диагностического пакета, при сбое сохраняет ссылки на уже завершённые безопасные Artifacts.
ITER-0048 добавляет сводку локального хранилища Artifact и двухэтапную очистку с истёкшим сроком. Preview только сканирует системно сгенерированные файлы и возвращает агрегированную сводку влияния; Submit принимает только Approval с высоким риском, действительное десять минут, одноразовое и с ограниченным диапазоном, проверяя путь, размер, SHA-256 и срок действия перед удалением. Асинхронные задачи не получают Device Session или Lease, отмена и Deadline на безопасной границе между Artifact предотвращают последующие удаления и сохраняют сводку завершённых удалений.
Если реальный Provider постоянно завершает ответы около бюджета по умолчанию 30 секунд, можно увеличить timeout_seconds до 60 (допустимый диапазон 1–120) в локальной конфигурации или переопределить через MOBILE_AGENT_MODEL_TIMEOUT_SECONDS=60. Повторные попытки по таймауту могут привести к дополнительным вызовам модели, отчёт о задаче покажет количество повторов.
This server cannot be installed
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
MCP server for static security analysis of Android source code
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LiuShiYi1027/ThumbAgent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server