wyre-ai/msp-claude-plugins/incident-response

Blackpoint Incident Response

The functional Blackpoint tool surface today is read-only and centers on detections and the assets they fire against. This skill walks the investigation flow: tenant → asset → detections → vulnerabilities, plus dark-web and external-vulnerability cross-references.

Anti-triggers

• Responding, acknowledging, isolating, or closing — despite the

skill name there is no incident object and no write tool here. The MCP surface cannot mutate CompassOne state; response happens in the portal. If the intent is an actionable incident lifecycle, the operator is probably thinking of huntress-incidents or sentinelone-alerts.

• `blackpoint_alerts_*` and `blackpoint_tickets_*` — those domains

are stubs, not an alternative alerting surface. Detections are the only detection object Blackpoint exposes.

• Exposure work in its own right — CVE filtering, scan history,

dark-web, and external exposure have their own skill: blackpoint-vulnerability-management. Use this one only when a detection is the starting point.

• Sweeping every customer rather than investigating one — use

blackpoint-multi-tenant-operations.

API Tools

Tenants

Assets

Detections

Vulnerabilities

Common Workflows

Walk a detection end-to-end

1. Identify the tenant: blackpoint_tenants_list →

blackpoint_tenants_get.

1. List recent detections: blackpoint_detections_list.
2. Pick the detection of interest: blackpoint_detections_get.
3. Pivot to the affected asset:

blackpoint_assets_get and blackpoint_assets_relationships.

1. Cross-reference vulnerabilities on that asset:

blackpoint_vulnerabilities_list.

Per-tenant exposure rollup

1. blackpoint_tenants_get to confirm scope.
2. blackpoint_vulnerabilities_external_list for internet-facing

exposure.

1. blackpoint_vulnerabilities_darkweb_list for credential / data

leakage.

1. blackpoint_vulnerabilities_scans_list for recent scan history.
2. Roll up: count by severity, age, and asset. Surface anything

high-severity with no recent scan.

Asset relationship map

1. blackpoint_assets_search to find the entry asset.
2. blackpoint_assets_relationships to enumerate connected assets.
3. For each related asset, summarize detections and vulnerabilities

to build a blast-radius view.

Multi-tenant detection sweep (partner view)

1. blackpoint_tenants_list to enumerate customers.
2. For each tenant, call blackpoint_detections_list for a recent

window.

1. Roll up: detections per tenant, severity distribution, top

detection types.

1. Surface tenants with abnormal volume or new detection types as

priority follow-ups.

Edge Cases

• Stub domains — blackpoint_alerts_*,

blackpoint_cloud_security_*, blackpoint_notifications_*, blackpoint_partners_*, blackpoint_threat_intel_*, and blackpoint_tickets_* are placeholders today and should not be invoked. Prefer the four functional domains.

• Read-only — Any "respond" or "acknowledge" action must happen

in the CompassOne portal; the MCP surface cannot mutate state yet.

• Asset identity drift — Re-imaged endpoints can produce two

asset records. Use blackpoint_assets_search and dedupe on hostname / serial before reporting.

Best Practices

• Always include tenant name in every output — partner-level work

spans many customers and ambiguity bites.

• Pair detections with the associated asset and any related

vulnerabilities in a single view; analysts should not have to chase the link themselves.

• For QBRs, pull the external-vulnerability list and dark-web list

together — they tell complementary stories.

Related Skills

• api-patterns - Auth, hierarchy, pagination