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'.

Identity-centric view of traffic: which ACCOUNT the communicating process ran as, which workloads it acted from, what it reached, and over what period. Answers least-privilege questions that workload labels cannot -- what can this account reach, and from how many places. Resolves DOMAIN\user and user@realm to one identity, so a person appearing as both CRYSTAL\jdoe and jdoe is not counted twice. Classifies service accounts (root, SYSTEM, mysql) separately from interactive ones, because wide host spread is normal for a daemon and notable for a person. Findings are ranked by how unexpected they are, and are observations, not verdicts.

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.

Time-bucketed flow counts from ONE Explorer query: how many flows and connections fell into each 15m/1h/6h/1d bucket of the window, with every bucket present (zeros included). Use it for 'blocked flows per hour for app X' instead of one summary query per bucket. Rows are bucketed by first_detected; Explorer aggregates a persistent connection (and, for older data, several days) into one row, so rows_spanning_buckets and resolution_note say how much the start of the window is smeared. spikes=true applies the shared rule: a bucket >= 3x the median of the non-zero buckets is a spike, and worst names the largest with its multiple.

A snapshot of who talks to whom on which service -- for the whole org, one environment (scope={env}) or one app (scope={app, env}) -- and the drift against an earlier snapshot. One Explorer query over the window; keys are app-pair x service with the decision set seen (A allowed, P potentially blocked, B blocked), never counts, plus per-app shape: peers in/out, external destinations and sources, services, blocked share, attributed providers. Compare by passing baseline (the fingerprint object this tool returned before) or baseline_days (a second query over the N days before the window): new / changed / gone keys, drift per app, the peers and providers that came and went. A compare across another PCE, org, scope or identity axis is refused; unequal windows and truncated sides are warned, since they inflate new or gone. Use it for 'what changed in payments/prod since last month', 'is this environment's shape stable', or to keep a per-app history.

Is the PCE answering, and how fast. Probes GET /health first and returns JSON: status (ok | unreachable), health_http_status, health_round_trip_ms, total_seconds. On failure the error names the host, how long it waited and the HTTP status or timeout -- a 5xx is the PCE or its front end, a timeout is the network. Waits are bounded (MCP_PCE_RETRIES, MCP_PCE_REQUEST_TIMEOUT); run this first when any other tool returns tool_timeout.

How full is this PCE, against its limits. Reads the documented metrics -- flow storage and retention per source vs limits (traffic_flows/database_metrics), managed-workload count over time (reports/time_series_statistics), and soft_limit_exceeded / hard_limit_exceeded events in the window -- and probes the object-limit API (/api/v2/object_limit_profiles and /api/v2/api_usage_limit_profiles, root-level, undocumented). A 403 there is reported as 'exists but this key is not allowed' (the PCE logs an authorization_failed audit event), a 404 as 'not on this PCE version', a 200 passed through with a best-effort summary. warnings lists anything at or above 80% of a limit or above a soft limit.

Get rulesets and their rules, from draft or active policy, rendered as data: scopes as [{key, value, href}], consumers/providers as {label: {key, value, href}} | {all_workloads: true} | {ip_list: {name, href}} | {label_group: {name, href}}, ingress_services as {port, proto} or {service: {name, href}}. Allow, deny and override_deny rules share one shape (rule_type). Rulesets and rules carry created_at, updated_at, update_type and created_by/updated_by as {username, href} when the PCE sends them (username needs GET /users; null if this key may not list users). labels matches ruleset SCOPE; actor_labels returns only the rules that NAME those labels as consumer or provider, in any ruleset -- 'the policy that touches app X'. Each ruleset costs one extra request for its deny rules, so filter where you can.

Get IP lists from the PCE with optional filtering. Each list carries ip_ranges as [{from_ip, to_ip, exclusion, description}] and fqdns as [{fqdn, description}], plus is_default: true on the built-in list that covers 0.0.0.0/0 or ::/0. Use contains_ip for an exact 'which lists cover this address' answer, evaluated server-side (CIDRs, from/to spans, exclusions, IPv4 and IPv6); the ip_address filter is the PCE's substring match on the range text and does not look inside CIDRs.

