Integration

VMware Carbon Black Cloud integration

Carbon Black Cloud endpoint detection and response API: search and triage alerts, read and update alert workflow state, search the managed device inventory, quarantine a device or move it to another prevention policy, run process searches across endpoint telemetry, and read prevention policies. Carbon Black Cloud runs one host per region and puts the organization key in every path, so both are part of the credential. Requests authenticate with an API key whose value is the API Secret Key and the API ID joined by a slash.

Ask it in chat

Say what should happen.
The workflow builds itself.

When this happens, do that in VMware Carbon Black Cloud.Built from the 17 VMware Carbon Black Cloud tools below, on the connection you add once.

Common VMware Carbon Black Cloud use cases

  • collecting the hosts that executed a suspicious binary
  • recording why an automated triage step closed an alert
  • pulling new high severity alerts into a triage workflow
  • reporting how many hosts still run an old sensor version
  • confirming that a quarantine or policy change took effect
  • exporting the complete managed endpoint estate for an audit
  • quarantining a compromised laptop the moment an alert fires
  • building an inventory of hosts running an out of date sensor
  • enriching an alert identifier with the full detection context
  • hunting for a suspicious binary across every managed endpoint

What you can do with VMware Carbon Black Cloud

Each of these is one operation on one endpoint, available both as a workflow step and as a tool an AI agent can call on its own. Nothing bundles several operations into one action, so what a run did stays readable afterwards.

Most endpoints run on the free plan. A few, mainly the ones that publish on your behalf, need a paid plan.

Alert, 5 operations

  • facet_alertsFacet alertsPOSTCounts Carbon Black Cloud alerts by field value so you can see the shape of a result set without listing it.
  • get_alertGet alertGETReturns the full record of one Carbon Black Cloud alert.
  • get_alert_historyGet alert historyGETReturns the audit trail of every triage change made to a Carbon Black Cloud alert.
  • search_alertsSearch alertsPOSTSearches Carbon Black Cloud alerts by query, criteria and time range and returns full alert records.
  • update_alerts_workflowUpdate alerts workflowPOSTCloses, reopens or re-classifies every alert matching a query and time range in one asynchronous request.

Device, 5 operations

  • facet_devicesFacet devicesPOSTCounts Carbon Black Cloud devices by field value, for example by operating system, policy or sensor version.
  • get_deviceGet deviceGETReturns the full inventory record of a single Carbon Black Cloud device.
  • perform_device_actionPerform device actionPOSTRuns a containment or management action such as quarantine, bypass, policy change or sensor upgrade on a set of devices.
  • scroll_devicesScroll devicesPOSTPages through every managed device without the 10000 record ceiling of the ordinary device search.
  • search_devicesSearch devicesPOSTSearches Carbon Black Cloud managed devices by criteria and returns their inventory records.

Note, 2 operations

  • create_alert_noteCreate alert notePOSTWrites a note onto a Carbon Black Cloud alert, optionally as a reply to an existing note.
  • list_alert_notesList alert notesGETReturns every note analysts have written on a Carbon Black Cloud alert.

Policy, 2 operations

  • get_policyGet policyGETReturns the full definition of a Carbon Black Cloud prevention policy, including its blocking rules and sensor settings.
  • list_policiesList policiesGETReturns every Carbon Black Cloud prevention policy with its identifier, priority and device count.

Process, 2 operations

  • get_process_search_resultsGet process search resultsGETReads the rows produced by a process search job and reports how far the job has progressed.
  • start_process_searchStart process searchPOSTSubmits a process search across endpoint telemetry and returns the job identifier to collect results with.

Job, 1 operation

  • get_jobGet jobGETReports whether a background Carbon Black Cloud job such as a bulk alert workflow update has finished.

Use VMware Carbon Black Cloud from Claude Code, Cursor or Codex

Connect VMware Carbon Black Cloud in LiveContext, create an API key in Settings, then add the LiveContext MCP server to your client. Its VMware Carbon Black Cloud operations become tools the client can call, next to every other integration you connected.

Claude Code
claude mcp add --transport http livecontext https://livecontext.ai/mcp --header "X-API-Key: YOUR_API_KEY"
Codex (~/.codex/config.toml)
[mcp_servers.livecontext]
url = "https://livecontext.ai/mcp"

[mcp_servers.livecontext.http_headers]
"X-API-Key" = "YOUR_API_KEY"
Cursor, Claude Desktop and other JSON configs
{
  "mcpServers": {
    "livecontext": {
      "type": "http",
      "url": "https://livecontext.ai/mcp",
      "headers": {
        "X-API-Key": "YOUR_API_KEY"
      }
    }
  }
}

Set up the MCP server step by step

How to connect VMware Carbon Black Cloud

  1. Create your workspace

    Sign up free. Nothing to install.

  2. Connect VMware Carbon Black Cloud once

    Add your VMware Carbon Black Cloud connection in Settings. Every tool from this integration reuses it, and secrets are encrypted at rest and visible only to you.

  3. Describe the job in chat

    The workflow builds itself in front of you and picks the endpoints it needs. Drag the steps yourself on the canvas whenever you would rather be explicit.

VMware Carbon Black Cloud integration FAQ

What can you do with the VMware Carbon Black Cloud integration?

LiveContext exposes 17 operations on VMware Carbon Black Cloud, covering alert, device, note and policy. Common uses include collecting the hosts that executed a suspicious binary, recording why an automated triage step closed an alert and pulling new high severity alerts into a triage workflow.

Popular integrations

Browse the whole catalog