# get_device_health

THE ONE QUERY (#1157/#1160): the latest capture-health projection for ONE device — one device_health row, no scan, no on-device access needed. Answers "is the TLS-intercept engine armed, and if not, WHY": engine_state ('armed'|'inert') + engine_reason (e.g. no_ca_key) + state_established_at (when that state was first established, so a stale fact is visibly stale), the CA triple (ca_loaded / ca_key_present / ca_trusted — 'trusted CA, missing key' means refetch the cert BUNDLE; 'CA not trusted' means reinstall the profile: opposite fixes today's signals cannot distinguish), ssl_domain_count + ssl_domain_hash (compare against the server's expected effective-settings hash: mismatch = config-delivery fault, match + inert = engine fault), config_hash/config_fetched_at, the decrypt counters (flows_total / flows_decrypted / flows_reasons {reason: count} over no_engine|no_sni|out_of_scope|leaf_mint_failed|ca_untrusted|pinned|upstream_failed), events_dropped + last_seq/seq_gaps (the telemetry stream's own honesty detectors), tunnel_state, app_build + ios_version + boot_id, and last_error. The row is trigger-written from device_events (the DEVICE's own claims about itself — diagnostic, never authorization). iOS-ONLY BY TRIGGER (#1208): device_events is a MULTI-PRODUCER stream (the PAC/proxy server writes to it too), but this projection admits ONLY legacy/no-producer and detail.producer='ios' rows — a proxy/PAC event can never refresh last_event_at/updated_at or overwrite last_error, so this row is never 'recently healthy' on another process's evidence, and every unknown future producer fails closed the same way. For the proxy's own stream use list_device_events with producer:'proxy-server'. A device with NO row returns found:false + a note (it has never emitted telemetry — needs an iOS build with the #1160 emitter); that is a NORMAL complete answer, and absence of telemetry is never evidence of health. Owner-scoped: without devices:view you may still read YOUR OWN device by uuid/name.

Agent View of the PolicyLayer registry record for `get_device_health`. HTML page: https://policylayer.com/tools/dev-busymate-busymate-devtools/get-device-health

## Facts

- Tool: `get_device_health`
- Server: Busymate DevTools (`https://mcp.busymate.dev`) — https://policylayer.com/tools/dev-busymate-busymate-devtools.md
- Homepage: https://github.com/serebano/busymate-devtools
- Risk category: Read (Low risk)
- Registry record: grade F, identity unverified
- Server auth posture: open
- Server rate-limited: no
- Parameters: 2
- Recommended policy verdict: Allowed

## Parameters

| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `deviceName` | string | no |  |
| `device_uuid` | string | no |  |

Parameters from the server's own tool schema.

## Example call (MCP tools/call, JSON-RPC 2.0)

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_device_health",
    "arguments": {}
  }
}
```

## Why get_device_health is rated Low

Even though get_device_health only reads data, uncontrolled read access leaks sensitive information and racks up API costs: an agent caught in a retry loop can make thousands of calls a minute without anyone noticing.

Risk signals: Bulk/mass operation — affects multiple targets

## Use case

AI agents call get_device_health to retrieve information from Busymate DevTools without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.

## Recommended policy (PolicyLayer)

Verdict: **Allowed**. Enforced by the PolicyLayer MCP gateway (https://policylayer.com/mcp-gateway) before a call reaches Busymate DevTools:

```json
{
  "version": "1",
  "default": "deny",
  "tools": {
    "get_device_health": {}
  }
}
```

## Other tools on Busymate DevTools (43)

- `share_advisor_finding` — Execute — https://policylayer.com/tools/dev-busymate-busymate-devtools/share-advisor-finding.md
- `summarize_device_traffic` — Execute — https://policylayer.com/tools/dev-busymate-busymate-devtools/summarize-device-traffic.md
- `download_snapshot` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/download-snapshot.md
- `export_har` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/export-har.md
- `get_advisor_finding` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-advisor-finding.md
- `get_audit_event` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-audit-event.md
- `get_block_rules_device` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-block-rules-device.md
- `get_device` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-device.md
- `get_device_egress_fail_posture` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-device-egress-fail-posture.md
- `get_device_egress_status` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-device-egress-status.md
- `get_device_settings` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-device-settings.md
- `get_device_status` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-device-status.md
- `get_entry` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-entry.md
- `get_entry_count` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-entry-count.md
- `get_my_account` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-my-account.md
- `get_push_response` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-push-response.md
- `get_service_group` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-service-group.md
- `get_stats` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-stats.md
- `get_status` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-status.md
- `get_subscription` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-subscription.md
- `get_todo` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-todo.md
- `get_usage` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-usage.md
- `get_workspace` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/get-workspace.md
- `inspect_requests` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/inspect-requests.md
- `list_advisor_findings` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/list-advisor-findings.md
- `list_audit_events` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/list-audit-events.md
- `list_breakpoint_events` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/list-breakpoint-events.md
- `list_device_audit_modes` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/list-device-audit-modes.md
- `list_device_events` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/list-device-events.md
- `list_device_service_groups` — Read — https://policylayer.com/tools/dev-busymate-busymate-devtools/list-device-service-groups.md
- …and 13 more: https://policylayer.com/tools/dev-busymate-busymate-devtools.md

## For agents

This record is a snapshot. Live verdicts and the full registry:

- Check every server in your MCP config at once: `npx -y policylayer stack`
- Vet a server before you add it: install the mcp-precheck skill — `npx skills add https://policylayer.com` (skill text: https://policylayer.com/skill.md)
- Query the registry over MCP: endpoint `https://api.policylayer.com/mcp` — tools `check_mcp_server`, `check_mcp_stack`, `check_tool`, `search_registry`, `get_change_events`

---

Source: the PolicyLayer MCP registry — one continuously verified record per MCP server. Full record: https://policylayer.com/registry?q=dev-busymate-busymate-devtools · API: https://policylayer.com/registry/api · Policy library: https://policylayer.com/policies/dev-busymate-busymate-devtools