---
name: ansight-app-inspection
description: Use this skill when an agent should use Ansight Studio as a local stdio-backed MCP bridge to inspect, debug, verify, or extract evidence from a running or captured app session. Prefer Ansight MCP tools for apps, sessions, screenshots, logs, telemetry, annotations, remote app tools, databases, and sandbox files before falling back to direct simulator or device access.
---

# Ansight App Inspection Skill

Use this skill when a user asks an agent to inspect, debug, review, verify, test, or extract data from an app and Ansight Studio may be available.

## Goal

Ground debugging and verification in live runtime evidence from Ansight Studio instead of relying only on source-code inspection.

## Required Constraints

- prefer Ansight Studio MCP tools before direct device, simulator, emulator, or app-container access
- prefer the `ansight-daemon mcp-stdio` bridge when configuring agent access; use direct HTTPS MCP only as a fallback when stdio is unavailable
- keep the MCP bridge local to the developer machine
- discover apps, sessions, and remote app tools before calling into a live app
- do not guess a target session when multiple live sessions match
- do not assume a remote app tool exists; use the returned app tool catalog
- use least-privilege reads first, and only mutate app state or files when the user request requires it
- report any fallback to direct device access and why Ansight could not satisfy the request

## Default Workflow

1. Confirm Ansight Studio is the available bridge.
   - Prefer mounted MCP tools named `ansight_*` when the agent exposes them directly.
   - If agent setup is needed, configure `ansight-daemon mcp-stdio` first.
   - If stdio is unavailable and tools are not mounted, connect to Studio at `https://localhost:45125/mcp/`.
2. Identify the target app.
   - Call `ansight_list_apps`.
   - Use `ansight_get_app` when the app id is known and the agent needs linked codebase or session metadata.
3. Identify the target session.
   - Call `ansight_list_sessions` with `liveOnly=true` for live debugging.
   - Pass `appId` when the user named a specific app.
   - If multiple live sessions match, ask the user to choose or use an explicit `sessionId`.
4. Pull host-owned evidence first.
   - State: `ansight_get_app_state`
   - Logs: `ansight_get_logs`
   - Telemetry: `ansight_get_telemetry`
   - Annotations: `ansight_get_annotations`
5. Discover live remote app capabilities when the task needs app internals.
   - Call `ansight_list_app_tools` with `sessionId` or `appId`.
   - Inspect the returned catalog, schemas, and guard policy.
6. Invoke remote app tools only after discovery.
   - Call `ansight_call_app_tool` with the selected `toolId` and schema-valid `arguments`.
   - Common remote tool families may include UI, data, file-system, preferences, secure-storage, reflection, or framework-specific tools, but availability depends on the app's installed Ansight tool packages and guards.
7. Use direct simulator or device access only if:
   - Ansight Studio is not reachable
   - no matching live or captured session exists
   - the required tool is not exposed
   - the MCP bridge or remote app tool returns a concrete blocking failure

## Stdio Bridge And HTTP Fallback

For agent configuration, prefer the stdio bridge:

```text
ansight-daemon mcp-stdio
```

If Ansight Studio is running but stdio is unavailable and the agent does not expose mounted `ansight_*` tools, use the MCP endpoint directly:

```text
https://localhost:45125/mcp/
```

Use `localhost`, not `127.0.0.1`, so hostname validation matches the Studio certificate.

Required MCP sequence:

1. Send `initialize`.
2. Store `MCP-Session-Id` and `MCP-Protocol-Version` from the response headers.
3. Send `notifications/initialized`.
4. Use `tools/list`, `tools/call`, `resources/list`, or `resources/read` as needed.
5. Include `MCP-Session-Id` and `MCP-Protocol-Version` on follow-up requests.

If the client rejects the certificate, switch to the stdio bridge when the client supports it. Otherwise trust the Studio-exported `localhost.cer` file.

## Tool Selection

Use host-owned Studio tools for session-level evidence:

- `ansight_list_apps`
- `ansight_get_app`
- `ansight_list_devices`
- `ansight_list_sessions`
- `ansight_get_app_state`
- `ansight_get_logs`
- `ansight_get_telemetry`
- `ansight_get_annotations`

Use remote app-tool proxying for live app internals:

- `ansight_list_app_tools`
- `ansight_call_app_tool`
- `ansight_push_file_to_app`

Use pairing and app-registration tools only when setting up or repairing an Ansight workflow:

- `ansight_register_app`
- `ansight_issue_pairing_config`
- `ansight_list_pairing_configs`
- `ansight_get_pairing_config`

## File And Database Rules

For sandbox files or databases exposed through remote app tools:

- call `ansight_list_app_tools` first and confirm the file or data tool is available
- list roots or databases before reading, downloading, or querying
- treat root aliases such as `appData`, `documents`, `cache`, and `temp` as already-resolved roots
- pass paths relative to the selected root; do not prepend the root's physical path or duplicate the root alias
- prefer read-only operations before writes
- use `ansight_push_file_to_app` only when the user asks to place a host-local file into the app sandbox

## Evidence Pattern

For debugging, gather enough runtime evidence to support the fix:

1. list sessions and select the relevant live or captured session
2. get current app state
3. read logs near the reproduction time
4. read telemetry when performance, memory, FPS, or timing is relevant
5. inspect screenshots or visual tree through remote app tools when UI state matters
6. query databases, preferences, files, or secure storage only when the issue requires that data
7. implement the code fix in the app
8. use Ansight again to verify the runtime behavior after the fix

## Output Expectations

When reporting back, include:

- the app id and session id used
- the Ansight tools called
- whether mounted MCP tools or direct MCP fallback were used
- key runtime evidence that drove the conclusion
- any exported artifact path
- any fallback to direct device access and why it was necessary