Busymate DevTools

{
  "id": "aix_06a6f6e9b4",
  "name": "Busymate DevTools",
  "operator": "(unclaimed - source: pulsemcp · publisher: www.pulsemcp.com)",
  "description": "Capture, inspect, and debug HTTPS traffic across iOS, Android, browsers, and backends via AI agents.",
  "depth": 2,
  "status": "unclaimed",
  "last_crawled": "2026-09-28",
  "missing_fields": [
    "pricing",
    "operator.identity"
  ],
  "skills": [
    "api-integration",
    "chat-messaging",
    "dedupe-records",
    "github-ops",
    "invoice-parsing",
    "sql-database",
    "summarize-docs"
  ],
  "protocols": {
    "mcp": "https://mcp.busymate.dev",
    "a2a": null
  },
  "pricing": null,
  "regions": [
    "global"
  ],
  "languages": [
    "en"
  ],
  "reputation": {
    "tasks_completed": null,
    "dispute_rate": null,
    "p95_latency_ms": 3088,
    "uptime_30d": 1,
    "onchain_volume_30d_usd": null
  },
  "aix_score": 41,
  "verification": {
    "identity": "none",
    "health": "probe/24h",
    "pricing": "unknown",
    "last_check": "2026-09-28T06:01:07.859Z"
  },
  "pricing_model": "unknown",
  "links": [
    {
      "label": "homepage",
      "url": "https://www.pulsemcp.com/servers/busymate-devtools"
    },
    {
      "label": "listing",
      "url": "https://busymate.dev/mcp"
    }
  ],
  "profile": {
    "mcp_server": "busymate-devtools",
    "mcp_version": "1.0.1.903",
    "tool_count": 48,
    "tools": [
      {
        "name": "list_breakpoint_events",
        "description": "List HELD (paused) breakpoint exchanges — the READ side of the breakpoint-continue flow (public.breakpoint_events; a row with resumed_at NULL is a request/response the proxy is holding RIGHT NOW, waiting for breakpoint_continue — feed it the returned request_id). YOUR OWN devices' events by default (owner-scoped to the calling account — the same reach the dashboard /breakpoints page gives you), or EVERY device with `all:true` (devices:view operators only; re-verified server-side — for a non-operator `all` is rejected, never silently widened). Each row is a SLIM projection: id, request_id, devi"
      },
      {
        "name": "get_device",
        "description": "Get one device row by uuid, name, OR its PAC PORT — the DIRECT resolver for a KNOWN device: when you already hold a device uuid/name (from traffic rows, audit events, another tool's result) or a per-device PAC/proxy endpoint, call this instead of browsing or paging list_devices. `pac_port` accepts EVERY spelling: a bare port (10807), the PAC hostname (10807.busymate.net), a full PAC URL (http://10807.busymate.net/ or https://10807.busymate.net/proxy.pac), or host:port — the leading label of a PAC host IS the device's allocated port. A host with no numeric leading label and no explicit port is "
      },
      {
        "name": "list_devices",
        "description": "List devices, ONE PAGE at a time — YOUR OWN by default (owner-scoped to the calling account: the same reach the dashboard gives you), or the WHOLE fleet with `all:true` (devices:view operators only; re-verified server-side — for a non-operator `all` is rejected, never silently widened). PAGINATION (read this before concluding anything is absent): every response carries `total` (the EXACT count in scope), `returned` (rows in THIS page), `has_more`, and `next_cursor`. If `has_more` is true the answer is INCOMPLETE — call again with `cursor: <next_cursor>` (same `order` and same scope) and repeat"
      },
      {
        "name": "get_device_status",
        "description": "Get a device's live status: `online` is DERIVED truth (#776 — devices.last_seen_at within 90s, 150s for farm hosts; the same derivation as every other surface, so it can't latch stale), plus the device_status row (last_heartbeat_at, ip, vpn_state, source, reported_online = the raw stored flag, diagnostics only). Works even for a device that never wrote a status row (entries-only clients) — `online` still evaluates from last_seen_at."
      },
      {
        "name": "get_device_health",
        "description": "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 + "
      },
      {
        "name": "list_device_events",
        "description": "The MULTI-PRODUCER device TELEMETRY event stream (#1160/#1208) — every DECISION and STATE TRANSITION reported about the capture pipeline by the iOS app OR by the PAC/proxy server (public.device_events, 14-day retention, weekly-partitioned). iOS kinds — this list is what the app ACTUALLY emits, corrected in #1232 after SEVEN of the fifteen declared categories turned out to have zero emit sites and zero rows while this description told operators they existed. BASELINE (always on, no flag): capture.health (armed|inert + why + decrypt counters), cert.state, config.applied / config.fetch, tunnel.li"
      },
      {
        "name": "list_device_audit_modes",
        "description": "Every device with AUDIT-mode telemetry currently armed — device_uuid + name, enabled, expires_at + expires_in, level, categories, who armed it (set_by_label) and when (set_at). The 'standing cost is never invisible' list (#1160 spec §5): audit mode is per-device + TTL-expiring, and this is where you see everything armed right now. YOUR OWN devices by default; devices:view operators see the whole fleet (re-verified server-side). Read-only, no confirm. Backed by the list_device_audit_modes DEFINER RPC."
      },
      {
        "name": "test_pac_connection",
        "description": "PROVE whether PAC capture actually works for ONE device — the \"is it really working?\" answer, not \"does it look configured\". Runs 8 independent checks and returns a per-check verdict with a specific human fix: (1) connection mode — is the device even on `pac` (a `vpn`/`off` device is SAID SO plainly, never reported as broken PAC); (2) PAC port + URL — a pool port is allocated and http://<port>.busymate.net/ + /proxy.pac + /wpad.dat each serve HTTP 200 with the PAC content type; (3) THE HEADLINE — the PAC the proxy really serves this device carries a PROXY directive and is NOT the silent DIRECT"
      },
      {
        "name": "list_screen_share_recordings",
        "description": "List saved screen-share RECORDINGS (#1916) — operator-captured mp4s of live share streams (the dashboard viewer's Record control), saved for later reference in public.screen_share_recordings. YOUR OWN recordings by default (owner-scoped to the calling account — the same reach the row RLS gives the dashboard), or every visible recording with `all:true` (devices:view operators only; re-verified by the dispatch — for a non-operator `all` is rejected, never silently widened). Filter by device_uuid and/or session_id. Each row: id, session_id, device_uuid, device_name (capture-time snapshot), owner,"
      },
      {
        "name": "get_screen_share_recording",
        "description": "Fetch ONE saved screen-share recording (#1916) by id — the metadata row plus, with `with_url:true`, a SHORT-TTL (600s) signed playback URL + a download URL for the mp4 (H.264 — plays in any <video> element / on iPhone). YOUR OWN recording by default; `all:true` (devices:view operators, dispatch-policed) reaches any visible recording. The internal storage_path is never surfaced — the signed URL is the only byte access. Read-only, no confirm. Returns { ok, recording, url, download_url, url_ttl_seconds }."
      },
      {
        "name": "get_my_account",
        "description": "YOUR account at a glance — ONE self-scoped read returning the calling account's profile (name, display_name, email, role, sign-in providers, user_id, created_at), your per-user default connection type (own value + the global default + the effective fold), your linked Telegram accounts, the devices YOU own (uuid/name/model/last_seen_at — the uuids feed get_device / rename_device / …), your Stripe subscription status, and the API endpoints callable with this token. The MCP mirror of the dashboard Account page. SELF-ONLY: every read is pinned server-side to the verified caller — it takes NO targe"
      },
      {
        "name": "get_device_egress_status",
        "description": "Read a device's egress-IP set (#1432) — the device→proxy INGRESS / CONNECT-source ADMISSION IPs the proxy allowlists for it (the addresses it will ACCEPT this device's CONNECTs FROM), PLUS any manual dev overrides. These are the CONNECT-source ADMISSION IPs, NOT the target-visible egress ORIGIN the destination server sees (that origin is governed by the device's external (upstream) proxy — see set_device_external_proxy). Each row carries `ip`, `source` ('proxy' = an automatic /allocate row, rolling 48h window + 10-most-recent-per-device cap; 'manual' = a TTL'd dev override, EXEMPT from the cap"
      },
      {
        "name": "get_device_egress_fail_posture",
        "description": "Read a device's PAC egress FAIL POSTURE (#1657) — what the proxy does when the device is handed the #76 PAC DIRECT fallback (its PAC-fetch source IP is not yet in the CONNECT-source admission allowlist, routine on CGNAT). The setting `egressFailPosture` ∈ open | closed | auto rides settings_{global,device}.data and is resolved device→user→service→global by effective_settings_for_device (like the external proxy). Meanings: open → serve DIRECT (stay online, but the device egresses from its REAL IP — a leak for an external-proxy/country-pinned device); closed → serve a HOLD/no-egress PAC (proxy-o"
      },
      {
        "name": "get_entry_count",
        "description": "Count entries in a workspace (workspace_id or workspace_slug) with optional device/host/method/status/search filters."
      },
      {
        "name": "list_wipe_jobs",
        "description": "List the workspace's WIPE JOBS (public.entries_wipe_jobs, #2147) — the ONE source of truth for wipe progress, the same rows the dashboard's wipe banner renders. Each job: the EXACT device set, the narrowing predicate (hosts/methods/status_class/search_q/origin), total (from the live entry_dh_counts ledger; total_exact=false ⇒ an upper bound), deleted, percent, status (queued|running|done|failed|cancelled), started/finished/heartbeat timestamps, requested_by, error, plus derived `stalled` (no heartbeat for 90 s — the server re-drive resumes it within a minute) and `terminal`. Filters: job_id, s"
      },
      {
        "name": "get_entry_counts_freshness",
        "description": "The ONE freshness surface for every dashboard counter (#2147): mode 'live' — entry_dh_counts is a LEDGER maintained in the write transaction of every insert / delete / wipe / partition drop and broadcast as COUNTS_DELTA (never an hourly snapshot); ledger_since; reconciled_at + drift_rows / drift_abs from the hourly RECONCILER (a bounded drift check that corrects idle groups); reconcile_stale=true ⇒ no successful drift check for >2 h (a REPORTED class — the ledger keeps moving); last_error; and the /stats rollup seal watermark (stats_rollup_sealed_to / stats_rollup_stale). Read-only; no argumen"
      },
      {
        "name": "search_entries",
        "description": "LOCATE captured entries by ANY keyword `q` — matched against the host/url/path AND the DECRYPTED request/response DATA: the request+response HEADERS and the request+response BODY text (#1577). Case-insensitive substring. Body/header matching covers full headers + the head of each body (first ~4KB request / ~8KB response) via a trigram index, and a body is indexed ONLY when its side's content-type is API-shaped (JSON / XML / form / multipart / text-plain / CSV / SSE / GraphQL, or no content-type at all) — JS, CSS, HTML, image, font and binary bodies are not keyword-searchable (#2143), and a key"
      },
      {
        "name": "list_entries",
        "description": "LIST the newest captured traffic entries as SLIM feed rows (id, ts, device, kind, request_id, host, path, method, status, contentType, url — NO bodies/headers) — the dashboard main live feed's MCP-parity read (#778). No search term needed (unlike search_entries' required `q`). FULL /feed filter set (#819): scope to ONE device (device_uuid/deviceName), an EXACT `host` or a `host_contains` substring, an HTTP `method`, a `status` (exact code or a class '2xx'/'4xx'/'5xx'), and/or an absolute ts range; `since_id` returns ONLY rows newer than an id you already hold (the live-tail append cursor — pol"
      },
      {
        "name": "get_entry",
        "description": "Get ONE captured entry's FULL detail by the id you already hold — method, URL, host, path, status, timing (duration_ms) + sizes, the request AND response HEADERS, and the request AND response BODIES (size-capped, truncation stated explicitly). The ID-SCOPED twin of inspect_requests (which is per-HOST): when a live feed row, an audit event or another tool hands you an `entry_id` (or a `request_id`), call this to see THAT exact request — never re-query by host and guess which result matched. This is the MCP/widget parity twin of the dashboard's request-detail pane, and the tool the live-traffic "
      },
      {
        "name": "export_har",
        "description": "Export captured entries as a HAR 1.2 log. Optionally scope by device, host, and date range."
      },
      {
        "name": "inspect_requests",
        "description": "Deep-inspect FULL captured request/response detail for ONE host — method, URL, request + response HEADERS, and request + response BODIES (size-capped). The tool for reverse-engineering how a real app/API works from its actual captured traffic (auth flows, required headers, payload shapes) and for building repro (curl/fetch). `host` MUST be a full hostname containing a dot (e.g. 'identity.doordash.com') — a bare brand word is rejected (an exact-host index scan is fast; a substring scan times out). Scoped to a device (device_uuid/deviceName) it scans that device's full history; WITHOUT a device "
      },
      {
        "name": "summarize_device_traffic",
        "description": "BOUNDED traffic aggregation for ONE device — the FIRST tool to call to report what a device is doing, find the busy/flooding host, or pick a host to clean up. REQUIRES a device (`device_uuid` or `deviceName`) — a host alone is NOT enough: if you don't know which device, ask the user (or check list_devices) BEFORE calling. NEVER scans or returns raw rows (use it instead of search_entries/inspect_requests on a high-volume device — those time out at scale). Omit `host` → top hosts by request count (which host dominates). Pass `host` → top path-bases on that host with per-path count + last-seen (w"
      },
      {
        "name": "list_service_groups",
        "description": "List every service group (full rows incl. ssl_proxy_domains) with each group's primary_agent + ordered agents[] from the service_group_agents join."
      },
      {
        "name": "get_service_group",
        "description": "Get one service group by id or name."
      },
      {
        "name": "list_tags",
        "description": "List every tag (id, name, color, patterns)."
      }
    ],
    "profiled_at": "2026-09-28T06:01:07.859Z"
  },
  "payment_method": "oauth",
  "unreachable": false
}