Get workloads from the PCE. Use detail_level to control breadth vs depth: 'compact' (default) for tabular overviews of thousands of workloads, 'full' for complete data on specific workloads, 'labels_only' for maximum breadth with just identity and labels.

Update a workload in the PCE. Identify by href (preferred) or name. Provide only fields you want to change. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Get labels from the PCE with optional filtering

Create a Illumio Core unmanaged workload in the PCE WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Create a label of a specific type and the value in the PCE WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Delete a label in the PCE WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Delete a workload from the PCE. Identify by href (preferred) or name. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Get traffic flows from the PCE with comprehensive filtering options

Find which processes talk to destinations outside this PCE's managed estate - the shadow-IT / unsanctioned-egress question. Returns ranked findings of process -> external destination with port, protocol, the user, current policy decision and volume, preferring an FQDN over a bare IP where the PCE resolved one. Use this instead of get-traffic-flows when the question is 'what is talking out', not 'show me all traffic'.

Summarize traffic flows as structured JSON. Sections: by_process (which binary talks to which destination, on which port, under which policy, and as which user), external_destinations (traffic leaving the managed estate), blocked (what policy is stopping), app_to_app (coarse view). Prefer this over get-traffic-flows for analysis - it is far smaller and answers the usual questions directly.

Are my credentials and the connection to the PCE working?

Get rulesets from the PCE with optional filtering

Get IP lists from the PCE with optional filtering

Get events from the PCE with optional filtering

Create a ruleset in the PCE with support for ring-fencing patterns WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Create a deny rule in an existing ruleset. Deny rules block specific traffic (processed after allow rules). Override deny rules (override_deny=true) are the HIGHEST priority — they block traffic even when allow rules exist, meaning 'this must not happen under any circumstances.' Use override deny for emergency isolation, hard compliance blocks, or active attack response — NOT for normal segmentation or ringfencing. Rule processing order: 1) Essential rules, 2) Override Deny (blocks above all), 3) Allow rules, 4) Deny rules, 5) Default action. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Get services from the PCE with optional filtering

Create a service in the PCE. Supply at least one of service_ports, windows_services or windows_egress_services. windows_egress_services matches a process on the consumer side and needs a Windows VEN there. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Update an existing service in the PCE. Identify by href (preferred) or name. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Delete a service from the PCE. Identify by href (preferred) or name. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Update an existing deny rule in a ruleset. Identify the rule by its href. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Update an allow rule inside a ruleset, identified by its href. Only the fields you supply change. Use this to refine a rule in place — swapping an inline port for a process-qualified service, for example — instead of rebuilding the ruleset. For deny rules use update-deny-rule. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Delete a single allow rule from a ruleset, leaving the rest of the ruleset intact. For deny rules use delete-deny-rule. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Delete a deny rule from a ruleset by its href WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Update an existing label in the PCE. Provide either: 1) href + new_value (optionally with key), or 2) key + value + new_value to identify and update the label. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Create a new IP List in the PCE WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Update an existing IP List in the PCE. Provide either 'href' or 'name' (but not both) to identify the IP List. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Delete an IP List from the PCE. Provide either 'href' or 'name' (but not both) to identify the IP List. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Update an existing ruleset in the PCE. Provide either 'href' or 'name' (but not both) to identify the ruleset. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Delete a ruleset from the PCE by its href WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Create a ringfencing policy for an application. This analyzes traffic flows to discover which other apps communicate with this app, then creates a ruleset with:

1. An intra-scope rule allowing all workloads within the app to communicate on All Services

2. Extra-scope rules for each remote app+env discovered in traffic, allowing them in on All Services The result is a coarse-grained segmentation that controls which apps can talk to each other, reducing risk without requiring per-port policies. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Analyze traffic flows to identify infrastructure services in your environment. Builds an app-to-app communication graph and computes centrality metrics to rank apps by how 'infrastructure-like' they are. Infrastructure services (DNS, AD, logging, monitoring platforms, shared databases) are consumed by many apps and should be policy'd first during segmentation rollouts. Returns a ranked list with scores, classification tiers, and connectivity details.

Provision pending draft policy changes in the PCE. This moves draft rulesets, rules, IP lists, services, and label groups from draft to active state. You can provision all pending changes or specific items by href. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting. Additionally requires an explicit confirm token, so it takes two steps: the first call returns a token to be passed back in the second.

Compare draft vs active policy to see what would change on provisioning. Shows new, modified, and deleted rulesets, rules, IP lists, and services.

Assess whether an application is ready for enforcement by analyzing its traffic flows, existing policy coverage, and identifying potential gaps. Provides a readiness score and actionable recommendations.

Create ringfence policies for multiple applications at once. Optionally auto-discovers infrastructure services and ringfences them first, then standard apps. Uses the same logic as create-ringfence for each app. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting. Additionally requires an explicit confirm token, so it takes two steps: the first call returns a token to be passed back in the second.

Get enforcement mode status across all workloads, grouped by application and environment. Shows counts per enforcement mode and identifies apps with mixed enforcement states.

Generate a policy coverage report for an app, showing what traffic is covered by existing rules vs what would be blocked. Helps understand how much of an app's traffic is already policy'd.

Find traffic involving unmanaged (unlabeled) workloads or IP addresses. These are sources or destinations without app/env labels, representing potential policy blind spots.

Analyze traffic patterns to detect potential lateral movement paths — chains of connections that could allow an attacker to pivot between applications. Identifies apps that serve as bridges between otherwise disconnected app groups.

Check policy compliance against common frameworks (PCI-DSS, NIST, CIS). Identifies workloads in specific compliance scopes and verifies that segmentation policies meet framework requirements.

Get Container Workload Profiles for a container cluster. These profiles control how Kubernetes pods are managed by Illumio — mapping K8s namespaces to Illumio labels and enforcement modes.

Update a Container Workload Profile to manage Kubernetes pods in Illumio. Set managed=true and assign labels to start managing pods in a namespace. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Get Kubernetes Workloads (CLAS mode) from a container cluster. Shows Deployments, Services, and other K8s objects managed by Illumio with their labels and policy sync state.

Get container clusters (Kubernetes/OpenShift) registered in the PCE. Shows cluster name, CLAS mode, online status, kubelink version, and node count.

Get pairing profiles from the PCE. Pairing profiles define the initial enforcement mode and labels for VENs when they pair with the PCE.

Register (or overwrite) PCE credentials for the current authenticated user. After registering, all PCE tools become available in this session. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Remove the current user's stored PCE credentials. Idempotent — safe to call even if no credentials are stored. WRITE OPERATION: changes PCE state. In clients that gate tool calls (Claude Desktop, Claude Code), this pauses for the user to approve it -- the call has not failed and must not be retried while waiting.

Check whether PCE credentials are registered for the current user without revealing the secret values.

What changed in this MCP server. Call this when tool behaviour does not match what you expect, after the server has been updated mid-session, or before relying on assumptions formed earlier in a long session -- a cached tools/list and remembered response shapes are not refreshed when the server changes. The unlearn field lists behaviour changes that make previously correct assumptions wrong. Needs no PCE connection.