PCE audit events as data. Each event carries created_by as {type: user|agent|system, username, href}, resource_changes as [{resource_type, href, name, change_type, changes}] (which ruleset, rule, workload... changed and how), notifications as [{notification_type, info}] and action as {api_endpoint, api_method, src_ip, http_status_code}. Filter by event_type (one string or a list, ORed) or by kind: policy = sec_policy.create/restore, rule_set., sec_rule., deny_rule., ip_list., service.* (create/update/delete); enforcement = workloads.bulk_update / workload.update whose changes name enforcement_mode; ven = agent.activate/deactivate/tampering/clone_detected/suspend/unsuspend, workloads.unpair; auth = user.login/logout/sign_in/sign_out/authenticate, request.authorization_failed. Verified on a live PCE (26.30): rule_set., sec_rule.create/delete, deny_rule., ip_list., service., workloads.bulk_update, request.authorization_failed. The rest are Illumio's documented names not yet seen on a PCE (expected); event_types_unverified lists them per call. The PCE filters on one event_type per request, so a list or kind is one request per type, merged newest-first and capped at max_results; event_types_queried echoes the list.

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 an IP List from IP ranges, FQDNs (api.example.com, *.example.com), or both. At least one entry is required. 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.

Which IP addresses show up in traffic that the PCE does not know as a workload at all, and what do they do. Unknown = Explorer attached no workload to that side of the flow AND the IP is not an interface address of any inventoried workload (managed or unmanaged). Not the same as find-unmanaged-traffic, whose test is 'no app label'. One Explorer pull, one workload pull, one IP-list pull. Per endpoint: fqdn, address_class (private | public | link_local | multicast | broadcast | loopback), ip_lists (named lists containing it; the 0.0.0.0/0 default list is dropped), likely_provider for public addresses, neighbourhood (the /24 or /64 it shares with N managed workloads), as_source / as_destination blocks (connections, flows, peer workloads, peer apps as 'app (env)', top-10 ports with an admin flag, policy mix, first/last seen), peers_enforced, and profile shapes: scanner, fan_in_server, admin_reach, high_volume, single_peer, with the numbers each test used. Noise classes are counted but listed only with include_noise. With ip set, profiles that one address: full peer x port table and a timeline (1h buckets up to two days, else 1d) with the shared spike rule. Read-only.

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.

First look at policy posture against a framework (PCI-DSS, DORA, NIS2, NIST, CIS, ISO 27001, SWIFT CSP, HIPAA): keyword-routed heuristics on draft policy and recent traffic, summarised as a score. Not audit evidence: for per-test results from ACTIVE policy for an app/env scope use collect-compliance-evidence. An unknown app_name or env_name label is an error, not an estate-wide run.

Audit evidence for segmentation controls, per app/env scope pair, from ACTIVE policy (pversion=active by default) and observed traffic. Runs the framework-independent tests the illumio-compliance-evidence skill defines (T1 inventory, T2 enforcement, T3 VEN health, T4 unmanaged in scope, T5 providing rules described, T6 no broad consumer, T7 admitted services vs approved list, T8 inbound boundary flows with potentially-blocked and blocked evidence plus a per-day timeline, T9 outbound crossings, T11 draft-vs-active drift for the scope's rulesets, T14 events and flows present) and returns, per test and per pair, {result: PASS|FAIL|EXCEPTION|NOT_TESTED, measured, rows, evidence}. No score. A capped pull never yields PASS (EXCEPTION). An unknown scope label is an error. T10 (unknown endpoints), T12 and T13 (attestations) are listed in not_run. Framework requirement mapping stays in the illumio://compliance/* resources. Read-only. Query cost: scope-wide one pull each of labels, rulesets, IP lists, services, pending changes and events, plus per pair one workload pull, four traffic queries and one deny-rule read per matched ruleset; queries reports the count.

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 which PCE credentials apply to the current user without revealing secrets. Always carries mode: per_user (your own key), shared (the operator's service account -- PCE-side audit shows it, not you), or stdio. In hybrid mode this reflects THIS request: registered users whose key could not be used are told they ran as shared.

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.