Live DAT Debugging with MCP (Android)
Use this skill when a developer is debugging an Android DAT app and has a local
DAT Inspector MCP server or DAT debug server available to the agent. This is
the live-runtime counterpart to dat-docs-mcp: use docs search for API lookup,
and use this skill for observed app/device behavior.
Ground rules
- Stay read-only unless the user explicitly asks for an app code change.
- Do not mutate Meta AI app, device, account, permission, registration, or app
state.
- Treat companion-app/device results as boundary diagnosis from app-visible DAT
events, not as direct access to companion app internals.
- Use live DAT evidence before guessing: registration, permissions, device
selection, link state, session state, stream state, typed errors, and SDK logs.
- If the MCP tools are not configured, ask the developer to enable their local
DAT debug setup and fall back to logs plus
search_dat_docs.
Normal agent loop
- Discover and connect to the running app debug server:
discover_debug_servers
connect_to_debug_server
- Establish the baseline with all three calls before diagnosing deeper:
get_connection_status
get_sdk_state
get_dat_readiness
Do not skip get_connection_status; it separates MCP/debug-server
connectivity from SDK, registration, permission, session, and stream state.
- If the issue looks like Meta AI app or device boundary behavior, inspect:
get_companion_boundary_diagnosis
get_device_path
get_permissions
get_device_properties
- Ask the developer to reproduce the failing Android flow while connected.
- Wait for narrow evidence instead of polling everything:
wait_for_events with category or source
get_errors
get_event_digest
- For handoff, collect a redacted bundle:
Evidence map
- Initialization: app logs around
Wearables.initialize(context)
- Registration:
Wearables.registrationState and wearables.registrationState
- Device availability:
Wearables.devices plus debug events from
wearables.devices, device.compatibility, and device.properties
- Device link:
device.linkState
- Permissions:
Wearables.checkPermissionStatus(...), device.permission,
check_permissions, and get_permissions
- Session:
createSession(...), session.start(), deviceSession.state,
session.state, and session errors
- Stream:
session.addCamera(...), camera.stream.start(), camera.stream.state, frame
counters, and stream errors
- DAM/DWA-visible transport:
sdk.usesDam and DAM/DWA error values
Diagnosis patterns
- Registration blocked: verify Android manifest metadata, app credentials or
Developer Mode setup, and callback/deeplink handling.
- No eligible device: inspect
Wearables.devices, device compatibility, and
device.linkState before changing selector code.
- Permission failure: use
get_permissions and get_companion_boundary_diagnosis;
do not assume Android runtime permission is the same as DAT permission through
the Meta AI app/device boundary.
- Session fails before stream creation: inspect session errors and selected
device compatibility before changing camera code.
- Stream fails after session start: inspect stream state, camera permission, and
recent errors before changing frame processing.
Output expectations
When summarizing, name the evidence plane, the blocking state, and the next
developer action. Example:
DAT readiness is blocked at permissions: camera is denied in app-visible DAT
events. Grant the DAT camera permission in Meta AI, return to the app, then
retry session.start() and camera.stream.start() while the MCP connection waits for
permission and stream events.
1---2name: live-debugging-mcp3description: Use this whenever debugging an Android DAT app with local DAT Inspector MCP tools, live device events, Meta AI app/device boundary issues, permissions, registration, sessions, streaming, or user reports that the app cannot communicate with glasses.4---56# Live DAT Debugging with MCP (Android)78Use this skill when a developer is debugging an Android DAT app and has a local9DAT Inspector MCP server or DAT debug server available to the agent. This is10the live-runtime counterpart to `dat-docs-mcp`: use docs search for API lookup,11and use this skill for observed app/device behavior.1213## Ground rules1415- Stay read-only unless the user explicitly asks for an app code change.16- Do not mutate Meta AI app, device, account, permission, registration, or app17 state.18- Treat companion-app/device results as boundary diagnosis from app-visible DAT19 events, not as direct access to companion app internals.20- Use live DAT evidence before guessing: registration, permissions, device21 selection, link state, session state, stream state, typed errors, and SDK logs.22- If the MCP tools are not configured, ask the developer to enable their local23 DAT debug setup and fall back to logs plus `search_dat_docs`.2425## Normal agent loop26271. Discover and connect to the running app debug server:28 - `discover_debug_servers`29 - `connect_to_debug_server`302. Establish the baseline with all three calls before diagnosing deeper:31 - `get_connection_status`32 - `get_sdk_state`33 - `get_dat_readiness`34 Do not skip `get_connection_status`; it separates MCP/debug-server35 connectivity from SDK, registration, permission, session, and stream state.363. If the issue looks like Meta AI app or device boundary behavior, inspect:37 - `get_companion_boundary_diagnosis`38 - `get_device_path`39 - `get_permissions`40 - `get_device_properties`414. Ask the developer to reproduce the failing Android flow while connected.425. Wait for narrow evidence instead of polling everything:43 - `wait_for_events` with `category` or `source`44 - `get_errors`45 - `get_event_digest`466. For handoff, collect a redacted bundle:47 - `export_diagnostic_bundle`4849## Evidence map5051- Initialization: app logs around `Wearables.initialize(context)`52- Registration: `Wearables.registrationState` and `wearables.registrationState`53- Device availability: `Wearables.devices` plus debug events from54 `wearables.devices`, `device.compatibility`, and `device.properties`55- Device link: `device.linkState`56- Permissions: `Wearables.checkPermissionStatus(...)`, `device.permission`,57 `check_permissions`, and `get_permissions`58- Session: `createSession(...)`, `session.start()`, `deviceSession.state`,59 `session.state`, and session errors60- Stream: `session.addCamera(...)`, `camera.stream.start()`, `camera.stream.state`, frame61 counters, and stream errors62- DAM/DWA-visible transport: `sdk.usesDam` and DAM/DWA error values6364## Diagnosis patterns6566- Registration blocked: verify Android manifest metadata, app credentials or67 Developer Mode setup, and callback/deeplink handling.68- No eligible device: inspect `Wearables.devices`, device compatibility, and69 `device.linkState` before changing selector code.70- Permission failure: use `get_permissions` and `get_companion_boundary_diagnosis`;71 do not assume Android runtime permission is the same as DAT permission through72 the Meta AI app/device boundary.73- Session fails before stream creation: inspect session errors and selected74 device compatibility before changing camera code.75- Stream fails after session start: inspect stream state, camera permission, and76 recent errors before changing frame processing.7778## Output expectations7980When summarizing, name the evidence plane, the blocking state, and the next81developer action. Example:8283```text84DAT readiness is blocked at permissions: camera is denied in app-visible DAT85events. Grant the DAT camera permission in Meta AI, return to the app, then86retry session.start() and camera.stream.start() while the MCP connection waits for87permission and stream events.88```